A little one is born. After a lot of 3D refinement there is a working prototype on the road… keep reading!
Last version was made out of recycled scrap and household stuff. And it worked, partially. But the tracks were not good enough for further development. I wanted a more reliable track. Time for Pololu’s 22T Track set and to migrate the design to a more interesting hardware.
This is the BOM of the prototype:
- microcontroller board: ATmega328p (Arduino Pro Micro clone). $4.00 (shipped, if buying 2 units)
- IMU board: MPU6050 (GY-521) $2.80 (shipped)
- motors: 2x N20 micro motors, 1:150 reduction metal gearbox (many sellers: Pololu, Solarbotics, chinese traders, etc.) $4 to $15 each (shipped)
- motor controller board: Pololu DRV8833 dual driver carrier $7.00 (+ shipping)
- 2x 14500 li ion 700mAh rechargeable batteries (1S2P), $3.00 each (price shipped, if buying 10 units)
- Pololu 22T track set $12.00 (+ shipping)
- 4x TCRT5000 IR proximity sensors $0.20 each (shipped, buying 10 units)
Total aprox. $45.00, prices may vary depending on destination country and seller. Plus custom conection plates inbetween them, and a custom handmade aluminium chassis.
The result is less “frankesteinish” than the previous version, but still a working prototype.
The code had to be updated, tweaked and calibrated for the new motors an geometry. The initial just “climb towards slope if you are on a slope” behaviour of previous version was changed in this test to :
– climb towards slope if you are on a slope
– if you are on an horizontal surface, if it is black: then keep going straight; if it is white then stop
In the first seconds the robot expects to be on a white flat surface, to calibrate the sensors.
This simple set of rules allows, within a proper black playground with a white mountain, that the robot eventually gets to the mountain, climbs it up, reaches the top and stays there.
You can see the test results in this video.
And now the conclusions extracted from the test, most of them deducted beforehand as they are quite obvious:
– It needs a very good grip, silicone rubber tracks on cloth surface works fine, but may be improved (rubber on glass is excellent, but reflects IR light). Just one note: one has to ensure the black cloth is black for the IR sensors, and the white cloth is white for them. IR spectrum reflection/abortion is different from visible light.
– geometry: in order to be able to climb each other the width / height proportion has to be at least 4, so that the centre of mass of the one climbing surpasses the edge of the other one.
– behaviour: it would be nice to add a “avoid black slopes” rule, so that they turn back at an arbitrary angle once the reach a black wall.
– sensors: it could have a pair on each side to detect cliffs at the sides.
In the meanwhile I’ve been making a lot of 3D sketchup prototyping, with ideas as: put the batteries inside the wheels (1/3 AA batteries); make the wheels along all the whole front/back (but not the tracks, like the Flintstones’ cars, so that it doesn’t get stuck on the edges of the mountain); put the motors between the wheels, under the tracks, etc.
This is the last 3D version so far:
I’ve made a cardboard mockup of the last 3D version to test the size and the components fittings, like the sandwich board that connects all the other boards or the four 350mAh 10440 li-ion batteries (1S4P).
This is a prototype model made out of household stuff, that detects slopes (with an accelerometer) and runs uphill until it reaches an horizontal zone or finds a cliff (with IR proximity sensors).
The next goal is that it moves forward on medium gray horizontal surfaces (floor) and climbs up over white (other robots) surfaces until it gest to the top of the heap (an horizontal white place).
This is a rough test with treads made out of a kitchen mat that Mey suggested would have a lot of grip.
The grip is great indeed, as Mey said, but I have to find some other base material to put it below the mat foam, so that it holds the tread in place and it doesn’t slip sidewards out of the wheels.
And here some pictures of the testing prototype with bottle cap wheels
Thinking of an approach that would allow Emergence, David and I tried to identify some of the rules that will control the robots’ behaviour:
check status: horizontal or vertical > if vertical then stop motors (?) check status: upside up or upside down > if upside down, change motor direction check light intensity: > compare to previous value >> if higher than previous value >>> if more on right side, turn right (e.g. stop right motor) >>> if more on left side, turn left (e.g. stop left motor) >>> if equal go straight >> if lower than previous value, change motor direction (go backwards) check status: collision > check if wall or other robot >> if wall, then turn >> if other robot check if it's its front or back >>> if front, then keep going >>> if back, follow its orders (e.g. left and right LED) check status: following other robot? > if yes, follow its orders (e.g. left and right LED) -- light/color gradient on floor check light intensity: > compare to previous value >> if higher/lower than previous value, keep going >> if lower/higher than previous value, turn (in one or random direction)
David made a very cool mechanic prototype of the stacking crab concept:
It can walk sideways and lift itself up to make room for the next robot. Will probably need three motors: two for being able to steer, and one for lifting.
Mey and I are considering several software alternatives that allow us to make the prototypes and send them to be 3D printed.
The ideal would be that we could use the same software on our different platforms. Mey is using OSX and I’m using Ubuntu GNU/Linux.
So far my favorite choice is FreeCAD, for several reasons. One, of course, is because it is free, with no restrictions or paid extra features. Another one is because I got used to SolidWorks at the University, and FreeCAD learning curve is less steep for me than, for example, OpenSCAD.
Some first test prints to play around with, made at Raumfahrtagentur.
The round ramp idea:
The upend idea: