Older blog entries for marcin (starting at number 5)

29 Jul 2005 (updated 29 Jul 2005 at 06:57 UTC) »

Not too much excitement this week generated by success, as failure has certainly had the upper hand. I've started a resign of the electronic system by listing the peripherals that I'll want in a typical robot (not just the current one) and mapping that to the uC peripherals (timers, etc) that are available. For example, differential drive (independent PWM to each motor) will take 2xtimers(w/PWM) and three GPIO. Controlling the SRF04 currently looks like it needs 2 timers, etc. It's looking promising - contrary to a previous post, the M16C that I have has 11 timers, although the pins for these timers are shared with other peripherals (eg UART). So there is a bit there to be allocated, which is nice.

All that software subsumption architecture stuff is really application programming and more in my expertise, it's doing the device drivers that is making me insane. I'm trying to do the code for the SRF04 (pulse out, measure width of pulse coming back) and I can't get the thing to work - most of the control code is in interrupts, so it's a bit hard to debug, but from what I can see, the SRF state machine (INIT->READY->TRIGGER->TX- >MEASURE->READY) has some issues. Most notably, i check that the state is SRF_READY before doing the trigger, and the check is with a function call that simply returns 1 if the srf_state == SRF_READY. It never gets past that, even though I know that the interrupt that puts it into the ready state does fire. Very frustrating.

If anyone would like to teach me a lesson, and show me how it's done, you can find my code here . Help or hints would be appreciated.

Also, for some reason, I can't get sprintf to work in my code, which is really strange since I have previously used it in other projects. It compiles happily, but the runtime just does wierd things -> so that makes reporting the range of the SRF that much more difficult. (I use sprintf to generate the character string for display to the LCD).

Nothing worthwhile was every easy. I just have to keep telling myself that.

Have a good weekend. Marcin

So, it turns out the weekend wasn't productive at all - I was doing some tidying up and came across an old game (F1 Manager - circa 1996) which I propmptly whiled away all of Saturday and most of Sunday with.

That's not to say, though, that I didn't think robotic thoughts. I've come up with a four level behavioural hierarchy for my little robot. It sort of follows from what I've been reading regarding subsumption architecture, but also trying to make it a 'natural' behaviour model. I'm sure this model has been discredited by some people smarter than me in these things, but I haven't consulted the literature so I'm currently happily ignorant. And, having explained it to my wife, it seems plausible.

1. With the highest priority, we have direct device control - eg the ISR that controlls the operation of the rangefinder, the comms ports, etc. These have to be very much short and sweet ISRs. The analog for the real world to this level of the hierarchy is the involuntary muscle control we all do - eg breathing, hearing, etc. (Note that hearing is a basic function, understanding/listening is something totally different).

2. Next we have the 'self-preservation' reflexes - the ones that protect the robot. These are things like collision avoidance and recovery, low battery recovery, etc. The real world equivalents are pretty easy to imagine - I, personally, find it very difficult to walk into a wall on purpose.

4. I put this here (ie before 3) because it just makes sense in an explanation. The lowest priority is the default behaviour(s) of the robot. This may be simply to do nothing, follow the sun, hide in corners, or it could be to just roam. Think of a dog when it's left by itself.

3. Next is the level of task oriented activity - these are the high level tasks that are the reason for the robot being turned on. The sort of activities at this level are things like search and retrieve, map, navigate, etc. This is analogous to a sheep dog getting told to rustle up some sheep.

I think that 1,2 and 4 are fairly easily implemented in code because they can just be linear combinations of simple state machines. Level 1 is device drivers, level 2 is reactive code (ie if dist < threshold, do collision avoidance) and level 4 can be either random or fairly simple. If the robot has a sufficiently interesting level 4 behaviour (eg roam or follow motion) then it will be pretty cool without even having any level 3 actions programmed.

Cheers, Marcin (marcincoles__at__yahoo.com)

After getting all excited about the possibilities of software subsumption, I have made a very basic simulator using Borland C++ Builder (ie for windows) V1. You can find it on my geocities site under the news section.

While I wasn't able to achieve everything as easily as I hoped, I think there is heaps of potential here, without necessarily totally exhausting my ability to comprehend what's going on. The hardest part can be the arbiter on the outputs - currently it is a winner takes all arbiter - if a more cooperative approach to resources is desired. So now I'm going to try to stick this into my robot on the weekend - this will be a bit of a challenge since I still have to write the driver for the IR ranger and rewrite the motor control code, but it's all getting pretty exciting now, so I guess I'll just have to forgo sleep.

Cheers, Marcin

20 Jul 2005 (updated 20 Jul 2005 at 07:15 UTC) »

I am totally ignoring the ultrasonic rangefinder at the moment in order to limit the exponential increase in complexity. I figure if I make the code modular and therefore pluggable, I'll either be able to add a module (ie driver) for the SRF or if I'm out of I/O then I won't. A smart design will, however, hopefully mean that there will be a bit of I/O to be had.

I've had a read of Chris Schur's PAAMI (http://www.schursastrophotography.com/robotics/paami_main. html) and predecessor and I do like the concept, although being pretty useless with a soldering iron I'm going to try the software path to subsumption. I figure that with my M16C running at 24MHz, (PLLx2) I'll be able to do some serious almost-parralelism. In the future, though, I would like to try doing some hardware subsumption - I have a motorola HC08 C compiler so it may be a goer (they are pretty cheap too, for the little ones). Then again, I have that Philips ARM able to do 32-bits at 60MHz and heaps of code space and RAM that may tempt me instead.

I am beginning to think, having considered it some more since my last post, that the best way to achieve the asynchronous FSM that Chris talks about, but in software, is to totally run via interrupts. So rather than a while (1) loop and a big nested case statement in the main(), I think that maybe all state transitions are handled by dedicated ISRs. It goes against the short and lean ISR theory, but when you think about it, it is a type of co- operative multi-tasking that subsumes all ISRs/responses below it. Then, once the response is complete, control by the ISR is released and the next lower ISR (which was interrupted) will be given a go. A lot will depend on how many levels of interrupt I can get.

Once I rewrite the basic bits (ie basic control actions), I'll post on the success or otherwise of this theory.

Does anyone else have a view on this? Can responses be given here in a post/reply type forum?

Oh yes, and did I mention that I get really jealous of all these people who have well kitted-out workshops and can make their own wheels, and chassis, etc? Well, I am. Making stuff yourself is fun, if you have the tools and know how to use them.

Cheers, Marcin

So I got my GP2d02 and SRF04 sensors today, nice. But it seems I need to get a little bit smarter with my use of timers. The M16C has 8 (including 5 PWMs) but with 4xPWM for the DC motors, 1xPWM for the sensor-spinning servo, at least 1 (maybe 2) timers/event counters for the GP2, and I haven't looked at the SRF yet, or future encoders on wheels ... I think I need a redesign.

I know I can halve the PWMs for the motors with the use of a couple of gates - I hate to increase the component count but there may be no option - I'd like to have the ability to control the pwm to each motor independently, hence I need at least 2 PWMs.

This redesing is probably a good time to look at implementing a better structured FSM and maybe some element of subsumption (although I hear it may be hard in software).

I wonder if anyone uses neural nets in mobile robots?

Cheers, Marcin.

18 Jul 2005 (updated 18 Jul 2005 at 06:00 UTC) »

I currently have a blog on Blogger (sydbot.blogspot.com) but I think this is a better place for it.

Does anyone know if there is a robotics club in Sydney?

This is my first post, and I'll post details of my adventures into robotics here.

Basically, I have made a base, which is now going to get some sensors mounted onto it - a Sharp IR ranger for collision avoidance, and a SRF04 ultrasonic ranger for mapping/localisation. The SRF04 will be on an oscillating servo to provide a scan similar to radar on war ships. We'll see how it goes. Initially, I'll be using the Renesas M16C 16 bit uC until it becomes apparent that I need more grunt - in which case I have a Philips 2138 32- bit ARM uC ready to go.

My sensors arrived today in the mail (yet to get home and open the box) so we'll see how it goes.

Cheers, Marcin

Share this page