R/C Car sensor question
I am going to be converting a remote control car to automation and was curious as to what people thought about which microprocessor and language they would use. I am also curious about what sensors others would use.
Note that I have not posted my thoughts, rather I am curious.
So -
1) What processor and language would you use and why?
2) What sensors would you use and why?
Comments
The why here is that the P1 has 8 cores and allows you to write independent running parts of software with more ease then a single core can.
As of language, it depends on what languages you know already, Parallax is concentrating on BlocklyProp and C/C++ lately, but most examples and objects in the OBEX are still in Spin/Pasm. There are some BASICs out there and if you can handle it, a very powerful FORTH.
As of sensors, it all depends on your needs.
My guess would be some encoders to read movement and direction of the wheels, to remember where you are and where you are going. Next thing is obstacle avoidance, starting from simple whiskers on switches for 'I bumped into something', the classical PING ultra sonic sensor for short distances, the IR Ping for slightly longer distance and a laser range finder for even longer distances. All of these 3 sensors have different abilities to 'see' something.
GPS might not make any sense indoors or for short distances, but if you plan to run outside around you house it might help. But keep in mind that the accuracy of GPS is around +-30 feet.
Enjoy!
Mike
I have written an RC decoder for the Propeller that I use to control a two wheel unit with a camera on it and drive around the house with goggles on.
If you look at the ELEV-8 flight controller you would have all the sensor and code you needed. If you look at the code you will see it's a mix of code and very hard to follow.
There is also the ArduPilot product that already will control your car for you. This would take all the fun out of coding it but should work out of the box.
I have tried the encoder piece of code and found that the wheels slip and getting accurate reading not easy. Even the 360 servos work as well for this use.
Using a laser ping sensor may be a better fit since you could mount four of them on the car and get distance readings from all side and decide what you wanted to do based on distance. No encoder slippage with them. More like a self driving car. You could also use a servo and 1 laser ping sensor and do a 360 sweep.
You may want to start with an ActivityBot 360 which has all the parts and then move on from there. I have a 3D printer so I can build my own frame for putting things together.
Mike
You left out a lot of details. How big is it? Is this indoors or out? GPS navigation? How fast do you want it to go?
Do you own any sensors?
If not start out with a Ping sensor. Get it setup on a breadboard. Get a standard servo to simulate the RC car's steering, and a continuous rotation servo to simulate the RC car's motor. Once you have everything working on your desk, and have some experience with the code, then move it to the car.
There's still a lot more info needed. I'm guessing your RC car uses standard servo for steering and ESC for motor control. Both run the same flavor of communication and they're easy to work with. It's just a guess though, your car may not work like that at all.
If you could send closeups of the electronics, battery packs/connectors, or even the model of the car, it would be easier for everyone
Personally I like to measure in potatoes
As Xanadu says, "I'm guessing your RC car uses standard servo for steering and ESC for motor control".
If you are delving into hobby cars/boats/planes then you will find servo control protocol on almost all accessories.
On Obex you will find many Prop 1 servo driver programs, catering up to 8 or more servos.
If you want telemetry/remote control options, then you can use common RC transcievers or write your own using Xbee radio modules.
As iseries points out, the ELEV-8 system is a benchmark example of well researched hobby equipment and well written and documented Prop 1 hobby control and telemetry.
Sounds like my old Algebra teacher... "What are we talking about here? 15 what? Chickens? Eggs? Potatoes? Oranges?"
Xanadu - yes, several sensors of varying types.
Either way you need to make certain your not going to send a pattern that can randomly happen (you'd be surprised).
If it is truly an emergency stop then the transmitter should ALWAYS be sending to the receiver. If there is any kind of disruption/corruption of signal the receiver senses, then the E-Stop routine takes over until a manual reset can occur.
I did something like this for a RC car if it drove out of radio range... I used the sequence of numbers from the TV series LOST for my pattern :-) ... plus the command data I was actually sending to the RC car and a simple XOR CRC check at the end.