PBP projects for R/C models

[Kenjones1935]

OKAY,

With the help of the new-to-me oscilloscope I saw what I had been suspecting. The PIC's HPWM signal is not structured like the RC receiver signal. This explains why the PIC has not been able to command a smooth gradation of steering servo positions or wheel driving torque.

The RC receiver produces a pulse every 20 milliseconds (50 Hz). The pulses are between 1 and 2 milliseconds long. The PIC's HPWM machine produces a pulse every 3.8 milliseconds (263 Hz). The pulses are between 1 and 2 milliseconds long.

This matches scalerobotics comment of yesterday. It also matches the PBP textbook. Now that I understand what it is saying.

What I have does give me steering and wheel drive control. It is more bang/bang than I would like. It goes FAST. Which leads me to the problem of getting the car to steer left soon enough when approaching a corner in the wall.

The RC versus PIC control toggle works. Under RC control the car reacts like the original system. RC channel 3 provides the toggle signal. The PULSIN command does a fine job differentiating short from long PWM on this incoming signal. The code then controls the AZ8222 Subminiature DIP DPDT Relay via the SN7407N DIP MOS driver. This DPDT switch selects either the PIC output or the RC receiver output to send to the electronic speed control and the steering servo.

I'll make a video when I get the kinks out. I am afraid my prototyping technique is not robust enough to withstand the bumps needed to straighten out the feed back loops.

Thanks again for your help and encouragement.

Ken

[Kenjones1935]

Here is a video of my RC car taken today at our Radio Control Hobby Shop's race track.



Why does my code take so long to see and react to the information from the proximity sensors? There are no long PAUSE statements in my code. I am using HPWM to create the PWM control signals. Maybe I should take all the comments out of my code and post it for your consideration.

Ken

[Kenjones1935]

Here is my code as seen by WINDOWS notepad application. It does not make the PBP commands into capitals.

Were is the big delay?

Ken

[mackrackit]

WOW!!! That is cool!!! Very nice job so far.

After a quick look at the code I see a lot of things going on between range checks.
Just wondering what would happen it you setup a timer to trigger an interrupt routine.
The interrupt routine would be the range check. That way the range would be know almost instantly for corrections.

Or add range checking in between the IF/ENDIF statements. Places like this

aftermain:
gosub skidandreverse                           
frontfreetostopreverse = frontfreetostopreversesetup
 

if rangefront < frontfree then 'turn left as there is something ahead in front

gosub SteerFullLeft

goto main 
endif



IF rangeright = 0 then
endif

if rangeright > outertrack then 'turn right as we are too far away
gosub SteerHalfRight
endif


if rangeright < desiredtrack and oldrangeright < rangeright then
gosub SteerStraight  
endif 
        
          

if rangeright > desiredtrack and oldrangeright > rangeright then
gosub SteerStraight  
endif

[Kenjones1935]

I thought that a PIC runs at micro second speed. I thought that a loop clean through all my code would be indistinguishable by my human eyes.
The SRF05 have little red lights that flash each time they are pulsed. While the PIC is running the little flashes come about one per second.

How can that be? What is consuming the time?

Where can I get some information about the relation between PBP commands and real 16RF887 machine language code?

Ken

[mackrackit]

I am not good at figuring execution times but there is a thread around here some place talking about it... i can not find it

I do see a 200 pause, add that to the IF/THENs...

On the bench just to see you could remove some of the code and see it the LEDs blink faster. A primitive way yes. All I can say at the moment.

[Byte_Butcher]

What about PULSIN?

It has 16 bit resolution and at 4MHz, the PULSIN resolution is 10uS.
If you DON'T receive a pulse doesn't the PIC wait for 65535 x 10uS (0.655 seconds) before it "moves along" to something else?
Perhaps you need a define to determine the max PULSIN time?

IE:
PULSIN_MAX 1000 'Maximum counts allowed before pulsin times out


Just a thought.


steve