Strobotics

Just thought I’d post an update on what’s happening in the widget development world.

Limited Production Run

I have a very limited number of widget kits available for purchase.  This limited batch of widget kits also include a bare prototype personality at no cost with each widget to get you started in your wireless applications.

Introductory price of $US25ea (or $20ea for 5+)  include headers, bare prototype boards, 10Mhz low profile crystal, switch, all smd components are pre-assembled and tested, latest bootloader and RFM12 test program loaded.

Options:

SMA Pigtail: $2.50 for externally mounting SMA antenna.

SMA Edge: $2.50 for mounting SMA antenna onto PCB

SMA R/A antenna 900Mhz only: $4.50 to suit SMA connectors above

CR123 Battery Holder: $2.50

I’ve yet to get full details and pictures available or a means to order online yet, so contact me in the mean time if you’re interested, please let me know the band of the RF module required when ordering, e.g 915Mhz, 868Mhz or 433Mhz.

New Bootloaders

The v1.1 of the widget bootloader for 8Mhz and 10Mhz boards are now available in the download area.  These have been updated to incorporate the onboard LEDS and provide visual indication when entering the bootloader.

Source now in SVN

All the arduino source that I’ve changed for the widgets is now in SVN on the project page.  This includes:

• Bootloader source.
• modified boards.txt that include the 8 and 10Mhz versions of the RFM12Widget. 
• Modified wiring_analog.c to read Widget battery voltage.

This can be checked out/copied directly to your arduino install directory by overwriting the existing files.  The arduino environment will need to be restarted for the boards.txt file to take effect.

V1.1 PCBs

I’ve started incorporating the user feedback into the next revision of PCBs.  Still a bit of work to be done on the PCB layouts.

Widget Mesh

Started preliminary design for a simple mesh network. 

Ultimately I would like to have the ability for the widgets to provide Zigbee type functionality (not compatibility)  along with frequency hopping as standard,  that is transparent to the application.  Only very early days so far.

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.

My wife is a kindergarten teacher and in Australia, Christmas is the end of our school year and the start our summer break.  However this is also when student reports are due.   The School at which she works is a pretty expensive private school with what appears no lack of IT funding, however for some reason the Kindergarten and Pre-Primary classes are the only 2 classes not on the Schools Reporting system, Maze. 

(more…)

Prototype Specs:

• PIC16F88 running on internal 8MHz Clock – low cost and very popular, free development tools available, i.e. C compiler.
• Works in unlicensed 915MHz ISM Band(Australia/US), can work at 433Mhz by changing RF module(US/EU/Australia).
• RF uses FSK Modulation – Less prone to interference sources.
• All aspects of the RF module is configurable via the firmware, i.e. frequency, Tx power, receiver bandwidth, modulation, datarate etc.
• Indoor Range – ~30m+ works all through my house non line of sight, i.e. through multiple single brick walls, with transmitter at furtherest end, close to AV, TV & WIFI (i.e. interference sources) and receiver roaming throughout the house in different rooms, microwave oven also in the mix. No packets lost or dropped so far, but more testing needing to be done.
• Outdoor Range – Untested, but from indoor tests I would guess 150-250m easily.
  Update: Outdoor Test Results here
• Antenna – Simple 8cm whip (i.e. a single piece of wire), these RF units are matched to 50Ohm so an SMA antenna could be used
• Sync to 1/125 – in theory it could easily sync upto 1/1000 as the Rf modules are capable of the bitrate necessary, however range will be affected by the higher the speed, also the processor / oscillator arrangement may need to be revised to handle the higher interrupt rate to process data, i.e may need to use a chip with onboard SPI support etc.
• Can act as Master or Slave.
• Can be programmed to use any frequency from 902Mhz to 928Mhz (using the 915Mhz module), using the 433Mhz Module will allow similar channels.
• Can be triggered by a contact closure on Trigger Input. i.e. from camera
• Can be manually triggered by test button.
• Trigger output is isolated upto 400V, i.e. can safely trigger old stobe units with high voltage on hotshoe / sync terminals
• Powered by x3 AA batteries. Currently no power management in the firmware.
• Cost per prototype board AUD$ ~25

Note on the costs:

• Most components are sourced via local retail outlets so are probably definately more expensive that sourcing elsewhere, i.e. this can be built a lot cheaper i.e. Sub $10 in parts.
• Some of the components I had lying around at home so I’ve just used market prices in my estimates.
• No freight was added to construction costs.
• Some components have minimium order quanties such as the RF module.

Back – Triggr Home Next – Firmware

I started testing last night after finishing initial motor and wheel sensor hookups to my development board.  Couple of minor issues so far. 

Issues 

I’m using a pic based board from Modtronics. These are great and reasonably priced, along with the prototyping daughterboard.  However I have since found that the onboard RS232 is not on the same pin as the PICAXE28X, so I had to wire in an additional programming circuit, no biggy.  The other issues so far were the wheel sensors.  From my initial design I had used 10K resistors to bias the output of the opto-transistor, this was not tested and when testing the logic probe was picking things up ok, but not the PICAXE, after much stuffing around and not being able to find my multimeter (it was still packed away from shifting house) I ended up prototyping the same circuit, still had some issues, so I went  hunting for my multimeter and of course it was on the bottom box lol.  Luckily thanks to my trusty multimeter I found that the sensor was just dropping down to 3.8v when interrupted, anyway the solution to the problem was a larger resistor, a 22K on the output, this tested AOK, now getting ttl levels when switched, I also noted that the distance of the sensor to the reflective object (paper in this case) was fairly critical.  I modded the breadboard and then found one side was working fine, the other was not being seen.  Checked and found that the sensor was slightly further away than the one that was working.  So out with the hot glue gun and moved the sensor.  Both side are now giving me a reading on the PICAXE.

