Let's Make Robots!

The Constructed 'M'

Explores and avoids - More on the way.
GoodAvoider.bas4.26 KB
AvoiderSM1.bas6.36 KB

Phase 1 (Updated 29/4 - New video & code.)    

Here's a little robot built on CTC's excellent Tiny Tank chassis. It's based on a Picaxe 28X2 which handles the navigation side of things and will be joined by a 14M2 to do other things in due course.  Pololu motors driven by a L293D are the motion side of things, and a servo and SRF05 do the sensing.

The name is inspired by a Philip K Dick short story - The Unreconstructed 'M'.  Unreconstructed in this sense meaning without morals and ineducable, and M standing for 'machine'.  This M had antisocial habits including planting evidence and assassination.   My one hopefully will have less of a bad attitude and I'm constructing it so . . . The Constructed 'M'.

At the moment I've just got it doing the usual thing of avoiding stuff.  It explores an area with CURIOSITY (green LED) and has FEAR of hitting objects (red LED).  Its path through an area is an alternation of these states.  Eventually it will be actively seeking out certain objects and doing the YDM thing on them (with added accompaniment).

The tiny PCB above the M is a compass board which works but is not active in the initial video.  Also, note the change in sweep rate of the U/S sensor as it gets near objects.  I rewired the 28X2 project board to give full PWM control of the motors.  This is not a task to attempt unless you really mean it as it requires several track cuts and joins.


I've reformatted the code to run as a finite state machine and tweaked the distance thresholds to make it get up close and personal and it is good.  It is very good. Wikipedia article on FSMs here : http://en.wikipedia.org/wiki/Finite-state_machine.

The robot will always be in one of 6 states; by 'state' I mean performing a certain operation (e.g. avoiding an object slightly to the left by slowing the right track).  There is a specific rule or rules to enter each state (e.g. if 30 left sensor range is less than lower range threshold) and once in a state it will continue to perform that operation until either the condition to leave the state is met (e.g. 30 left sensor value is greater than lower range threshold)  or the conditions are met to enter a state with a higher priority (e.g. mid sensor range is less than lower range threshold. Crash imminent).  State 0 is 'flat out straight ahead' and is the default state.

It still just wanders around with no purpose in life.  That will be the next step.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

It looks a lot like the TinyTank in your shop, was this a prototype?

I LOVE the toothed belts and pulleys on these.  What is the name of that product?  I haven't been able to find them yet, but I'm not very adept at searching sdp-si.

Yep, it's ChrisTheCarpenter's Tiny Tank chassis with a Picaxe 28x2 board on top. The motors and belts are available separately from Pololu.  Pololu also do a chassis that has a base slightly shorter than Chris' one and designed for their miniature metal motors so you can build your own top bits.

Haven't done much work on this lately but I'll pick it up soon.  Next step is a circuit rebuild to give it a second 'brain'.

THIS IS SO CUTE!! =D nice work (: it reminds me of wall-e

That's so cool! It's so tiny, I like tiny things.

As you went into the domain of Finite State Machines here a weblink that might interest you. This paper gives a big picture of component- and model-based construction of embedded systems where the topic of Finite State Machines is an important part within.

Interesting approach, although the scope is well beyond what I'll be requiring.  It does appear to give a full formalised view down to the lowest level of the process without losing sight of the overall functionality.

I came across FSMs way back in the early 'eighties when I was designing test equipment for various electronic and electro-mechanical assemblies.  I was building state machines implemented in PALs (mainly 22V10) developed with PALASM - http://orion.ipt.pt/~fmbarros/ed/PALASM%20Language%20Guide.htm . All very dated looking back, but pretty state-of-the-art at the time.

My code differs from a 'classic' state machine because of my 'higher priority' rule, although I think it could be written as such with an big increase in code size - too slow on a Picaxe. However, it does the job and gives me something to work from.

Very neat robot!

What is that chip stuck up in the air?

It's a Honeywell compass module.  I've tested it but I'm not using it in the videos.  It's an I2C device which outputs the orientation of the module when you ask it to. From this you can work out the bearing of the robot and steer it to go in the compass direction you want.

It's up in the air like that to keep it away from the thrashing magnetic flux around the motors.  In practice I found the readings were pretty accurate whatever the motors were doing. 

soft iron plate between motors and compass , twisting motor wires together , some ways to reduce thrashing magnetic flux , but its not a problem so it don't matter :)

This was my first play with a compass module so I had no idea what to expect and was wondering if it was possible at all on a small robot. I was pleasantly suprised by the result.  It was one of those things which just worked - first time #;¬) 

I'd like to get it closer to the main board so I'll be seeing what happens and possibly playing about with the methods you suggest at some point.