PBP projects for R/C models

[Kenjones1935]

I have not learned to SEARCH the forum.

How about I return to basics. How about I make my controls interrupt driven. If had an interrupt routine that ran every 20msec, I could create a true-so-spec PWM signal and I could measure rate of closing speed for each SONAR. I think the 16F887 can get all my work done in 20msec. If not I can up the PIC power.

Way back someone told me how to set up such an interrupt system. Where is that? It's Monday morning. Time to get moving.

Ken

[mackrackit]

Thank you for the October reference.

I have not learned to SEARCH the forum.

??????
No search required for that, it is a part of this thread.

Anyways, have you looked over the PID routines given by Henrik Olsson?

[Kenjones1935]

Yes, I looked at Olsson's routines. I got distracted by the thought that my 16F887 is just not up to the task at hand.

I glanced through the MicroChip 18F PICs. My eye fell on the PIC18F46K20.
It comes in 40 pin PDIP format. That is good. It has lots more code memory space. It is on the list of devices that can be programmed by my PICKIT 2 and my Microcode Studio PICBASIC PRO combination. It must be bigger, faster, more capable than my 16F887. True? Which 18F should I choose. I have little to no sense of the differences.

Ken

[cncmachineguy]

Ken, What makes you think your current device is not up to the task? R/C systems are very slow IMHO relative to processors. Think on this, pulses for the car happen for 1-2msec each every 20 msec. so 2 pulses (drive & steering) will be max 4 msec. That leaves 16 msec for the uP to do whatever like measure distance and decide what to output next. At 4Mhz clock, thats 16000 ASM instructions! Not PBP instructions but still a whole lot!

So heres a couple of thoughts: Use pulseout for the signals to the car. No need for int or PWM. How about connecting 1 of the car signals from the receiver to your pic. Then just check to see if the pin went high, if so its time to send out commands. This way you can use the car receiver as a 20mSec clock.

[ScaleRobotics]

I also think the PIC16 or 18 is plenty fast for the application. But the servo's and speed controllers are pretty picky about their signals. They need to be at regular intervals in order for the servo's and speed controllers to work smoothly. Otherwise their operation can be erratic. While you could measure the receiver with pulsin, I would stick to interrupts for the servo and speed controller. The PIC18F4431 has hardware that allows for R/C pwm frequencies. But it could be done with pretty much any PIC using spwm. I would probably use a PIC18 rather than a PIC16 because it opens up a couple of possibilities, but both are powerful enough.

[cncmachineguy]

Hi Walter, quick question. I am under the impression most Rx send their pulses sequencially, so when channel 1 is done, 2 starts, 2 done 3 starts... I know they are not always in numeric order, but none the less they wait until the last is don befor sending the next. At least with a little older equipment.

If my assumption is correct, in a 4 channel Rx, channel 4 could start anywhere between 4mSec to 8mSec after the start of the 20mSec frame. (channel 1,2 and 3 could be all min or all max). If this is true, They can't be too picky cuz 4 mSec is pretty darn big!. I would think it would take little effort to hit the 20mSec loop within .1msec.

so I was thinking in the main loop, don't measure the pulse from the Rx, just see if it went high. Then within a couple of instructions the "send pulses" routine would start. When thats done, acquire the next distance reading (10 mSec) then back to the old main loop waiting for the next trigger from the Rx.

Of course if my assumption is not correct, this was a nice typing excerise for me

[Kenjones1935]

1. Although the SONAR only requires a 10microsec trigger pulse, at 1100 feet per second a five foot sound echo returns (order of magnitude) in a bit less that 10 millisec. I can not trigger both SONARs at the same time. I believe their echos would interfere. I certainly do not have to trigger these devices 50 times per second. Three or four times per second would be enough. This would give the velocity rate calculations more meaning. (Maybe I should make the SONAR activity interrupt dependent, not the PWM activity.)

2. The PIC needs to control the steering. It needs to keep the car traveling parallel to the side wall a given distance (desiredtrack) from that wall. It also needs to turn the car dramatically left when a (corner) wall appears inside a given distance (frontfree) in front. Both 'desiredtrack' and 'frontfree' are VAR WORDs - functions of the POT position (which also influences the speed of the car).

3. There is a totally separate algorithm controlling steering when the car is backing up due to a collision or a very near miss. Basicly steer right and back up a couple of feet then steer left and try to go forward.

4. If the steering were absolutely under control I feel the wheel speed could be pretty much left alone. Check the POT and make the PWM signal to the Electronic Speed Control proportional in seven stages.

5. My PIC really should have four pieces of data to work from.
A. Distance to the right wall.
B. Closing rate to the right wall.
C. Distance from an object in front.
D. Closing rate on the object in front.
If it had this information I think even I could code proportional feed back loops. Note two are rates. Each of these require two readings a known time apart, a subtraction process and some comparisons to fixed estimated values.

6. My model level car can be put under radio control merely by turning on the power to the ratio transmitter. It is selection which PWM signals (radio receiver sourced or PIC sourced) that is done by the DPDT coil driven relay switch. It is driving that relay switch coil that requires the SN7407 current driver.

7. I chose the HPWM to shape the steering and DC motor signals because by trial and error I found parameters that seemed to work at slower speeds. The signals continue no matter what the PIC code is doing. I do wonder whether I screw up a sequence each time I exercise a new HPWM command even if it is a repeat of the previous HPWM command. I do not understand the architecture details of HPWM command.

Ken

[ScaleRobotics]

Hi Walter, quick question. I am under the impression most Rx send their pulses sequencially, so when channel 1 is done, 2 starts, 2 done 3 starts... I know they are not always in numeric order, but none the less they wait until the last is don befor sending the next. At least with a little older equipment.

If my assumption is correct, in a 4 channel Rx, channel 4 could start anywhere between 4mSec to 8mSec after the start of the 20mSec frame. (channel 1,2 and 3 could be all min or all max). If this is true, They can't be too picky cuz 4 mSec is pretty darn big!. I would think it would take little effort to hit the 20mSec loop within .1msec.

so I was thinking in the main loop, don't measure the pulse from the Rx, just see if it went high. Then within a couple of instructions the "send pulses" routine would start. When thats done, acquire the next distance reading (10 mSec) then back to the old main loop waiting for the next trigger from the Rx.

Of course if my assumption is not correct, this was a nice typing excerise for me

Hello Bert,

I think all your assumptions are correct.

What I have seen is when pulses of 1 to 2 ms are not timed to occur about every 20 ms, the servos exhibit some eratic behavior. If some timing is attempted, and you get close-ish to the 20 ms the servo's are expecting, then yes, you will probably be just fine. But if you are going to go to the trouble of getting the timing close, why not use interrupts? It would allow the pic to be looking at different sensors, and not make it "dead" for up to 4 ms (1/5 of the time) while it sends out a pulse to two servo's.

[mackrackit]

I do not have any experience with the 18F46K20 but two things that I think would make it a good one for this project are:

Internal Oscillator Block:
- 8 user selectable frequencies, from 31 kHz to
16 MHz
- Provides a complete range of clock speeds
from 31 kHz to 64 MHz when used with PLL

And

Enhanced CCP module: In PWM mode, this
module provides 1, 2 or 4 modulated outputs for
controlling half-bridge and full-bridge drivers.