Goeff 2.0: Following in the Tracks of the Mars Rovers

Laying the foundation.

We Can Rebuild Him…

After watching The Martian a few weeks ago, I was inspired to create my own semi-autonomous rover. Unfortunately, the privilege of space travel is still reserved for a few select exceptional individuals and even they may only get the chance once or twice. I’d still like to help push humanity towards the stars so towards this end I’d like to develop my skills with embedded electronics which control the probes and craft we use to explore our neighbors. So I decided to redevelop my previous “rover” I called Geoff. In his first form, Geoff was an object avoiding robot built with an Arduino Uno, IR distance sensor and the Dagu Rover 5 chassis.

With this project, my goal is to capture certain aspects of a semi-autonomous rovers like those we’ve sent to Mars. I’m also including features that are characteristic of probes used here at home like direct control. The goals I’ve chosen to focus on are listed:

  • Prioritized Reactions
    • Suspend activities and begin charging
    • Send logged data when threshold reached
  • Environmental Awareness
    • Map best route to goals
    • Reconnaissance using sensors with logging
  • Energy independence
    • Solar panels charge on-board batteries.
  • Remote Access and Control
    • Software updates
    • Navigation updates
    • Direct control

Better than he was before. Better… Stronger… Faster

In selecting the parts for Geoff 2.0, I strove to mimic the functionality of a Mars rover while keeping the price and difficulty within my means. I already have a BeagleBone Black and after some research found that it would be a capable board for this project. Not only does it support various ARM Linux distributions and plenty of GPIOs, it also include two realtime microcontrollers built in called Programmable Realtime Units (PRUs). With these, I can stick with the Debian image that it came with without patching the kernel or replacing it with a real time kernel. I still may move to a real time kernel in the future but that will be implemented later in the interest of quickly setting up the hardware and testing it.

Tentative Parts Listing

  • BeagleBone Black Rev C running Debian Wheezy (kernel version)
  • Navigation
    • Adafruit 10-DOF IMU Breakout – L3GD20H + LSM303 + BMP180
    • Adafruit Ultimate GPS
  • Power
    • 2 x USB / DC / Solar Lithium Ion/Polymer charger (v2)
    • INA219  High Side DC Current Sensor Breakout
    • 2 x Lithium Ion Battery – 3.7v 2000mAh (wired in serial)
    • UBEC DC/DC Step-Down (Buck) Converter 5V @ 3A
    • 2 x Medium 6V 2W Solar panel (2.0 Watt)
  • Drive
    • 4 x 7.2V DC motors
    • 4 x Quadrature Encoders
    • 2 x Adafruit TB6612 1.2A DC/Stepper Motor Driver Breakout Board
  • various sensors
    • temp and humidity
    • IR motion
    • object detection via sonar
    • CMUCam5 Pixy camera

The first system I have focused on after building the rover’s frame, pictured above, has been the power system. Since I want this rover to be autonomous, I have designed it to be as energy independent as possible. To achieve this, I designed a power system that incorporates LiPo battery packs that can be charged via a solar panel. Implementing and testing the solar component will be done later on in the project since we’re going into winter here in Alberta and because there is a lot of work to be done before the freedom solar panels grant is of any use.

This slideshow requires JavaScript.

Since the drive system will be one of the largest power hogs in the system, I have been working on it in tandem with the power system. The drive subsystem will consist of the four motors and encoders found in Dagu’s Rover 5 chassis. These motor are rated for 7.2V with a stall current of 2.5A  and a free run current of 210 mA. As mentioned above, power will come from two 3.7V LiPo batteries wired in serial with a total output of 7.4V. The drive system will be wired in parallel with the rest of the rover. Unregulated power will go the drive system, branching off before the 5V regulator. Regulated power will go to the BeagleBone Black, sensors, and motor drivers. The central power system circuit has been wired up and I’m in the process of creating a simple wiring harness  for the motors. Once that is complete, I’ll begin the process of writing programs to test the drive system’s wiring, power drain and capabilities.

I’ll be posting more updates as I continue my work be sure to come back for more soon! Here is a link to the Trello board I’m using to manage the project. I do comment on the tasks as needed and many tasks include checklists to document their stage of completion.

Update History:

11/16/2015: Update power sub-system fritzing diagram to fix errors and reflect changes made to circuit during implementation.


2 thoughts on “Goeff 2.0: Following in the Tracks of the Mars Rovers

  1. What exactly is a kernel, and what’s the difference between a real time kernel, and the kernel that you are using?

    • Firstly, thanks for having a look! Secondly, there are books written to answer those very questions so I’ll do what I can and try to keep it short.

      To start, the kernel is a program that is part of the operating system. It is primarily responsible for managing the hardware of the computer. This includes how programs access the RAM as well as when programs are scheduled to run on the CPU.

      The mainline (ie compiled from the official source code) Linux kernel uses a scheduling algorithm that tries to allow programs fair access to the CPU while ensuring the system remains responsive. Fair means that each process gets to eventually run to completion. Responsive means the user can watch YouTube while other tasks are running in the background. While it tries to achieve these goals, there are no guarantees that a program finishes or responds in a timely manner.

      A real time kernel performs the same role as other kernels but one big difference is the algorithms it uses. Real time kernels are designed so that when the system receives an input it will reliably respond within a known maximum time. This is important if the kernel is running on a system monitoring a nuclear plant, life support machine or rover millions of miles from home. Mainline kernels make no guarantee of a programs run time so you won’t find them running on hardware where lives or expensive hardware depend on quick responses.

      I actually worked with the Linux kernel for my capstone project during my degree. I’m planning a series on that work and operating systems in general so stay tuned!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s