Difference between revisions of "Self-Guided RC Car"

From Hive13 Wiki
Jump to navigation Jump to search
m (moved Hive13 Wiki:Self-Guided RC Car to Self-Guided RC Car: didn't mean to use 'Wiki' namespace tag.)
m (H-Bridge)
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
This is the wiki page for the self-guided RC car that [[User:TraylerPhi|TP]] is working on.
+
This project has been discontinued and archived, replaced by the [[Self-Guided RC Car AI]] project.
 +
 
 +
[[File:SGRC Car Overhead.jpg|400px|right]]
  
 
= Overview =
 
= Overview =
Line 19: Line 21:
 
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.
 
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.
  
[http://www.mcmanis.com/chuck/robotics/tutorial/h-bridge/bjt-circuit.html Chuck's Robotics Notebook] has a nice tutorial on this kind of H-bridge, and my bridges are basically exactly as shown on this page except for different transistor parts and my complete lack of motivation to use opto-coupling.
+
[http://www.mcmanis.com/chuck/robotics/tutorial/h-bridge/bjt-circuit.html 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.
 +
 
 +
 
 +
[[File:RC car bridge.gif|500px|center]]
 +
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 ===
 
=== Sensors ===
  
 
For obstacle avoidance I'm currently trying to make due with two Sharp IR range sensors, which I bought from [http://www.hobbyengineering.com/H1061.html 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.
 
For obstacle avoidance I'm currently trying to make due with two Sharp IR range sensors, which I bought from [http://www.hobbyengineering.com/H1061.html 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.
 +
[[File:SGRC Car Head On.jpg|300px|center]]
 +
  
 
=== Decision Making ===
 
=== Decision Making ===
Line 39: Line 47:
 
</table>
 
</table>
 
</center>
 
</center>
 +
Based on this decision table, we get the following 'control' circuit:
 +
[[Image:Discrete schematic.gif|600px|center]]
 +
(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 =
+
= Current Status -  Cancelled =
  
* The car has been built as described above and works - kinda.  It works if you define 'works' as "Does what I told it to do."  I am currently re-thinking the steering control system - always backing up to the left is less than ideal and the car keeps running into stuff with its tires.
+
* Project replaced by [[Self-Guided RC Car AI]] on Sept 10th, 2009.
  
= Log =
+
= Work Log =
  
== Aug 31, 2009 ==
+
'''Aug 31, 2009'''
  
 
Built control circuitry.  Tried to go to DebCo for some P-channel MOSFETs but they close at fraking 4pm!
 
Built control circuitry.  Tried to go to DebCo for some P-channel MOSFETs but they close at fraking 4pm!
  
== Sept 1, 2009 ==
+
 
 +
'''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 [http://www.microchip.com PIC] for control, possibly the [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en020096 PIC16F505], but others have expressed the opinion that this would lower whatever cool factor the car currently has going for it.
 
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 [http://www.microchip.com PIC] for control, possibly the [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en020096 PIC16F505], but others have expressed the opinion that this would lower whatever cool factor the car currently has going for it.
  
= Current Issues =
 
  
My stuff is perfectEverything I do is wonderful.  (Too lazy to describe all of the problems the car is currently having, so for now I'll just touch on them in the Next Steps section)
+
'''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 [http://www.neural-networks-at-your-fingertips.com/ AI] routine, in an attempt to make up for the very likely probabilty that I'll be moving to a microcontrollerTo 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:
 +
[[File:Rc car simulation.png|300px|center]]
 +
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.
 +
[[File:SGRC Car Side Shot.jpg|400px|center]]
 +
 
 +
= Final Issues =
  
= Next Steps =
+
* 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.
  
* Figure out exactly which dust filled hole in the bowels of my apartment my digital camera has fallen into and retreive it so I can take some pictures.
+
[[Category:InactiveProjects]]
* Schematics would be cool.  Sounds like work, which is less cool.
+
[[Category:Projects]]
* Seriously consider adding at least one more forward sensor?
 
* Re-position sensors to include the space directly in front of the front tires within their field of view.
 
* Replace PNP Darlingtons with higher amp rated versions (low priority).
 
* Rethink and hopefully improve steering control design.
 
* Layout and solder finalized circuit.
 

Latest revision as of 19:59, 8 November 2010

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

SGRC Car Overhead.jpg

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.


RC car bridge.gif

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.

SGRC Car Head On.jpg


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:

Left SensorRight SensorAction
LowLowSteering Centered, Moving Forward
LowHighSteering to Left, Moving Forward
HighLowSteering to Right, Moving Forward
HighHighSteering to Left, Moving Backward

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

Discrete schematic.gif

(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

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:

Rc car simulation.png

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.

SGRC Car Side Shot.jpg

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.