Having some issues now with the software subsumption architecture. Chris Schur was right in that the implementation in software can be a bit nasty - my implementation certainly is. I still like the concept, but I need to tidy it up a bit - the arbiter needs to work more like a scheduler as well as a sort of bus-master? Maybe.

Well, Scaredy is all systems go. Not that there are that many systems (servo, motor, SRF04 and MCU) but go it is.

I've put up new pics and a tiny video (745k) on my ScaredyBot page (http://roboteer.net/robots/scaredy.html).

So that's good. More soon.

Cheers, Marcin.

I've been putting together my enhanced controller according to my Robot-MCU Peripheral Interface. It's a living document at this stage, but once all the interfaces are designed, implemented and tested, it will become the stardard for all my mobile robots (that use the Renesas M16C, at any rate).

I've also been trying to stir up interest in a Sydney robotics club - I may have 1 interested party (well 2, if you count my wife who wants me to talk to someone else about robots) so that's a start (albeit very modest).

Ciao, Marcin (marcin__at__roboteer.net)

ScaredyBot has been working out at the gym. It's now got a bit of extra physical construction that holds the SRF04 on a servo turret. Under the turret, I've put a small furniture caster under it, so it should have better mobility around the house now. The jiffy-box construction is so far working out.

However, the robot now will be driving backwards - ie what used to be the front is now the rear - yet another code change.

I've taken the bold step of redesigning the motor driver interface as well to accomodate the extra timers required of the other peripherals - I've almost finished my robot- mcu peripheral interface document which outlines which mcu timers, INTs, GPIOs, UARTs etc will be allocated to which functions.

Cheers, Marcin

Slowly, slowly, Scaredy bot is progressing. Most recently I ripped (gently) the SRF04 off the front and mounted it onto a servo turret. Now the servo control is programmed in and working (albeit not working as per theory).

So, I've done some initial tests of getting the sonar head to scan once it gets too close, and it seems to work. I just now have to formalise the state machine and turn the whole thing into a single interface that takes an angle bearing parameter as part of ranging. Hopefully, this will mean that it will be a bit smarter in it's way of dealing with corners.

Oh yeah, but first I have to redo the DC motor drivers to use only 2xPWM timers instead of the four PWMs it currently uses - just need an XOR gate, a couple of inverters and a couple of AND gates. And, of course recode the drivers.

I've also been slowly formulating a philosophical thesis on what the essence of a robot is - ie surely robot != control system, rather robot > control system. But more on that spiritual topic later. I need to update my site (roboteer.net) - still struggling with getting some of the more interesting add ons working.

Cheers, Marcin.

I was reading the site of Paul Graham - he created what is now Yahoo! stores - and he has some interesting things to say. Firstly, that LISP is the way to go as far as programming is concerned - and having started to read up about it, well maybe he's right. I hate learning new programming languages and especially since they say this is a new way of thinking required (at 31 I may be too late to change my ways?)

Secondly, he has a quote on his site (a paraphrase, actually) of Peter Landin: "Most papers in computer science describe how their author learned what someone else already knew." Which has made me think seriously on what I am trying to achieve by writing and documenting low- level interface code.

Cheers, Marcin

Well, I haven't done too much actual work on the robot in the last 2 weeks. This is mostly because I've been trying to set up a new site (since my old one was pretty below- average) at roboteer.net. The thing that I've been doing, and I honestly didn't think it would take as long as it does, is documenting on the website the design and implementation of the interface to SRF04 range finder from the M16C. The successful implementation, not the unsuccessful optimisation. The write-up isn't completed yet. I do get distracted though.

The web host I use provides PHP Nuke, and phpBB within it, so I'm slowly making my way through developing that into a 'community portal' - I want to eventually start a robotics club here in Sydney, and I figure a BB and news page is a way to start.

