Software


The other day while playing around with the ADC on the widget I had some problems with noise causing the reading to bounce around, It needed some form filtering to remove the noise.   Normally almost everyone seems to take a number of readings and then average the result, unfortunately this takes time.

I came across this simple low pass filter on EDN.  A Low pass filter works by blocking the higher frequency (in this case noise) and allowing the low frequency signal (in this case the underlying signal) to pass. hence the name.  Perfect in cases where measuring slow moving signals, like temperature etc.  The algorithm is fast, simple to implement and works a treats.  It can be made to filter faster for a more response to change or slower to give more filtering.

#define FILTER_SHIFT 3
int32_t filter_reg;
int16_t filter_input;
int16_t filter_output;
 
filter_input = analogRead(0);                 // read ADC
 
// low pass filter to get rid of noise
filter_reg = filter_reg - (filter_reg >> FILTER_SHIFT) + filter_input; 
filter_output = filter_reg >> FILTER_SHIFT;   

 

The algorithm is a classified as a leaky integrator, where the latest reading have more weight than the older reading.  So you take a single reading each cycle of the sensor loop and feed that into the filter, the output is used you would normally use the raw value.

The response of the filer can be adjusted by the FILTER_SHIFT, to make it more responsive, then lower this value, to give better filtering and hence a slower response then increase this value.  For my application I found that a value of 3 to 4 worked well, but will depend on the underlying application.

I suggest you read the full article for an in depth description.

I’ve been playing around with the Arduino Diecimila and the ATMEGA168 over the last couple of weeks to better familiarise myself with the AVR ATMega168 MCU, I’ve been using PICs on and off the last few years, but the decision was made to use the ATMEGA as the MCU of choice for the Strobit Triggr project, mainly due to the open source tool chains available, and the simply programmer required.

In short I’m glad I’ve made the switch and I must say I’m loving the learning experience.  I’ve moved from the Arduino software development platform as I found it very limiting and am now using the open source avr-gcc (win-avr) and Eclipse, using the AVR plugin and CDT plugin as my development platform of choice, I’m comfortable with eclipse as my editor as I’ve been using this for my Java development for the last 5 or so years.

As a task I set for myself to learn the onboard peripherals,  I’ve created a Weather Shield for the Arduino, so far it has the RFM12B RF module, DS1307 RTC, HH10D Humidity Sensor, a HP03D, combined barometric pressure and temperature sensor, and soon to have a light sensor and Dallas 1-Wire interface for talking to the Dallas Weather Station that I’ve had lying around in a box for the last 10 years, (yes one of the original ones released by Dallas in 1998, I’ve been waiting to move in my house for a long time),  I’ll post the weather shield design up on a separate topic later, but suffice to say, I’ve enjoyed playing with the SPI, I2C, ICP, UART and onboard timers.

I’m pleased to announce the very ALPHA release of the RFM12 library for the wireless HopeRF RFM12 FSK tranceiver module that I’m using for the strobist open trigger project.  It was developed under BOOSTC for the PIC embedded controller, but should be easily ported to any compiler.

Most of it is untested, hence the alpha release, but it’s a good starting point.  Everything is fairly well documented, but like any project could do with more.   Please send me any bug fixes/improvements that you may find while using it.

Download:  rfm12-0_1a.zip 

Features:

  • 433Mhz and 915Mhz HopeRF FSK RFM12 modules supported
  • Initialisation with a basic config
  • Set Frequency
  • Set Receiver Bandwidth
  • Set Receiver Gain
  • Set Receiver Signal Strength Indicator Level (RSSI)
  • Set Transmit Power level
  • Set Transmit Modulation
  • Set Baud rate
  • Enable/Disable Transmitter
  • Enable/Disable Receiver
  • Transmit a single byte – blocking
  • Transmit a buffer of data – blocking
  • Receive single byte – blocking with timeout
  • Receive ‘x’ number of bytes into buffer – blocking with timout

 TODO:  (not in any order)

  • Testing
  • Howto documentation
  • RFM12 Interrupt handling 
  • Non-blocking Tx/Rx routines
  • MSSP SPI implementation (current SPI implemented via bit bang)
  • Frequency hopping
  • Custom configurations

License:

Released under the Creative Commons – Attribution-Noncommercial-Share Alike

Disclaimer:

Please use this library at your own risk.  I will not be held liable for any damages.

