Musings on bot architecture in go.

[Carl Ranson]

Hey all, 

So now that I've got my basic bot hardware together so it can be driven around via joystick, i've started thinking about adding more behaviour. 

I've been thinking about the following code structure, see what you think.

so consider a bot like mine that has, a. remote control drive, b. two reflective sensors & c. differential drive. 

you could program this as a list of behaviours with priorities. 

1. both sensors on, don't drive forward

2. one sensor on, turn to avoid crash

3. no sensors on, obey joystick input

4. no sensors, no joystick, stop. 

now since golang has effectively as many threads as you want, I thought why not implement these as a golang each, and have all of them running at once. 

at start up, the main routine would start the behaviours and link them in order of priority. 

to work out what to do next, query each one in reverse priority order and send that to the motors. 

even better than that, each behaviour can have a channel back to main to signal that a refresh is needed. 

then each behaviour can respond to a joystick or sensor event by signalling the main routine that an update is called for. 

so. 

main routine

1. creates a feedback chanel

2. starts all the behaviour routines with that channel and a link to the next lower routine. 

3. links event listeners to update the relevant behaviour routines. 

4. starts a routine that listens to the feedback channel 

whenever a event triggers, the relevant behaviours will save the state and put an update signal on the feedback channel 

the update routine will wait for an update signal, then ask the first behaviour for the motor state. 

if the first behaviour doesn't want to set the motors, it calls down to the next one and so on. 

the update routine takes the result and sets the motors accordingly . 

what I like about this is ease with which you could add new behaviours. you could imagine a high priority "low battery" behaviour that overrides all the others when the battery runs out etc. 

thoughts? 

CR

[Carl Ranson]

I've started reworking my code under this scheme and so far it's looking pretty good. 

I'm not entirely certain that chaining through the behaviours to get the current state is kosher in Golang. It might make more sense to just fire state changes through a channel as they happen. 

Will post some code soon...

[Carl Ranson]

code, messy as it is, can be found here:
https://github.com/carl-ranson/Tankbot/tree/master