Overview: Feedback and Telemetry

It's one thing to have a rover that you can drive around (or which drives itself around) within your line of sight where you can see what it's doing, but to really get a feel for what's going on, or to expand beyond the immediate area, you need a way to get some information from the rover back to the control point.

For this project, I will be using an amateur television link to provide video feedback from the rover's point of view, as well as telemetry data overlaid on top of the image.  The small video transmitter I have available should be sufficient to send a signal a good distance away, and has an audio channel available, which I might use for sending packetized data as well.

The Videolynx Z70A ATV transmitter

The Videolynx Z70A has an output of 50 to 100 mW on the 70cm (440 MHz) ham band.  Using this band simplifies reception quite a bit, since the image can be received by any television with an analog CATV (cable TV) tuner built in.  This band is also quite removed from the frequencies that the control system will be using for communications, so there will hopefully be no problems with crosstalk or swamping.

The BOB-4 video overlay unit, on a carrier board

For video overlay, I will be using a BOB-4 Video OSD module from Decade Engineering.  This is a very capable module which, while a bit larger than some on-screen display units, allows for the use of halftone video and graphic elements.  It is available in both SIMM and 0.10" header form-factors, depending on your particular application.  As you can see in the photo above, I purchased the SIMM version before deciding that what I really needed was a header-based connection.  Some creative soldering did the trick though, and it now occupies less space than before, while retaining all of its functionality.

An assortment of small video cameras from the parts bin

For capturing the video in the first place, I have a number of small video cameras available.  I'll be using a micro camera of one type or another, in the interest of keeping it light and mobile.  Many smaller inexpensive cameras have lower resolution, but I figure I can start out simple and work my way up to better units as things progress.

In the next installment, I'll briefly discuss some of the sensors I'll be using onboard the rover, and then it will be on to the actual building process!

Overview: Onboard Logic

From the outset, the roverbot project was planned to be more than just an elaborate radio-controlled car.  The plan is for it to be able to navigate autonomously between GPS waypoints while detecting, avoiding, and navigating around obstacles in its path.  To do so, it will need some amount of onboard logic to do the "heavy lifting" tasks involved in performing that navigation.

To that end, the roverbot carries an Arduino Mega 2560 microcontroller board, interfaced to a variety of sensors and modules.  At the heart of the Mega board is an Atmel ATMega 2560 processor, with 256 KB of flash memory for storing program code, 8 KB of SRAM, and 4 KB of non-volatile EEPROM storage space.  It runs at a clock speed of 16 MHz, and features 54 general-purpose I/O lines, 16 analog input lines, and 4 dedicated hardware serial ports.  This may not sound like much as compared to the computer you're reading this on, but it's not too shabby, either.  In addition, the Arduino line has a huge user support base, with tons of resources and libraries available.

Arduino Mega 2560 (Photo from Arduino website)

Since I started the roverbot project, there has been a very interesting development in the world of embedded computing: the Raspberry Pi.  This is a small single-board computer, selling for approximately $35, which comprises a complete Linux system.  Created for teaching programming in schools, it's got a great feature set and is catching on like wildfire.  It features some general-purpose I/O lines, although not nearly as many as the Arduino Mega does, and they're only digital I/O, without support for reading analog values directly.  All of this can be worked around however, and there are a good number of interface boards available to enhance the capabilities of the Pi.

Raspberry Pi (Photo from Wikipedia article)

At the moment, the Arduino Mega board is more than powerful enough for what I'm asking it to do.  With a retail price between that of an Arduino Uno and an Arduino Mega 2560, the Raspberry Pi is powerful and affordable.  Probably the biggest barrier keeping me from switching the roverbot's brains to a Pi is that I am not (yet) fluent in Linux or Python.  For simplicity's sake, I'm sticking with the Arduino for the time being, but the Raspberry Pi is certainly an attractive option, which I may have to look into at a later date.

Next up, I'll take a look at some of the sensors I'll be using on the roverbot.

Overview: Command and Control

Oh boy, has this gone through some changes since my first post!

Initially, I had planned to implement a control system using packetized data transmitted via amateur radio frequencies.  While it is possible to pull off such an arrangement, I have come to realize that it isn't entirely practical for a rover of this type and size.

Point-to-point data transmission on the ham frequencies is usually accomplished through the AX.25 "packet radio" protocol, with a data rate of 1200 or 9600 bps, on frequencies of 144 MHz and up.  These transmission speeds, combined with the size, weight, and power requirements of the radios involved make this a less-than-ideal solution for this project.

Once I decided against the packet radio solution, I spent a bit of time working out a system that used a couple of Arduino microcontroller boards connected via XBee wireless modules.  I did in fact manage to get a basic control system cobbled together, but it was far from ideal.  It was relatively slow, had fairly high processor requirements, took a lot of tweaking to get the timing right between the transmitter and receiver, and didn't cope well if you weren't constantly checking and reading the Arduino's serial receive buffer.  It also had an unfortunate tendency to develop transient glitches after it had been running for a while.  It didn't really take too long to figure out that this wasn't going to work.  The XBee modules also apparently have some provision for directly transmitting analog values, but I didn't examine that option too closely because...

I finally got smart, stopped re-inventing the wheel, and took a look at what other rover and drone builders were doing to handle the control functions.

