“Shall I attach a light sensor to the robot and program it to drive onto the bridge?”, asked one 9 year old team member to me, 10 minutes before session end without joking. This sounds rather strange for such a young kid, but surely he knows what he is talking about. We tried to learn them rule number one in design: “do not reinvent the hot water” and we encouraged them to find some successful examples on Youtube…
Nevertheless there is a difference between seeing and doing. It is nice to see the power of belief in ones own powers, but even these self-confident little designers have to start with the beginning. I tried to explain them that you cannot join the Tour de France if you are still cycling on a tricycle and I guess they understood what I meant.
But what are the fundamentals for robot programming and design. For that we had to define some basic functionalities that the robot should have. First of all, the robot needs to drive in a straight line. Then it needs capability to make accurate turns. Let’s look at these now.
Driving straight sounds easy, but then there is the real world of tolerance. The default choice to program a motion is by the “move” command that controls two servos at the same time. (There is a PID control algorithm behind this to synchronize the motor displacements, but I did not bother the young designers with that at the moment). The downside of this easy to use command is that it starts and stops abruptly, causing some slip. In this slippery moment, the robot can quickly rotate a little to the side.Also the mechanical design needs some characteristics to support a minimum deviation, like a stable suspensions, minimal size difference between left and right wheel, etc. All these ideas can only partly overcome the effect of gear slack inside the servos so a random deviation of a some degree is allways there.
Then we need to determine the distance to cover. The servos can be controlled by rotation time, angle or number of revolutions, but not distance. The children have to find a way to translate one of these three parameters into a traveling distance. The first instinct tells them to trial and error and here is where we come in as coach to guide them by asking questions like: If the robot travels 12 cm with 180° of rotation, how much rotation would be needed for 30cm? The fast thinkers will see the algorithm after a few tries. See tests on http://youtu.be/7oLcekKtQwY
Turning is more interesting. The team decided to go for differential steering: different rotation of left and right servo. Some legacy information of last year’s team told them that a caster wheel induced instability so we are trying three methods. A caster wheel, a sliding stick and two slip wheels (wheels without tires that follow on the straight line, but slide on turns.) All these methods will cause some type of slip on the traction wheels. The challenge in turns is to get a reproducible turning angle. In the tests we did, this is the hard part, where the gear space in the servo have a lot of influence. For short distances it will be possible to solve a mission or two with absolute driving, but I guess I will be talking about optical sensors very soon on this blog…
What is interesting to see is that the team members are doing some R&D here. they are experiencing technical problems and have to come up with solutions. These solutions can be in several directions like in real world. It can be done in mechanics (tolerance, stability), in controls (acceleration limit, sensors) or in strategy (do we need to go there anyway?). I am very excited to see this happening from close-by and look forward to creative solutions they can come up with.
Out of the kids’ sight I have set up a SolidWorks Motion Simulation of an LEGO NXT Robot performing a basic movement; drive forward with 720° wheel rotation – stop – rotate both traction wheels 150° in opposite direction – stop – drive backward with 360° wheel rotation – stop. The result you can see on the video: http://youtu.be/kV52pek-_2Y