Let's Make Robots!

RoverX - A lunar rover study

Travels on the lunar surface

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.

Arm under construction:

The main board and the robot arm control board:

The PIC12F683 monitors the voltages of the two Li-Po batteries. If the voltages drop under a certain limit, a buzzer starts to sound:

Remote control, using cheap 433 MHz transmitter module:

RoverX with LADAR:

Useful sketch for programming the arm:

I have created a poll: Which Google Lunar X Prize team has the most sophisticated rover in the moment?

You're all roboteers, be honest, visit the team web sites, study the rover prototypes and vote then:)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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!

Hi IG,

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 ?

These are very good questions.

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.

I would not use an accelerometer because is a single-point-of-failure, better duplicate the touch sensors puting a row in front of another.

You detect the wrong output but what if the wrong output is not a caused by a tempororay condition but permanent defective input or output pin ? the algorithm as you have described it will calculate over and over again and the results between microcontrollers will still be wrong.

If one microcontroller dies, as ignoblegnome said, you must implement something like a ping-pong message exchange between microcontrollers.

P.S.: I am raising these questions in the ideea that some may be of some help.

P.P.S.: Do not laugh, but I think the simplest and strongest design will be a controller built with heavy duty discrete transistors in an electromagnetically and termal shielded enclosure.


The algorithm can include that the calculation will be repeated only one or two or three times.

Which controller is now defect? I am thinking on a simple mechanism they are using in manned spaceships. The astronaut can activate manual control over the ship but must plug in a secret code firstly. This asures that only a clear thinking astronaut can overtake the space ship.

Most big electroncis companies offer space qualified components, also micro controller. Sure, as the circuit would be simple, it could be made by discrete components.

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.

Hi Markus,

very nice, a similar project is Asguard by DFKI Bremen: http://robotik.dfki-bremen.de/de/forschung/robotersysteme/asguard-ii.html (in case you haven't seen that one yet). There's also some videos on YouTube.

Thanks for the link, TUD_SK, very interesting. Was not aware of Asguard.

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 ?