To make a long story shorter, I ended up settling on using a 5-channel radio designed for aircraft use, transmitting on the 2.4 GHz band.  Older analog R/C radio sets were very specific about which frequency sets were to be used for which type of models (ground or air operation); modern 2.4 GHz digital radios are far more adaptable and less prone to interference, so it no longer matters what you use a given radio for.  As with the mobility base, the off-the-shelf solution is proving to be a far more viable solution, which is easier to use and has better performance overall.  Just the robustness of the link and ease of implementation make it a winner.

I will still be using amateur radio on the rover - the onboard video downlink will use the 440 MHz ATV frequencies, and I will probably be sending some telemetry back wrapped up in AX.25 packets as well.  The XBee modules will also find a use, providing a reliable data channel for control signals that won't be sent via the R/C transmitter.  This will still see a good bit of use, since the goal of the roverbot is for it to primarily be an autonomous rover, with manual drive being just one relatively minor mode of operation.

In the next post, I'll talk a little bit about the onboard logic, the way it's configured now, and where it might be going as things get more complex.

Overview: Mobility

In this post, I will talk briefly about the basic mobility base that the roverbot will be built around.

The roverbot will be based on a commercially-available radio-controlled vehicle chassis.  While it may not have the "geek appeal" of designing a mobility base from scratch, this approach will have the advantage of using a known-good platform to start with, which will allow me to concentrate on control, navigation, and other systems, instead of spending all of my time hammering out little physical details.  I have nothing against scratch-building a base - my initial plan was to start with a three-wheel differentially-driven tail-dragger design, eventually migrating to a custom-built treaded design using some really nice track units from Lynxmotion.  Unfortunately, right now I just don't have access to the tools or building space that I would need to do it properly.  I would rather defer it until a later project and do it right than to do a half-baked job using what I have available right now.

In addition, I have already had a bit of experience in working with radio-controlled vehicles.  I used to race R/C trucks some years ago, and so am at least somewhat familiar with the mechanics of getting them to do what I want.  Not surprisingly, things in the hobby have changed considerably in the years since I dropped out of racing, but the fundamentals are still the same.  There will no doubt be a learning curve involved, but it shouldn't be too rough.  After a good deal of poking around and re-learning a few things, I sat down to assess what features I was looking for in a robot base, and compare them to what was available on the market.

In the end, I went with a rock-crawler model from Venom Racing (now apparently Atomik), called the Creeper.  

Venom (Atomik) Creeper (photo source: Atomik website)

It features high-articulation suspension for terrain handling, along with provision for adding rear-wheel steering, and a single, centrally-mounted motor (as opposed to two motors, mounted on each axle, as some models use).  Many rock-crawler models have permanently locked differentials on the ends - essentially just solid axles in a differential-shaped housing - to eliminate wheel spin.  The Creeper features working diffs that can be locked manually.  Since I'm actually interested in having the differential action in the roverbot, I'll be leaving mine active.

The ability to upgrade to four-wheel steering was another plus.  I may have given up the zero turning radius of a tracked base, but the ability to steer sharply with both ends of the rover should help to keep the turning radius tight enough for a reasonable amount of maneuverability.

Finally, there's the suspension.  The extreme deflection of the rock crawler chassis may be a bit of overkill, but whether driven manually via a video link or running in autonomous navigation mode, it is certain to run up against a good number of obstacles that will simply be missed by the control system, so the ability to handle large bumps and obstacles will surely come in handy.

There are some definite quirks to the Creeper chassis design, which I will cover in more depth in a later post, but for the most part, it seems to be a pretty capable chassis which will serve well for this project.

My next post will take a look at the wireless link from the control station to the roverbot.  Of all of the rover's subsystems, the control link has gone through the most changes so far.  More on that next time.

Getting Rolling.....Again.

Well, I guess it's been a while, hasn't it?

A lot has happened since that original post.  Unfortunately, most of it didn't involve the roverbot project.  I had a few things come up which prevented me from doing any work at all on any of my various projects.  After a few false starts however, I'm finally making a bit of progress.

The Plan:
I had originally intended to document the entire build extensively as progress was made, but my current workspace places quite a few limits on that sort of thing.  For the most part, I can be set up for building or taking halfway-decent documentation photos, but not both at the same time.  I'll be sharing what I can, as well as I can, though.

As before, the plan is still to work my way up incrementally from a basic mobility platform, incorporating systems and increasing complexity as I go.  The next few posts will include some more specific information about the various components that will make up the basic systems of the roverbot, along with a bit of discussion about why each piece was chosen, and where I plan to go with it.  After that, I'll be getting into the actual building and integration of the various systems, and start working towards an actual roverbot.

I have to admit that my efforts at documentation have progressed somewhat slower than the actual build, and the roverbot has outpaced my blog entries somewhat (largely because I keep meaning to get some good photos and illustrations before posting - see above regarding the workspace).  As a result, some of the upcoming entries will be a little bit time-compressed, and the times between the blog posts will not accurately reflect the time between the progress shown in them.  It should all get caught up before long though, and I'll eventually be posting in real-time as I develop things.  There will no doubt be some dead-ends and blind alleys along the way, and I welcome questions and feedback on anything.  It should be fun.

Thanks for reading!