Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Google
Search WWW Search seattlerobotics.org

Mars Lander Idea

Karl Lunt

So Kevin Ross, the SRS president, and I were headed over to Silverdale, to give a presentation to the state-wide Mensa meeting held there on November 9th 1996. Since this trip involves both driving and a ferry ride, we had plenty of time to talk robotics. And the conversation turned, as always, to new club contests.

We focused on a Mars exploration event, since NASA and its Mars mission will be in the news for some time to come. We settled on a two-room format, where an autonomous robot explores an area hidden from the view of the human controller. The controller can issue commands to the machine, but must rely solely on data received through some kind of data channel.

As usual, we hit the wall with the data channel; building a reliable link is just not easy. Even if you select one of the obvious media, such as RF, you still have to face all of the robot-specific questions. What is the bandwidth? What kind of protocol (if any) do you use? What kind of data will you exchange? How much current will the devices draw?

After spending several miles thrashing on these questions, Kevin suggested a lowest-common denominator solution: restrict all competitors to using a 9600-baud RF serial link. And before some of you out there start whining about lack of equipment and/or low throughput, let me provide some details. Using a standard connection eliminates one big hurdle to designing a Mars explorer robot. Those builders without the required RF modems need not hesitate; they can simply use a cable to wring out their software. When it's time to run the event, Kevin and I will provide the actual RF modems. They will behave exactly like a physical cable, but will draw a little more power.

Since the Proxim RF modems we will use already contain packetizing and error detection, builders won't have to get their hands dirty, mucking about with low-level protocol details. Their software simply sends a byte, and the byte gets to the other end of the "wire."

You are on your own as to the data you send. If you can squeeze low-res video through this link, fine. If you only want to send a few packets of sonar data, great. But all contestants will have a fixed, common channel for data transfer, with no need to design or build what must be the toughest part of the system. I'11 provide full details on the interconnect later, but at the robot end, it will be transmit and receive lines and some source of +5 VDC power you supply. For the PC, the RF modem will hook to a standard DB-9 RS-232 serial port, using a wan-wart for power.

This scheme allows Kevin and I to introduce a very interesting wrinkle to the event. We can insert a laptop in the link, which delays all two-way traffic. Thus, commands sent from the PC will take a fixed amount of time to "get to Mars." Likewise, telemetry from the robot will be delayed before it "reaches Earth." This type of delayed exchange would be reserved for the "open" or most difficult event, since not all contestants will be able to test their system with this delay inserted.

We got so excited talking about the possibilities offered by this fixed-link scheme that Kevin and I never got around to the event's specifics. We discussed generally what each robot would find during its explorations, and how we would award points based on the type and accuracy of information returned. And naturally, explorer robots should scoop up samples for transfer back to some analysis station.

By next meeting, I hope we will be able to present a full contest design. I'd love to see a Mars exploration event next year; the tie-ins would be wonderful. We're talking everything from NASA to the Pacific Science Center, from Bill Nye to Olympics of the Mind.

In the meantime, you can begin designing your explorer 'bet, knowing that one of the hardest element is already behind you. Use the time you would have spent on designing the link to figure out as many sensors as possible. We've already thought up tests for heat, light, direction, mass, color, texture, size, and a few others. So drag out those design notebooks, fire up those compilers, and let's get started.

Keep on keeping on...

Karl Lunt: karl@mav.com Web: www.seanet.com/-karllunt