This is a lunar rover study I am doing for the Google Lunar X Prize. RoverX is a so called wheg robot. I was inspired by the work of the Case Biorobotics Lab. I started with some sketchup drafts before I built the robot, using 2mm and 1.5mm aluminum sheet.
The wheel legs are from VEX. I've added 6mm wheel hubs to connect the wheels with the 4 gearde motors (cytron-12v-12rpm-166oz-in-spur-gearmotor).The motor driver is a Sabertooth 2x25, controlled by simplified serial.
I know the sketchup physics plugin, but Phun is a quite nice and simple to use 2-D-physics engine to demonstrate the obstacle overcome capability of the wheel legs, which was my target to demonstrate:)
This thing is pretty cool. I was surprised at how effective the whegs were in the sand, pretty impressive! Have you tried to climb stairs with that thing yet?
I know this is just a prototype but considering the Moon temperatures and dust I have doubts about the amount of time that the present design will survive there.
You definitelly have resources and skills so why don’t you use a long time developed and tested design like Mars rovers ?
Markus, I continue to be impressed by the design of RoverX. Your latest videos really show his adaptability and range of movement over different obstacles.
One thing to consider is the reliability of your electronics. I know it doesn’t have to survive long on the Moon, but the ride up there and landing will be very rough. I worked briefly at GE Astrospace on satellite systems. Anything they shoot into space gets intensive vibration and temperature testing.
Here are a few things I learned while working there:
Use components with the best temperature range that you can get.
Try a shake test. Maybe you can borrow a paint mixer rig from a hardware store.
Try heat and cold testing.
Avoid single points of failure in your design.
Redundancy, redundancy.
Consider failure modes of components. E.g., a diode usually fails by shorting. So instead of one diode, you can put two in series so if one fails you still have diode protection.
They build one unit for vibration and temperature testing extremes. This unit is tested to failure; it will never go into space.
They space-ready unit undergoes slightly less intense temperature and vibration testing. The GE engineers used to joke that they test them almost to the point of failure… and then shoot them into space!
Commercial space systems have an incredible amount of redundancy. Each circuit has redundancy built in. Each board usually has a redundant copy. Each system usually has a redundant copy. The whole design can survive failure of any single circuit, board, or box. It’s probably not practical for you to build this much redundancy into RoverX, but if you design with this in mind, you may be able to improve overall system reliability.
Maybe you’ve considered all this already, but I’ll point it out just in case. I’d hate to see RoverX land on the Moon, only to fail due to some minor lose wire or damaged component. You might even consider sending two copies of RoverX, just in case!
Best of luck on this incredible effort. Wishing Selene Team all the best!
Thanks. You are right, all these things I have to consider.
Because each board has a redundant copy, I want to keep the complete system as simple as possible. Just building a much smaller version of RoverX (size of two cigarette packs and a mass of 200g), will post over the next weeks.
If each board has one redundant copy, how you deal with selecting correct output ? Did you designed the boards so in case of a failure the output will be something like a tri-state or an invalid value and a (redundant by design) supervisor will select the correct output ?
One more question: how will you know the distance travelled by the robot ?
I am not planning to remote control the vehicle to avoid the need of an uplink to the Moon. It is in the end a “simple” obstacle avoider. I will follow the KISS principle, only two kind of obstacle/environment sensors are considered: bi-directonal flexible band sensors and an accelerometer. The vehicle will have two batteries, but even one battery can power the vehicle in case of emergency. No solar panel, which is redundant for a 500m travel. Mass reduction will be a big issue. It will have one mirrored micro controller. Most errors are caused by high energy particle impacts or overheating. Both micro controllers will inteprating sensor and output data. If they agree, then there was no error, but if they disagree, the calculation is repeated.
The travelled distcance will be determinated by the on-board camera, which transmit HD video to the lander unit, and from lander unit to Earth.
Some kind of keep-alive routine between the microcontrollers would be a good thing. They’ll do their comparison as you describe above, but what if one processor just dies on you?
If you have a regular keep-alive routine, if one processor detects that the other stops working, it takes over. You should define one as primary and one as secondary, so that they are both not trying to command the rover in the event they lose communication to each other, but each is actually fine.
Maybe the secondary can monitor for motion or changes. If it thinks the Primary is dead, it can take over.