I finally had some time this weekend so I started the hardware verification, mainly getting the PIC and the RFM talking together via SPI, of which I have had no previous experience.  The PIC is receiving it’s clock source from the RFM12 via the CLK pin so I dont need any external Xtals.  The RFM12 default clock rate on reset is 1MHz, so the first challenge is to change the speed of the RFM12 CLK to 10MHz, that way I know the PIC and RFM12 are talking.

 As I’m doing most of my software development with BoostC (http://www.boostc.com), there is a library to use the on-chip MSSP (SPI and I2C) functions of the PIC16f873A, so I thought I’d use this and the on-board SPI functions to handle all SPI communications to the RFM12, after a very frustrating few hours and with my scope monitoring the SPI pins, I finally got the SPI to spit out proper CLK, SDO, and receiving something back on the SDI line after I realised I had not had my interrupts enabled to allow for the non blocking SPI functions DOH!

Now that something was getting out and back in, however none of the commands I sent seem to be getting through, well at least not interpreted as commands by the RFM12.  After much head scratching and re-reading of the RFM12 SPI timing diagrams It occurred to me that the 16bits that make up the the RFM12 commands were getting send through in byte sized chunks, i.e. 8 bits at a time were being sent through, then the next 8 bits were send with a delay in between the two bytes, this makes sense as the internal SPI uses an 8 bit register that gets transmitted, although the library I was using allows from the transmit of any number of bytes via a buffer.  I figured this was the problem and quickly wrote some bit banging SPI functions to test the theory, and straight away the RFM12 responded to my commands and now I have the PIC running at 10MHz.

So now that  all is working in the land of Oz as far as my PIC and RFM12 and talking to each other it’s onto finishing the RFM12 library I started last week and testing that with the RFM12 Demo board so I can test Tx and Rx functionality without having two development boards set up.

RFM12 Demo Board

Well today I had my annual review at work, all went exceedingly well, it was also my contract renewal time which had previously been for 3 years,  man the last three years have flown by.  Anyway I now have my contract renewed for 5 years, along with a decent payrise to boot.

Started work on the shutdown agent, and doing the coding whenever I get some free time at work.  I have my agent displaying an initial GUI with list of server addresses that are currently hardcoded as  beliefs of the agent, and it’s responding to a manual shutdown command from the GUI, that is, it’s executing the shutdown plan (but not actually doing anything atm).  Another goal I’ve setup is to  monitor the UPS battery level, not reading anything yet but it looks like it is executing the goal every 5 seconds, and from this goal it is executing the monitor_ups plan.   Time to start fleshing out the the guts of the plans so the agent can start monitoring and making some decisions.

One problem I’ve come up against is actually bootstrapping my manager Agent which starts everything else from code.  Normally you start the agent container then load the agents ADF (Agent Definition File) into the AMS (Agent Management Service).  I have one manager agent that loads all my other agents (I only have one atm) and it’s working as it should, but I want to bootstrap it from my applications main class so that I don’t have to do it all manually, I just want to click an icon on the desktop.  I know it can be done, just have to re-read the API a bit more deeply. 

The last few weeks at work have been shocking with power outages, I think mainly to do with the summer heat ramping up, 38DegC yesterday,  at one site I we have a fairly overloaded UPS that does not stay up for very long, while a new 8500VA is on order, I have decided to write a small agent application to shutdown all our servers at that site in a graceful manner based on a UPS battery life remaining,  i.e. initially all non critical services are shutdown, than as battery life decreases then core servers get shutdown.  The servers are a mix are a mix of Windows 2000, 2003 and of course Linux :)   

Now being the glutton for punishment I am, I know there is probably something already out there that will send out a broadcast to shut things down, but always wanting to implement agent based solutions I think this would be a nice project.   

Well it’s been a while since my last post – Sorry about that, alot happening in my life at the moment and unfortunately robotics have taken a bit of a back seat.  Although it’s taken a back seat it has not been forgotten and during this period I’ve been looking at Intelligent Agents using JADE and more importantly JADEX that sits atop of JADE and provides a BDI Agent  BDI – Belief, Desire, Intention.  Actually I had come across JADE a couple of years ago and dabbled with it a little, but then got busy with my job at the time.  By chance I came across the site again and rekindled my interest and how it can be applied to robotics.

One of the cool thing about JADE is the ability for agents to live in any container on a network and work together, that is talking to other agents that perform a particular job to help them in their individual goals.  Agents can also migrate from container to container.   Think of the possibilities, an agent can be monitoring the hardware platform and detects an abnomily then all agents leave the host before it fails completely, pretty cool stuff.  Also using the LEAP plugin for JADE agents they can run on mobile computing, i.e. small hardware footprint, obviously something cabable of  running a Java VM, but still something with a small Memory/CPU footprint. 

What I can envisage here, is an agent based home control system, with all appliances networked, each with their little helper agents.  E.g. the homecontrol agent talks to the mowerbot system and sets a new goal, “mow the lawn”.  The agent on the mowerbot dutifully makes this it’s primary goal.  So off it goes mowing the lawn until that goal is achieved, using it’s beliefs to help it obtain this goal, the goal could be deemed as complete by the the amount of lawn covered/cut etc. The mowerbot agent also monitors the mowing system, battery is getting low, so the new goal that overrides the current goal is go and get charged, so the Agent could now ask the home control agent to turn on the recharge station  beacon so it can locate it, the agents goal then becomes navigate to the recharge station, once recharged, the prior goal comes back into play and the mowing of the lawn continues.  Or alternately a problem occurs and the mowerbot gets stuck, or has a hardware failure.  The Mowerbot agent then communicated this to the home control agent that inturn notifies the occupier by different plans (i.e. email, phone txt etc) that it’s something needs to be done and intervention is required. 

I’m currently playing with JADE/JADEX and writting a helpdesk system based on these agents to help me in my day to day work.

 Helpdesk Agent System

Switch to our mobile site