Robot Inspiration Series #10: All-Terrain Autonomous Rovers
One of the first robots I tried to make without instructions, back in the RIS days, was an all-terrain autonomous rover. These robots are nice in that they don't have to be too hard to build or program, but they can have many challenges and thinking problems to overcome, and they can stimulate many creative ideas and designs. Although an all-terrain rover should technically be able to traverse any terrain, we're talking about NXT robots, so you might want to limit yourself to inside your house.
Since your robot needs to move around without you controlling it, you'll need to give it the capability to detect and respond to (or not be affected by) potentially problematic situations. Aside from the obvious one of walls and other simple obstacles, these may include:
- Steep dropoffs
- Short overhangs: sometimes a ledge or other object may block the top of your robot instead of the bottom. In this situation, a mechanism for detecting obstacles soley on the ground level would not be sufficient.
- Bumpy ground
- Steep ramps: sometimes the robot might go up a ramp that becomes so steep that the robot falls over. You'd need something that could detect this (for example, a touch sensor in the back that gets pressed if the robot tilts back too far)
- Obstacles in the back or on the sides of the robot: sometimes the robot might back up or turn into an obstacle (perhaps from avoiding an obstacle in the front). You'd need sensors to detect such objects.
One of the greatest difficulties I've found in building these robots is getting around the sensor and motor limitations. There can be so many things the robot needs to detect, but only four sensors and three motors are available per NXT Brick. You could try using multiple Bricks if you have them, or try to give each sensor multiple functions.
One way to make the robot travel is to simply make it move randomly while monitoring for problem situations and responding to them when they appear. If you wanted to go advanced, you might try to make the robot travel to a certain destination through terrain with random obstacles. Another idea would be to give the robot a task, like cleaning a floor, that it could do while moving around and avoiding obstacles.
-Jonathan
Since your robot needs to move around without you controlling it, you'll need to give it the capability to detect and respond to (or not be affected by) potentially problematic situations. Aside from the obvious one of walls and other simple obstacles, these may include:
- Steep dropoffs
- Short overhangs: sometimes a ledge or other object may block the top of your robot instead of the bottom. In this situation, a mechanism for detecting obstacles soley on the ground level would not be sufficient.
- Bumpy ground
- Steep ramps: sometimes the robot might go up a ramp that becomes so steep that the robot falls over. You'd need something that could detect this (for example, a touch sensor in the back that gets pressed if the robot tilts back too far)
- Obstacles in the back or on the sides of the robot: sometimes the robot might back up or turn into an obstacle (perhaps from avoiding an obstacle in the front). You'd need sensors to detect such objects.
One of the greatest difficulties I've found in building these robots is getting around the sensor and motor limitations. There can be so many things the robot needs to detect, but only four sensors and three motors are available per NXT Brick. You could try using multiple Bricks if you have them, or try to give each sensor multiple functions.
One way to make the robot travel is to simply make it move randomly while monitoring for problem situations and responding to them when they appear. If you wanted to go advanced, you might try to make the robot travel to a certain destination through terrain with random obstacles. Another idea would be to give the robot a task, like cleaning a floor, that it could do while moving around and avoiding obstacles.
-Jonathan
Comments
Jason W. from Sacramento
I'm not sure that's completely accurate, in that the motor encoders are really extra sensor, and valuable ones at that. For LNE/Packbot for instance, the front flippers can be used to literally "feel" for obstacles, like the height of a step or potentially the depth of a hole, by watching the motor encoders. Carefully monitoring the power and rotations of each drive motor can provide you with an idea of how much the robot is slipping or straining, telling you something about the ground it is moving over. A 3-axis accelerometer (a single sensor) can tell you not only what slope the robot is climbing, but its orientation on that slope, etc... and if you don't have an accelerometer you can make a rough one that at least handles tilt using a series of colored parts on a pendulum that hangs in front of a light sensor.
The part I find difficult is actually putting enough "intelligence" into the system to fully utilize the sensors. Usually the sensor systems on a robot can by used to produce a lot of information about the environment, but it takes some careful thought how best to tease that out (& use it).
This isn't the correct spot to post a comment like this, but don't worry - I'm not overly concerned if someone doesn't like RaSPy. Brian, Matthias, and I had fun designing it and I still think it's a good design PLUS it leaves room for others to experiment and upgrade it (like Snabeli's version).
Tell Rita I said hello back.
Yeah you're right... Since my all-terrain rovers were built with the RIS, I didn't have the built-in rotation sensors, but I completely agree with you. In fact, the NXT rotation sensors could be used in place of simple object-detectors on all sides, if you programmed the robot to detect when the motors slowed down drastically and then run "tests" to determine where the obstacle was (by trying to move in various directions).
Still, there are so many situations you could watch for that it could still be pretty easy to run out of sensors. The idea is to combine functions for each sensor. And like you said, this would be harder to program.
-Jonathan
P.S. BTW, I'm curious as to how you got LNE to feel for dropoffs... how did it know when to feel for them? Or did you get it to constantly feel for them?
> watch for that it could still be pretty easy to
> run out of sensors.
Sure, but there's a lot you can do with what you have. Sometimes that means dealing more intelligently with the data instead of just getting more of it - like you said, multiple functions (or interpretations) of limited sensors.
> I'm curious as to how you got LNE to
> feel for dropoffs... how did it know when
> to feel for them? Or did you get it to
> constantly feel for them?
If you can't see the ground, you have to constantly feel with your foot. Yes, that makes it slower - but it works. Another way is to have LNE run forward while raised slightly up on the flipper treads. If one of these runs off an edge, the angle of the robot will change, which can be sensed with the accelerometer. Neither of these is as fast or safe as having a continuous dedicated edge sensor... but then again, you make do with what you have. In fact, LNE has never maxed out the sensors - it used the US sensor, the accelerometer, and sometimes the compass, but I never bother with a fourth... and it could do a lot.