PBP projects for R/C models

[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

[Kenjones1935]

Originally I used a three channel R/C system. I kept the transmitter on all the time. Like you all suggested I could have used its outputs to trigger the PIC's PWM signals.

To take R/C control I tuned on channel 3. The receiver signaled the PIC that channel 3 was active. The PIC flipped the DPDT relay thereby steering the radio receiver's servo signals to the car.

This was not a good system because the model level car which is the basis of my work comes naturally with a 2 channel R/C. Adding the third channel was a big expense. Too much for our school systems.

Ken

[Kenjones1935]

From what I can tell the PIC18F45K20 is compatible with the PICKIT2 and MPLAB systems. I see that it comes in a 40 pin PDIP configuration.

Do you think I could unplug my 40 pin PIC16F887 and plug in a new PIC18F45K20 40 pin PDIP, do a bit of rewiring and be ready to go hardwarewize?

KEn

[cncmachineguy]

What does it give you that you don't have with the '887?

[Kenjones1935]

Scalerobotics wrote a while back:

A 12F683 design (would require a fair amount of changes to work on your chip)
http://www.picbasic.co.uk/forum/show...4998#post84998

This one could not be modified for your chip, and would require a 18F2431, or 4431.
http://www.picbasic.co.uk/forum/show...1961#post91961 (cleaner code than above)

And the one rmteo pointed out, which would require an 18 series chip: http://www.picbasic.co.uk/forum/cont...e-Servo-Driver (Darrels, so you can't really go wrong)

I am not enough conversant with the various Microchip models to talk intelligently about what I need or don't need.

Ken

[Kenjones1935]

After comparing the power and the 6 pin PC connector selections of the 44 pin 16F887 in the PICKIT2 and the 44 pin 18F45K20 in its StarterKit I think I can unplug one and plug in the other. I'll bet that will be the same for the 40 pin PDIP versions also. Good for our team.

Ken

[cncmachineguy]

ken, I think you should stick with the '887. You already have lots of experience with it and really it can suit your needs just fine.

If you want to jump up to the 18F, you may find yourself feeling like WOW, how do I do this. From what I have found, the 18F's just left me feeling like I had just stepped into a new world with regards to setting up and configuring it just to get it to run. You are doing basic stuff, ie no USB or 4 way PWM with encoder feedback. So the 887 can do that just fine.

BTW, I don't remember how fast you are running the PIC. Whats your osc speed?

[ScaleRobotics]

Great job Ken. What you are doing is the best way to learn about the interrupts. You have to play with them. That is a great start.

I believe both pulsin and pulsout are blocking commands. While they run, nothing else can happen on your chip. Once they are finished, sure, things resume and the program takes over. For a single servo, this is fine. But once you start throwing in sonar, multiple servos, other things you have thought of, and some you haven't thought of yet ... then you start to run out of time to do all these things using blocking commands. Especially if you want to go 20 mph.

As it stands, 20mph is half a foot for each 20ms (that is every chance you get to make an R/C correction). For your sonar, it takes a bit over 20ms, so if that is the only input, the best your chip can do is determine a correction every other 20 ms, or every foot.

In fact, just listening to the echo pulse on your sonar takes up to 25 ms, so that alone screws up everything if we use blocking commands like pulsin. (and double the screwed if you are listening to two of these!)

So, in the long run I think it is best to use interrupts for listening to your sonars, as well as outputting to your servo's. I can't remember how you are switching your transmitter for R/C control vs pic control, but that too might as well go on interrupts.

If you do, you have all kinds of time. You can be listening for two sonars at the same time, chewing on some math to determine the amount of turn, etc. If you want speed, it is most definitely the way to go.

That said, exactly what you are currently doing to learn is what I would recommend. Use the commands you know with interrupts to make things happen, and see how they work, and how to adjust them. Later on, when you feel comfortable with them, try adding in another interrupt timer to control a servo pulse.

[cncmachineguy]

Hi Walter, I love what you are saying about using int instead of pulsein/out. I am having trouble visualizing how to do that.

In my head, something has to be the overall clock, thats where my suggestion of 5msec came from. when I think about what you are saying, all I seem to be able to see is all these events started waiting for an int to make them stop. so I see like 6 different timers going all at once.

Or maybe you have 1 timer going for the 20ms, then do everything else sequencially using a different timer.

EDIT: The slow sonars are gonna definitly limit the top speed! Maybe as an upgrade once it works slowly, infra red emitters and detectors. This way they could also be used at the same time by sending different signals on each.

[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.