Overview

I got this idea from Darren Kitchen over at Hak5.org. They did an episode on building a web controlled rover using a cheap toy tank and a Phidgets control board. I thought that was cool and had wanted to make a web rover for a while, but it had always been too expensive. Once I saw the little tank driving around, I immediately realized that the awesomeness of the rover varies directly with its size. A kids power wheels car is small enough to fit in my garage and cheap enough to modify, plus I laughed every time I got the image in my head of a little car driving down the neighborhood street loaded down with a bunch of electronics.

So, I got with two of my friends who also thought that this was a cool idea and we started planning. We decided to use an Arduino instead of a Phidget because of price and performance. Rather than just turn motors on and off, we wanted to be able to variably control them and have inputs in case we ever want to make it semi or fully autonomous.

We have done several complete tests so far. We have added a tube that can tilt for launching model rockets. We also added a pan mechanism for the camera. And, for night drives, we now have headlights, underglow (from white cold cathodes from old scanners) and to top it all off, some green Electrolumenescent wire left over from an old project. It also now has a small amplifier and speakers for playing music. We play the music remotely with mplayer over SSH. We have been able to use an ad-hoc network for controlling the rover when there is no internet availible.

The newer version of the rover also has some new controlling electronics. We replaced the BaneBots controllers with a beefy Sabertooth 2×25. It can drive peaks of up to 50 amps for a few seconds (25 nominal). It is also really versitile, so it can be used for future projects as well. It was costly, but we felt it would be a good investment. It did help with the torque problem (we removed all of the resistors as well). It can drive on pavement at maybe 5-7 mph and on grass at around 3 mph. It still doesn’t have as much toque as we would like. We need to do more research into why this is because our initial calculations and measurements show that it is not drawing quite up to the nominal amperage allowed.

We also learned the value of safety in our last test before going back to school. We attempted a rocket launch from the tube. I hadn’t installed a safety switch yet and an as-yet-undetermined problem in either the code or hardware caused the rocket to ignite prematurely while it was being loaded in the tube. This cause a bad 2nd degree burn on the thumb of one of the guys on our team when it went off in his hand. Luckily the burn wasn’t very big and healed in about a month. Before we attempt it again, we will be installing a key start safety switch. We will also have a connector (probably just Molex) that will physically seperate the ignitor from any possible voltage.

FAQ:

Q: Why?
A: Because we can.

Q: What’s with the front wheel?
A: We were cheap. We could have bought a big servo to turn the front wheels, but servos that big are expensive, plus the way the original car steered wasn’t very good for making it R/C. Maybe in the future we will get a better solution for the front wheels, but right now the caster works surprisingly well.

Q: What happens when it goes out of wifi range/what if there is no wifi?
A:We have 2 solutions for this. First, if there is no wifi where you are, then you can’t drive it over the internet of course (unless you use a cell phone to connect [too expensive for us]), but you can still drive it locally. I was able to drive it using an ad-hoc network and as long as you are in range of the car, you can drive it. I am adding a linksys router and using WiFry (Asian cookware like a wok as a wifi antenna) that will extend that range further. As for going out of range, we actually have 2 wireless interfaces on the car. That way one card is always connected. So as you are driving down a neighborhood, you can connect with one card, scan with the other and then when you start getting out of range of the first, connect to the second. I am working on a shell script that will automate this. If there is no second network to connect to, then you get a warning telling you that you are about to strand yourself. Another solution to this problem is just to use a cell phone to get internet. We are also considering using an XBee. They make these now that have a range of up to 40 miles, which is really cool, but also pretty expensive. Because we don’t have a big enough budget, plain old 802.11 is the current method for remote control.

Q: Why does it need an entire laptop?
A: The reason ours has a laptop is for the wifi hopping capability. We wanted to be able to drive down the block and connect to open networks to keep the connectivity. You need at least 2 interfaces for this to ensure constant connectivity. The budget also kept us from getting a network camera, so a little $20 webcam had to do. We can connect multiple cameras for multiple angles, and we have plans for several ‘attachments’. Plus, we wanted to be able to play intimidating music as we drove :) .

Q: Can I drive it? Please?
A: Sorry. As of now, the rover isn’t nearly ready to be driven by anyone but us. We still need to work out some problems and bugs. Maybe if we make some good progress next summer, we might let certain people drive it. If anyone drives it, there needs to be one of us right there to make sure it doesn’t hit anything and to set up everything. The project wasn’t meant to be open for the public to be able to drive the rover. Instead, build your own! We will be more than happy to share advice, problems, and solutions.

Problems we encountered:

We had several problems when making this thing, and I thought that documenting them might help other people who attempt it avoid some mistakes. The first problem I was having was sending stuff over the serial port. I knew that I wanted a web interface and PHP seemed like the best way to do it. I learned that you can use fopen() to not only write to files, but also to serial ports. So I wrote the code and tried it out and nothing worked. I asked around online and learned that under Windows, fopen() doesn’t work the same way. If you use it in Linux, then you can use it on pretty much whatever you want. So I switched the OS to Ubuntu. Once I got that working, our first little successful test was being able to press a button on the browser and turn on an LED. We got the motor controllers in the mail and hooked one up. It didn’t work in any predictable way. We kept messing with it, using the Arduino  servo library, doing it manually, etc. Servos work differently from motors because when you send them a signal, they don’t turn based its voltage. Servos expect you to send them pulses and it is the duration of these pulses that tell it how much and which direction to turn. We emailed the manufacturer of our specific motor controllers and found out that 1000ms is full speed reverse, 1500ms is neutral and 2000ms is full forward. Check out the comments in the Arduino code and you can see where I had to specify these values. We thought that that would fix our motor controller, but it didn’t. I was stumped and my final guess was a hardware failure on the Arduino, so I began looking for an oscilloscope to make sure pulses were being sent correctly. Almost on a whim, I tried swapping out our motor controller with the second one we bought, just to make sure. And sure enough, it worked great. We had received a faulty controller. The moral of the story: isolate hardware problems first, then software. Those were the main problems we encountered (we had several smaller ones that we worked out pretty quickly). If you do try this project don’t be afraid to ask for help online. There are a lot of really nice people out there who will help you and point you in the right direction. Just don’t be afraid to do some research yourself and don’t expect the people you talk to to do all the work for you.


Do NOT follow this link or you will be banned from the site!