Rallylog is an open hardware project that is used in Rally time trial competitions.

Project Home : http://code.google.com/p/rallylog/


  • RTC with battery backup
  • SD Card Data Logging
  • RFID
  • LCD
  • Battery Powered
  • Low Powered Handheld device
  • Atmega328P
  • USB
  • Arduino compatible

RFM12 Tutorials


I’ve written these “How-To” articles to help get you started in using the RFM12 transceiver module from HopeRf. I found using these modules for the first time can have a bit of a steep learning curve, so I’ve put down to e-ink what I’ve learnt and hopefully you can benefit from my trials and tribulations ūüôā

Other Articles

StrobIt Triggr


20/03/09 *UPDATE * This project now has a new home and is actively being developed on Google code project hosting http://code.google.com/p/strobit/

IMPORTANT    This page is no longer being being maintained please go to the new project page.

Welcome to the Strobit Triggr Project, an open source hackable wireless trigger used in photography lighting by using low cost strobe units triggered remotely via RF. This was started while trying to find a cost effective and reliable solution to the commercial alternatives out there. At one end of the market is the Ebay or Cactus Trigger, which is low cost but rather unreliable. At the other end of the market there is the industry standard, Pocket Wizards, very reliable, but very expensive (i.e. way out of my price range).

What I wanted to do was to create an open platform that anyone can easily build for a low cost and then be expand upon by the community. The pair of prototypes I’ve built were a proof of concept that I can get a camera to trigger a strobe unit reliably at a low cost. From early tests it appears that I’ve succeeded in my goal, but further testing is required.


Project Status :

– Prototype successfully working in single master/slave configuration !

– (20/03/2009) Project now has a home at Google Code – http://code.google.com/p/strobit/

Still Todo:

  • Specifications
  • Hardware Design
    • Schematics
    • PCB
  • Software Design
    • Wireless
    • User Interface
    • Protocol
  • Hardware Prototype


The strobit hardware design is covered by The TAPR Open Hardware License. Please see http://www.tapr.org/ohl.html for further details.


Strobit Triggr Block Diagram Strobit Triggr Topology StrobIt Triggr Schematic

Prototype Details

Firmware Description

Protocol Description

Downloads – Files associated with the project

Tests – Tests done so Far

In the Wild – Version of this trigger made by others

I’m toying with the idea of putting together a low cost kit for the enthusiast. i.e. PCB, pre-programmed PIC, etc. So we could all benefit with a bulk order of the components. If your interested please email me using the contact form the top menu or use the mailing list signup on the right to give me an indication of numbers interested. Once I finaliaze the design and get some idea of numbers I’ll get a better idea of price. At the moment it will only be available in kit form due to FCC and other Licensing regulations.

Future Improvements:

  • Higher Sync Speed.
  • Frequency Hopping.
  • Forward Error Correction.
  • Power management.
  • UI to change settings, Channel etc.
  • Save settings in Flash memory.

Java – Intelligent Agents

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

BuzzBot – Initial Testing

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


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.


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.

buzzbot -  Motor Testingbuzzbot -  Motor TestingBuzzBot - Modtronics PIC Board

Buzzbot – Circuit Design

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