Well, it's been almost a year since I posted anything here. My major achievements in the mean time have been blowing a lot of things - zigbee modules, microcontrollers, voltage regulators, etc. In fact it's been a bit annoying. I'm back on deck now, though, and working with the Cypress PSOC, and the graphical development tool PSOCExpress - you wouldn't want to write any AI in it, but it rocks for device drivers (motors, sensors, etc) and has a very convenient I2C interface.

Cheers, Marcin

Are there any aussies out there building robots? Sydneysiders, specifically?

marcin@roboteer.net

Finally, after what's been a 5-6 week break, I returned fresh to ScaredyBot and sorted out the issues I was having - it's amazing how quickly I was able to find the problems in the code once I actually sat down to it. So now I have a subsumption architecture going on, all on one chip (Renesas M16C). It's not quite how Brooks does it - it's not exactly asynchronous or parallel, but oh well. So I've written up four behaviours, in decending order of priority: retreat, collision avoidance, wall avoidance, and roaming. Each behaviour is written independently and can be inserted (even possibly dynamically at runtime) into the behaviour list at any level. So next, I'll get a light sensor, write the 'driver', and then try to use it in some behaviours (photovore, photophobe, other - ideas?)

Cheers, Marcin

I truly haven't done anything on ScaredyBot for almost a month - my subsumption architecture was a bit too complicated - still is, but I'm working on it. The funny (or sad) thing is, that I didn't take the step back and try to trade off some of the complexity/functionality/purity in a pragmatic manner. Basically, I was trying to go for generality that would (in theory) support any future requirements. Now that's just silly, especially considering this is only my second robot. So I'm now going to shed some of the Brooks subsumption ideals and just focus on making it work reliably, with extensiblility to support the likely future growth.

Ah, embedded ISR debugging is so much fun, because it's just so darn easy and not at all time consuming.

Cheers, Marcin

Okay, so I was a bit premature in giving myself kudos for getting a nice subsumption/arbitration thing going there. I've been refactoring the code a little while writing the rotating ranger code (ie servo+SRF as a single entity), and as it turns out, one of the conditional compiles wasn't #defined previously. Now that I have enabled it ... well subsumption has a little way to go.

That being said, though, I have to say that the architecture works as designed, it is just that my behaviours are too simple - they should be state machines, not simple conditional outputs. It does raise the question though, once the behaviours are FSMs, what will happen once a higher-priority tasks interrupts a lower priority one, since not all behaviours are mutually exclusive.

Cheers, Marcin.