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 ■■■■ 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.
29/4/2012
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.
Explores and avoids - More on the way.
Actuators / output devices: beeper, Pololu motors, Head scanner servo
The programming seems pretty competent as well. It only seemed to have a minor issue when it got into the tight corner. Maybe a counter to check how many times it turns left and right to say “hey, I am in a corner and should probably try a complete 180” ?
Totally agree about the corners. Currently it only ‘lives for the moment’ (i.e. the last sensor sweep) but I think it really needs a memory to set a course of action and follow it, unless something with higher priority comes along. This was just a first try to get things moving, but I’ll also be looking at a state machine type concept as well as a ‘big loop’ structure.
My head code only works with a step of 1 or 2 at the moment; It has to hit the sensing values. Easy enough to expand it though.
I’m just rewriting the code as a state machine(ish) which is running a bit sluggish at the moment. I’ll be doing a new board using a 28x2 module soon so can up the processor clock from 8MHz to 32Mhz which will sort it.
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.
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.
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.
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.
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’.
