Self-Guided RC Car

This project has been discontinued and archived, replaced by the Self-Guided RC Car AI project.

Overview

Background

Several years ago when I had the nerve to blow money on such things, I attempted to build out a '68 Volkswagen Beetle for The DARPA Grand Challenge. During that time I thought it would be fun to convert a small RC car for self-guided operation also. I bought the car from RadioShack for maybe $30, tore it apart, and promptly forgot about it completely.

Inspired by joining Hive13, and particularly a similiar RC Vehicle project that Paul is working on, I am now trying to actually build this thing (the Volkswagen was never finished either, but I've already sold it).

The Vehicle

Standard issue cheap piece of junk from Radio Shack. I believe it used to be some kind of truck maybe? Not very large.

The rear power motor is a simple brushed DC motor connected to a gearbox with two settings, high and low. I think the low setting gives more torque but don't hold me to it. The front steering motor is a smaller version of the rear motor. The front wheels are spring loaded, so the front end 'snaps back' to center when the steering motor is not being powered. The battery pack that came with the car says that it's 9.6V, but it consistently reads over 10V whenever I do occasionally get around to charging it.

Control

H-Bridge

Each motor is controlled by a simple transistor H-bridge, which allows a logic signal from a controller or something to turn the motor in either direction. I had meant to use power MOSFETs, but DebCo was out of the parts I wanted so I had to use BJT Darlingtons.

Chuck's Robotics Notebook has a nice tutorial on this kind of H-bridge, and my bridges are basically as shown on his page except for different transistor parts, a slight inversion with the NPN transistors, and my complete lack of motivation to use opto-coupling.

The most damaging thing you can do to an H-bridge is turn on both transistors on one side of the motor at the same time. This basically creates a short across the battery through the transistors and will quickly fry them. While in the schematic above it might seem that this is exactly what I'm doing, I swear I'm not. The PNP (TIP130) and NPN (2N6387) transistors activate at exactly opposite levels, so wired this way only one of each can possibly turn on at once. The H-bridge for the steering motor is identical in every way.

Sensors

For obstacle avoidance I'm currently trying to make due with two Sharp IR range sensors, which I bought from Hobby Engineering quite a while ago. These sensors have a range of about 2 feet or so and output a voltage from 0-5V based on the range to target detected.

Decision Making

Probably the only thing making this project unique in any sort of way is that at this point I'm not using a microcontroller. The algorithm for the car's decision making process is pretty straight forward, so for now I'm using discrete logic. The analog sensors are being monitored by comparators that fire a logical high when the voltage of the sensor reaches a predetermined level.

I'm thinking that the car should act in the following way:

Based on this decision table, we get the following 'control' circuit:

(Note that this diagram shows LS chips because that's all my schematic software had - I used HC chips in the real circuit. The 100K resistors would need to be lowered to maybe 10K if using actual LS chips. The difference is LS chips are TTL whereas the HC chips are CMOS.)

Current Status - Cancelled

• Project replaced by Self-Guided RC Car AI on Sept 10th, 2009.

Work Log

Aug 31, 2009

Built control circuitry. Tried to go to DebCo for some P-channel MOSFETs but they close at fraking 4pm!

Sept 1, 2009

Realized DebCo didn't have any P-channel MOSFETs for sale. Purchased transistors instead; re-designed and finished H-bridge portion of circuit. Demo'd car (as it were) at weekly Hive13 meeting; got some good feedback from other Hive members. I'm considering moving to using a PIC for control, possibly the PIC16F505, but others have expressed the opinion that this would lower whatever cool factor the car currently has going for it.

Sept 3, 2009

Much to my annoyance I still can't find my digital camera, but...

I've been thinking a lot about trying to maybe make the car run on some kind of AI routine, in an attempt to make up for the very likely probabilty that I'll be moving to a microcontroller. To that end I've built a crappy sort of simulator to test more complex control ideas. Right now it just models what the car already tries to do (a little better than the actual car does it, unsurprisingly). The code is too embarrassing to post for now, and it's absolutely not portable in any fashion (libX11 graphics hack), but it does work and I thought I'd share a screenshot:

I think I must have too much time on my hands - anything to keep from doing something actually productive, right? Anyway... The light blue square is the car and the lines coming off of it are the sensor paths, which turn red when triggered. Here the car is just about to make a right turn. The green squares are the registered obstacles of the overworld map. Moving obstacles are an unimplemented but highly plausible possiblity.

Sept 10, 2009

Finally found my camera - just in time to take a few pictures before I take the thing apart.

Final Issues

• Sensor positions are causing the car to clip most obstacles with the front tires.
  • Need to get the space in front of the tires into the sensor paths.
  • If the sensors were to be angled slightly outward this would help this issue and also keep the car from just following along the walls, which unintentionally ended up being the default behavior, but it might then require a third sensor in the middle to avoid thinner stuff coming up dead-on.
  • Just moving the sensors out and maybe back a little would help greatly without needing a third sensor, but then wall-following stays the norm.
• I suspected and the simulator proved (to me at least) that even if the design was working perfectly (not clipping stuff with the tires) the programmed behavior is boring.
  • Maybe a random turn every now and then? This would probably require more than the discrete logic control it's currently using.
  • Perhaps the problem is one of motivation (the car's, not mine). It feels like it needs a better goal than just "don't hit stuff." Here we would definitely start needing a smarter control system.