I have been happily jamming away for the past couple months on my robot, Zaethira. (Which is a concatenation of my kids' and wife's names, and happens to sound geek awesome, the geekiness of the whole is greater than the geek sum of the parts).
Anyway, I could have written a 20 page blog post about how things are coming along, but I think a diagram does a much better job. I made the below because I needed to get a handle on where I needed to focus and what I planned to do. This diagram made me realize how flipping complex this project is.
Here's a couple of key points:
- I'm using ChibiOS. I wanted originally to use the .Net micro framework, but it was too taxing, and unless I wanted to manage making my own builds of the framework, I would be limited in how "close to the metal" I could get. Chibi has great hardware support for the STM32F4 discovery board I'm using.
- In a bit of feature creep, I decided to add scripting support in the form of the Pawn scripting system. I first heard about Pawn in this project for my Seeed DSO Quad scope. (Once I get more comfortable with the language itself, I'd like to take a stab as writing some for the DSO). I was a little surprised how easy it was to get the initial Pawn bytecode interpreter running on my robot. I still have a lot of additional parts to add to it, like real-time debugging of scripts (wirelessly over zigbee!)
- I still have to actually connect the two modules. I've got a little code on either side, but it's not beign used yet. I plan to get a better battery solution soon than the 5 rechargeable AA's, which I feel wont be able to handle all of it at once.
- I started to try to implement Z-modem over Zigbee using the source to lrzsz. It turns out the Zmodem is a good deal more complex(and robust) than ymodem, and lrzsz was really written with workstations and servers in mind.
- I've found SPIN to be a bit frustrating to develop an architecture with. It is not object oriented. I may be be a little to hard-wired to think in object oriented languages (or even straight C would be easier). I love the flexibility of the propeller hardware. I'm early enough in development that I could re-write much of the code, but I don't think there's any other single microcontroller physically capable of doing what I want. I may give Catalina C a try, (I tried it very briefly a couple years ago), it sounds like it can generate smaller and/or faster code than propgcc.