I've also started thinking about what robot should be next - my current line of thinking is that I should get 2 programmable sumo kits (I'm leaning towards 2x oopic-based MarkIII sumos) so that there will be at least something cool to show anyone who may be half interested in robotics, as a way to get them hooked. I'm actually thinking to make one with a R/C add on, and have the other in auto, and then let people challenge the autonomous bot to some rounds. Obviously, that's a couple of hundred dollars, and a couple of hundred hours away, but a plan is the first step towards a goal.

Cheers, Marcin

Hi everyone.

I've had a few days where I've either done nothing on the robot, or just watched it drive around the house (mostly) avoiding walls and furniture, but usually getting snagged on the rug (the robot has some clearance issues). I'm now in the 24-hour battery recharge cycle.

An interesting observation I've come away with, that will be analysed more thoroughly over the weekend, is the spotty performance of the SRF04 in 'hard' environments. By hard I don't mean outdoors, rough terrain. I mean in my passageway. My house is about 80 years old, with thick plaster covered walls, fairly tall, glossy, wooden skirting board, and polished wood floors. When the robot approaches the wall from an angle of 30deg or more away from the normal, it doesn't get a good range reading at all - it's like the wall isn't there. Then, all of a sudden it will get reflections when it is very close and execute the emergency reverse, then almost instantly get back to the invisible zone. It doesn't do this in my bedroom.

In general though, I like the SRF04 - I think it's very accurate - within 1 cm in the ranges of interest to me - and using the driver is a snap.

I'm going to integrate the Sharp IR ranger next .. hopefully that won't take 3 weeks!

Have a good w/e.

Cheers, Marcin.

I drew up an arbitration/subsumption architecture, on the train home, and then coded it tonight - so far is seems to work. I think it is more arbitration than subsumption though. The way it works is a bit of a publish and subscribe metaphor - in that each sensor has a supply vector, identifying what inputs it reports on (oublish: for example, the SRF reports range - theoretically, a sensor could report two or more measures), and it passes this supply vector to the arbiter () function during the ISR. The arbiter has a set of demand vectors that are associated with each action/behaviour (subscribe: for example, the avoid behaviour has a demand vector of range, but the general case would be that an action demands more than one input.)

So if the (supply_vector && demand_vector) == true, then the action is interested in the change in the environment reported by that sensor, and it gets called. If the action takes control of any outputs (eg motors, leds, etc) then it sets the corresponding bit in the output vector - but it first checks whether that output is available.

Then arbiter calls the next action on the list that is interested, etc. It sounds a bit convoluted, perhaps, but I'll type it up and put it on my new site once I've had some more time to tinker with it. But the nice thing about this is that the actions/behaviours can be programmed in isolation from each other.

This works with 3 behaviours (retreat, avoid, and roam), one sensor (the SRF04), and one output (the motors). We'll see how it scales in the coming weeks. I think that the arbiter my have to become a timed action queue manager once the number of inputs and outputs and behaviours increases.

Cheers for now, Marcin.

It's amazing how simple it was to use the SRF04 in my code, once the driver was working... I wrote some simple state machine based test code using the SRF04 for sensing... if range < 200mm or so, then reverse, if 200 < range < 400, then turn left, else drive forward. It has a bit of hysteresis to avoid getting trapped.

It works pretty much as expected - there are some deficiencies eg due to the beamwidth of the SRF04 not being wide enough close in for the width of the robot. The funniest one, though, is that the robot does a bit of a back-forward-back-forward-... shudder sometimes at close ranges, although it does normally work it out eventually.

The robot now has a new name - scaredyBOT - coined by my daughter because the robot was afraid of (backed up from) her teddy bear when she put it in front of the robot.

I feel so much happier now that I'm again moving forward, not backwards, upwards not forwards, and forever twirling...

I've got a highish-res movie of the robot being turned on with the sensor for the second time (about 2 minutes after the first time), but at 18MB, it's a bit too big to post at this stage, not to mention a bit boring for everyone except me.

Tonight's work will be that software subsumption/arbitration architecture I wrote about previously. We'll see how that goes.

Cheers, Marcin.