I’ve been busy with rover software structure lately. Although I had an ‘ok’ framework for testing, the one thing I needed to do was monitor battery voltage all the time. As in every second or so.
For that to happen I had to do the complete chain – from the top level executive, down through the HAL, out the I2C busmux, to the voltage ADC module. A few simple tests showed that it worked, but it didn’t lend itself to the kind of modular development I was looking for, and if an error crept in that prevented the voltage from being monitored… well, there was a good chance the battery would be damaged from over-drain.
So I decided to step back and look at what I was building, and how it did what it did.
First off, I doubt there is going to be an outdoor autonomous rover race in Calgary this year, which means the rover can default back to it’s role as an engineering prototype platform.
We are well into June now, and summer here only lasts until August. Two months isn’t really enough time for anyone to start building anything but a robot that competes with last years rules, and probably re-uses last years chassis or parts. And most everyone that raced in 2013 had major issues with grass/weeds in the gravel pit, so it would only be worse later in the year if it were in the same location.
If it’s indoors, well, the rover is a little big for that, unless it’s in an arena. And it’s honestly not super fun to watch it roll on flat ground, or mess around with artificial obstacles. It’s so heavy it just pushes most of them instead of rolling over them. It needs rocks, gravel, sand, and clay. Maybe a race out in the Badlands somewhere?
The next thing I was concerned with was tasking. If there were some event announced this week, and the rules were changed to require tasks to be done during the drive, that would be interesting. So there might have to be some kind of sequencer, maybe with task priorities or ranking or something. Hmmm…
Rules also add to the complexity, so I started to take a detour to see if I could express the rules of a game in a simplified way, based on positive and negative outcomes. In fact, the whole rover could operate that way, and it would balance performing work tasks against returning to the charging station for an electron top-up.
Another thing that struck me was the object-orientedness of Go, and how via interfaces different ‘things’ (i.e. structs) can respond to identical function calls differently. This means that like SHRDLU back in the 1970’s, the knowledge elements weren’t static data – they could be procedures. I had played around with the idea of using Forth or a Forth-like stack/word based system, since like lisp it’s a bit more dynamic, but Go takes that to a whole ‘nother level.
Taking it further, Go channels of an ‘activation’ type could link these goroutines together, as a sort of analogy to neural networks.
It turns out that it may be sufficient to have a fewer number of goroutines that manage concepts but contain slices of data that can be ranged over, and then let that action back propagate or forward activate other elements via a smaller subset of common channels. Functions like planning and interim goal setting/checking become interface calls, and ultimately the rover can select tasks to execute, which are really groups of skills; skills being the atomic actions the HAL knows how to execute natively.
I haven’t built that yet, but it’s on the to-do list. I’ll see how much natural language I can bake in there as well, since it might be handy for teaching it the rules of various games, and perhaps applying strategies from one game to another.
Hmmm….[ EDIT: I see the robotgames.com site is back up and running now, instead of a blank page. Maybe good news soon? ]