Motor Tests 

Next I adapted some motor control routines on Hippys PICAXE site to test my motor circuit.  First I tested without my motor control board plugged in, didnt’ want any smoke to escape, and all logic tested aok, then came big crunch of running motors live.  I can gladly say that all tests worked A1 with no issues.  Motor was tested though a range of 3 speeds in FWD, REV, Turn right FWD , Turn Left FWD, Turn Right Rev, Turn Left Rev, Spin Left and finally Spin Right.  While Testing the FWD and REV, I checked the Pulses from the wheel encoders to see how much the same each drive was over 100 counts from the wheel encoders and it looks like the Right side is slightly stronger than the left, no real surprise here as no two motor/gearbox combinations are the same.  I had thought about this a few days ago and knew that with any differential drive system I will encounter this type of problem.

Motor Control Algorithm 

This then leads me onto my motor control algorithm.  Over the last few days I have been researching PID Controller and their application to motor control for robots, as I want Buzzbot to drive in a straight line, also been looking at fuzzy logic, but I think will give that a miss at the moment.  I have been thinking of using and adaptation of the PI Proportional controller from the book “Robots – Inspiration to Implementation”  however so far I’m not 100% happy with the PWM and the way it is from the code I adapted, while it is very simple and works,  I would really like to use the onboard PWMout routines, but as I mentioned in an earlier entry it is only limited to two PWM and to two physical pins on the PICAXE – Bummer!!!!   I also thought I can use the old PWM command.  This command requires it to be refreshed, much like what is happening in  my test code, except with a agreater resolution, unlike the PWMOUT that runs in the background, perfect I thought!, but when I went to test it I found it’s only available on the 08 series…double Bummer!!!!!  So now may have to look at teh PulseOut command.

While the existing configuration does give me three speeds, the lowest is time critical and I notice that when I add a debug routine the slowest speed does start pulsing, also I don’t think it will give me the fine control needed on each of the wheel speed controllers.  I’m going to have to think about this a bit deeper.

Conclusion 

All in all everything is working as expected, with a couple of minor hicups along the way.  Biggest issue will be PWM resolution and time of my routines.  I think I’ll need to come up with another way of doing what I want simply and without too much additional hardware if I want a closed loop control system.  While I ponder on this I’ll test the IR Sensor circuits.  These I’ll prototype first before I hardwire in.  Once I finish these I can then start working on behaviour.  I would like to look at using some sort of subsumption model, but will look at it deeper as I get closer.

Last night I did some brain storming asto what the I/O requirements will be.  During this requirements phase I came across a bit of a delima with the PWM requirements for the motor controller.  The motor controller requires two outputs per motor, so this rules out using the onboard PWMout command of the PICAXE, as there are only two dedicated PWM pins on the chip that I’m using.  Although I could do it with some additional glue logic in hardware, I don’t really want to do that (as I’m lazy), so now I will be doing it all within the software, this should free up the servo command within the PICAXE, so I can now use this to drive the servo for the sonar unit.

I’m going to be using the PICAXE 28X. With my I/O current configuration of the 22 available I/O on chip, I have 2 Inputs/Outputs and 4 Analogue Inputs Available for future expansion (or and additional 4 inputs if I don’t want to use the analogue inputs).  It will be interesting to see if the processor will be fast enough process everything in a timely manner, especially with the motor control and encoders.  Well I guess I’m about to find out.

I’m now going to actually get my hands dirty with the PICAXE as I still haven’t plugged the development board into my PC yet

BuzzBot – I/O Requirements

Buzzbot – PICAXE Circuit

Over the past number of years, along with my interest in robotics and software development,  I have also had a keen interest in machining and metal work, I suppose ever since I build my first Stuart Turner stationary engine when I was 15 on my fathers Lathe,  BTW my father is also a very keen model engineer/machinist.  So wanting to merge my interests along came CNC.

I don’t own a lather / milling machine, actually I don’t even have a workshop myself (about to change with my new house being built), although I do have access to them when ever I want its still not the same as ducking out to the shed to whip up a part, in general I find making small components and PCBS a bit of a pain, mainly though lack of tools and proper work area.  So Getting back into the robotics/electronics scene after a long break has also re-kindled my interest in the CNC Area, especially for small robotic parts (plastic and aluminium) and one off PCBs (routing and drilling). 

So in my quest for knowledge, I spent the last few nights browsing what’s out there, and was very surprised to see the huge amount of work that people have done.  I must admit it had been a couple of years since I’ve last looked, and there there are some truly amazing machines out there (check out http://www.cnczone.com/).   Anyway I think I want to start off small first with a low cost pcb router/drilling using a 3-axis with a dremal.  Plenty of photos out there with low cost designs and common parts have inspired me to take some steps and begin some design work, so stay tuned.

Ok encoders are in, although not wired up.  So I quickly re-assembled the wheels and motor controller board for a quick test.  Glad to say that everything tested aok.  Put my logic pulser on the inputs and sure enough forward and reverse is easily attained on both motors, although due to the low frequency pulses of my logic pulser the motor speed did hunt a little.  Now reassembling with cabling to go to my pic development board.

This Blog is a collection of my geek projects and things I’m doing at the time.  Unfortunately due to a busy life (like most out there) the blog may see some in-action for periods of time, however don’t despair, as I get around to updating things eventually and the blog posts go  through a burst of activity.

My Interests (in no order what so ever):  Embedded Development, Photography, Wireless Sensor Networking, Home Control, CNC.

My Photography: www.flickr.com/strobotics/

Tweet Me: www.twitter.com/madeinoz