How do I give a radio control car autonomous control

[Kenjones1935]

John,

I got the following from a Mike Green on the Parallax forum. I think he is agreeing with your decision to migrate up from the Basic Stamp.

With my 1/10 hobby car came a three channel RC unit. One for the DC drive motor, one for the steering servo, and a spare. I thought I could use the spare for the auto/RC toggle. This car is just an experiment to get a working prototype. Once that is done I might be able to find some money for a "real" prototype. There is quite a bit to consider in selecting the race car/truck itself. What do I want to teach about suspensions? I'm not sure.
----------Mike wrote----------
"There is no mechanism for the Stamp to automatically sample the RC channels. Typically you'd use a sequence of 3 PULSIN statements, one for each channel. The RC receiver normally receives one channel at a time and the PWM signals occur in sequence and repeat about 50 times a second. There's not much time left to do control functions once you account for timing 3 RC receive channels and 3 servo PWM output channels. It's possible to offload the PWM output functions, but I don't know any ready-to-go PWM input processor.

"I would strongly suggest you look at the Propeller. It can easily do the RC receiver timing and the servo PWM generation with two cogs (processors) and have plenty of processing power to do whatever control functions you need. The Propeller Servo Controller is a compact board that comes pre-programmed with a 16 channel servo controller, but the outputs can also be used as inputs by modifying the control program."

My next step is to examine the Propeller.

Thanks again..
Ken

[John_Mac]

Mike is correct on the sampling times, however I have made things work well for this application at a much lower rate....basically whenever it gets to it. This can lead to some choppy response on the throttle and steering servo, but nothing bad unless you really load down the processor doing other things.

The Propeller is a better chip, but look carefully at the overall cost of all the cogs and infrastructure compared to a PIC system....might still be cost effective, never used one.

[Kenjones1935]

mackrackit suggested that I use a third RC channel to toggle disconnecting the PIC when under RC control. It does sound like the simplest and maybe the least expensive way to go. Trouble is I do not know how to do this.

Is it as simple as inserting a double pole double throw switch that is controlled by the third channel into the signal line between the RC receiver and the electronic speed control? And another between the receiver and the steering servo?

Will surges and the like kill the electronics? It would be safest if there were a way to guarantee the motor being off and the servo being neutral when toggling. John, mackrackit, what do you think?

Ken

[John_Mac]

Personally I would go with what I described....software control. But someone might come up with an elegant solution. I really don't think you have to keep up with the 25ms servo rate. I have done several applications at lower rates and it works fine. So most processor will work just fine in this mode.

[mackrackit]

John made some good points as to why a hardware solution may not be to your liking.

On the flip side side, a software solution can also have some draw backs. I am coming from an industrial point of view so maybe something non-critical as a RC car could be looked at differently...

To go from manual to auto with software at least one ASM interrupt is needed, depending on the application you may want more from different sources. In your case on should be enough. If the operator can not see the car then switch to auto. Using software the code can be cumbersome. Say you are running in manual. Are you still keeping track of the sensors? That can get to be a neat trick, code space and all. If you do a hardware switch, the auto part can keep monitoring the inputs just as it would if it was in control. This way, when auto does take over it is near seamless.

Good and bad both ways.

If you do go with the hardware solution and the RC part of the car (manual) is still intact then you are halfway there. Find were the inputs to the MOSFET bank are or the motor controller and that is where the DPDT relay will go. Being the control signal is the only thing that is switching the only surge you will have to worry about is from the relay coil. A flyback diode will take care of that.

But either way you go, keep us posted. I have some young ones I am also teaching.

BTW.... I only use windows when I have to...

[John_Mac]

Hi Dave

I agree it depends on the level of glitches you are willing to put up with. I have done what Ken describes with a PIC in a single loop. The call to read PWMs is one element. Sensor analysis is other.

I don't use an interrupt on the lower level PICs. I simply read the mode channel PWM. If it is below some value I jump to manual, if above then to auto. Very simple.

I do much more in the dsPIC which actually interrupts every PWM pulse, but that is way beyond what Ken is talking about. Without interrupts on a mid-range PIC, the throttle will seem a little sluggish in response to changes, this is due to the fact that it is being sampled at less than its normal 25ms rate. But this really isn't a big deal for an RC car. Same is true with steering.

I would think that the sensor calls would only be in auto mode. So no real impact to manual response times. All depends on the details of what Ken ends up doing. I think a simple start is best. There is a big learning curve.

John

[mackrackit]

I think a simple start is best. There is a big learning curve.

Yup, as I was advised a while back when I asked "ASM or PBP first?" the general consensus was to make things as simple as possible so the students would not lose interest.

Keeping the kids excited about something makes MCUs seem easy