Self-Guided RC Car 3: Difference between revisions
(Closing project page)
|Line 56:||Line 56:|
=== Controller ===
=== Controller ===
PIC16F688 in 14 pin DIP form. 12 configurable IO pins with up to 8 analog channels. Can run at up to
PIC16F688 in 14 pin DIP form. 12 configurable IO pins with up to 8 analog channels. Can run at up to on internal clock, but I have software configured it to run at only 500kHz (I have my reasons - I'll come back to this section later).
=== Motor Drivers ===
=== Motor Drivers ===
Revision as of 20:05, 8 November 2010
This project has been discontinued and archived. A replacement project is being planned.
The idea is to:
- Build a RC car that controls itself, and
- Have that RC car figure out HOW to control itself on its own, using some sort of adaptive learning routine.
The car's intristic goal will be to always be rolling.
"Standard issue cheap piece of junk from Radio Shack."
The car has two simple brushed DC motors. Rear drive motor has High/Low gear box with manual selector; steering assembly is spring-loaded to return to center when steering motor is not powered. Chassis came with a rechargable 9.6 V Ni-Cd battery and an on/off switch. The battery label is somewhat misleading but I think it's trying to tell me that the pack is rated for 1000mAh.
I added the ridiculously oversized terminal strip.
|Red||Positive Lead from Battery|
|Black||Ground from Battery to On/Off switch|
|Grey (thick)||Ground from On/Off switch|
|Yellow||Rear Motor Lead A|
|Green||Rear Motor Lead B|
|Brown||Steering Motor Lead A|
|Grey (thin)||Steering Motor Lead B|
PIC16F688 in 14 pin DIP form. 12 configurable IO pins with up to 8 analog channels. Can run at up to 8MHz on internal clock, but I have software configured it to run at only 500kHz (I have my reasons - I'll come back to this section later).
To drive the rear and steering motors, I am using two (2) L6202 DMOS Full Bridge Drivers, which are 18 pin Power-DIPs.
The feature that attracted me to these drivers in particular was their SENSE outputs. This pin outputs an analog voltage that corresponds to the amount of current being drawn by the motors. It is my understanding that with a recommended 0.15 ohm resistor this voltage would spike to full scale when a motor stalls (powered but for whatever reason can't turn), but tests with a 4.9 ohm resistor (the smallest I had on hand) show a spike to just over 2 volts when the motor stalls, which is acceptable to me.
The drivers can handle up to 1 amp of continuous current and up to 5 amps of current when pulsed. Each driver requires three (3) inputs, one for each direction and an enable. I am sharing a common pulse between the two drivers, connected to the enable inputs. Unfortunately this plays havoc with the SENSE readings, so careful timing is needed to only read the SENSE output while: 1) the enable pulse is high, and 2) the driver has had time to dissapate the transient spike associated with the motor turning on and off. Other timing hoops had to be jumped through to not trigger a 'stall' reading when the car first starts moving without hitting an obstacle, but so far the system appears to be working well. It terms of reliability, it is a huge improvement over the crash/idle detection system of SGRC2.
To the right is a picture comparing the footprints of the new IC bridges with the discrete component bridges from SGRC2. The board with the new bridges also has a 5V power regulator setup to power the controller - this regulator is not involved directly in bridge operation. As you can see, there is still plenty of room left on the breadboard for the 14-pin controller IC. I am also leaving room for the accelerometer in case I decide to re-include it at some point in the future. The compactness of the L6202's make up for the fact that they cost me about $5 a piece (plus S&H, of course). I will most likely use the SMD version for the final soldered circuit.
Sharp 30cm IR range finder mounted on a hobby aircraft servo. The sensor is bolted to an L-shaped piece of stiff plastic which has been screwed down into the horn of the servo. The sensor has a nominal range of 30 cm, but there is a roll-off region when objects are closer than 8 cm or so. This greatly distorts impressions from analog readings of the sensor, so I have set the controller to use the sensor's output in an on/off fashion, which cuts the deadband region to less than 1 cm. Although using the sensor this way losses granularity, it makes the signal very 'trustable.' The limited overall range of the sensor doesn't make this loss of granularity very painful at all.
The servo has a range of slightly greater than 180 degrees, but I will be limiting it to one of seven (7) positions. The binary addresses shown above each position hint at how the neural network will be choosing where to look.
[UPDATE] After long trials in the simulator, I have decided to limit the servo positions to only three: -45, Center, and +45.
Currently, the best simulation I have been able to create (and still imagine fitting in the PIC's limited memory space) involves a back-prop neural network (NN) with 5 inputs, 6 hidden nodes, and 3 outputs. As the networks have become more involved, and thus taken longer to train, I have created a few different 'levels' for the car to work through. Level One is what I call the 'NASCAR Problem'. This is basically an oval track, where all the turns are in the same direction. Surprisingly, to me at least, the more complex the NN routine, the longer this takes to figure out. Once an NN routine is able to solve this board by continuously circling the 'track', it graduates to Level Two, shown to the right. I feel that this board exposes the simulated car to far worse than the Anchor space could provide, so once I can simulate a car that can solve this 'problem,' I will code it for the PIC controller and bring it to the Space for testing. The goal is for the car to run from one end of the track to the other without hitting any walls. No simulation has successfully done this yet, but maybe there will be a Level Three with multiple paths. I hope to use the network weights from a successful simulation as the starting point for the real thing. Since reality and the simulation will differ, the car will certainly have more to learn, but as a starting point, why not? Current designs takes a long time to 'cool down,' in simulated time. Real time would take many battery charges to reach the same level of 'settled.'
Current Status - Cancelled
- Replacement project being planned, but not started
Nov 20, 2009
Set project to Active status. Removed SGRC2 control system from chasis and began playing with the L6202 motor drivers. I haven't done anything electronic that wasn't school related lately, so it feels good to get back to playing. The drivers ended up being much simplier to wire than I had been led to believe.
Nov 21, 2009
A night of slow going with the PIC microcontroller. Took a minute to get back into the swing of programming one of these things, but I think I'm finding a stride.
I found a 4.9 ohm resistor laying around. The motors still get enough power to slip on my kitchen floor and now I have a readable SENSE output. I'm noticing that the current jumps pretty good when the rear motor first starts out, so I've added a timeout mechanism to hopefully only trip the error flag when continously trying to push up against an obstacle. Right now it works great moving forward but is still a little jumpy going backward, which might be OK in the end, since backward is not the preferred direction anyway, and it doesn't seem to be that bad. It's fairly transisent and may stop showing up as the main control loop gets longer as features are added.
Nov 24, 2009
Stabs in the dark at figuring out the servo timings left me wishing I had ordered the in-circuit programming option hardware for my PIC programmer, but eventually the solutions were found. As expected, pulsing the rear motor driver resulted in havoc with the current sensing routines I had. I wish I had logged this last night (early this morning) when I could remember some details, but I threw in the towel around 6am. It took a couple hours, but I now have all the hardware but the IR sensor input working, which I expect to be relatively simple at this point.
I found some great plexi-glass type plastic at HomeDepot for fashioning a frame. Tonight I'll finish the hardware interfacing and plan to try to do up the frame at the Hive tomorrow. Once I get everything mounted I'll begin with implementing the simplified neural net, which I've been giving considerable thought to.
Nov 29, 2009
I managed to get a few hours of work in on the car before the Thanksgiving holiday kicked off. All components now have their interfaces up and tested. Now all that is really left is building a neural network around those controls.
As for the mounting platform, I began making a pattern out of paper for the future plastic mounded piece, but switched to cardboard since it is stiff enough to actually stand up. Why didn't I think of cardboard before? I have some spray paint in the garage if I find the time for that. I now do not intend to mould the platform out of plastic until if-and-when I have a final soldered circuit board.
One important change the new platform has made is that I have removed the terminal strip. I'll now need to solder some small pieces of wire to all of the wires that needed the terminal strip - this way they can be pushed directly into the breadboard.
I forgot to update this back when I did it, but at some point I did solder breadboard-friendly leads to all the wires that didn't fit.
Apr 7, 2010
It took many, many hours, but I have re-written my simulation software with what I consider great success. G*d Bless OOP! Not only does the new sim run much, much faster, but also much more reliably. My NN routines have improved rapidly since completing the new environment. After a long time not working on this project, it has jumpen out front. (Thought: I think 'jumpen' isn't exactly a word, but it sounds right to me. Please try to deal)
The pic to the left shows my Level Two board for the simulated car to 'pass'. The good news is that I currently have a hard-to-train network that can pass Level One (The NASCAR Problem), the meh news is that it has not been able to solve 'The Snake' yet. Yet.
I have high hopes for this latest network. The newest feature is that I am allowing the car to NOT move for limited periods of time, to give it a chance to 'look around' if it chooses. Since I don't want the car to just sit there (can't hit a wall if I don't move - problem solved) allowing it to pause occasionally has proved to be a benefit. I remain a little disappointed in how long it took to to pass Level One. I have some ideas about a Self-Organizing Map (SOM) that I will try simulating soon, although I worry something like that may exceed the PIC's memory restrictions.
- Servo IR 'vision' system cannot sense the surrounding environment fast enough for simple AI control
- Simulations have proved to me that the currently selected PIC does not the RAM needed to support the complexity of the AI routine that would be required to control the current vehicle setup.
- Looking to move to a more advanced 'vision' system to get environment data into the controller faster - this should allow a simple routine to have better results.
- Depending on the form the new 'vision' system takes, may still require a PIC with higher RAM resourses for vision support, even if control routine remains simplistic.