PBP projects for R/C models

[Kenjones1935]

cncmachineguy

Five millisec interrupts seems like a good plan. I will do a little more complicated counting and skipping. I think the SONARs should be less often if I am going to calculate velocity.

I wish I felt more at home with PBP. I'm tempted go to the freebe C, but that means starting all over again. It's been too many years.... Too lazy. sigh...

How do I get 5millisec interrupts from a FOSC/4 oscillator. I just do not understand section 6.0 of the '887 spec sheet.

Ken

[cncmachineguy]

cncmachineguy

Five millisec interrupts seems like a good plan. I will do a little more complicated counting and skipping. I think the SONARs should be less often if I am going to calculate velocity.

I'm not sure what needs to be more complicated, but I am prolly not seeing the whol picture. Velocity calc won't take long, I am sure it can still be done in the fourth block You have 5000 cycles to burn up before the next interupt.

I wish I felt more at home with PBP. I'm tempted go to the freebe C, but that means starting all over again. It's been too many years.... Too lazy. sigh...

I don't have any experience with PBP yet (but I will start programming in the next week or so ), all my programming has been in ASM. But from what I can see, there may be a few times when PBP isn't the best choice, but I don't know when that is. All languages have pros and cons. PBP seems to me to be a very good compilier. If I were you, I would just stick with it. I don't think it is where the difficulties are.

How do I get 5millisec interrupts from a FOSC/4 oscillator. I just do not understand section 6.0 of the '887 spec sheet.
Ken

For my part of being lazy, its not going to look at the datasheet for this processor. But the good news is I don't think I need to to answer this. I assume '887 has at least 1 16 bit timer you are not using. So go look at the timer section and figure out how to configure it as a counter. What I find to be the most important part about osc is this, it takes 4 clock cycles to execute an instruction (ASM). So that means if using 4Mhz clock, each instruction takes .000001 seconds, or 1/(osc/4). so for 5 msec, thats 5000 instructions. The timer/counter will increment 1 for every instruction. So heres the math:
16 bit counter = 65535
65535 - 5000 = 60535

so if you preload the timer with 60535, it will take 5000 counts to roll over. thats 5 msec. If timer overflow interupt is enabled, an int will be generated at 5 msec. Then in the handler, reload the timer with 60535 so another int will happen in 5 more msec. and so forth.

1 thing to keep in mind, 60535 assumes there is no lag between rollover and reload. In reality there is, it will take a few cycles to enter the interupt, then another few to reload and start the timer. so your number would adjust up by some small amount. for instance: if it takes 12 cycles to go from overflow to reload, the number you want to load would be 60535 + 12 = 60547. Make sense?

You can determine the exact number with some testing, before you reload the timer, grab the timer low byte and save it. then look at that number. it will be the number of cycles it took to get to the point where you grabbed it. Then replace the code to grab it with code to load it and the timing should be within 1 or 2 cycles.

I will let you chew on this for a while.
BTW, If you find there is not enough time between int for math and such, change the clock to 8Mhz, then you will be able to execute twice as many instructions between interupts.

[Kenjones1935]

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

[Kenjones1935]

Folks, I have been PBPing on a wing and a prayer (to quote an old WWII song). I need more
reference material. I compiled Mackrackit's code and got the following error. I do not know
where to go to chase it down.

Error 118 c:/~~~.asm 67: Overwriting previous address contents(2007)

Here's from the .asm file:

66 ASM?
67 __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF
68
69 ENDASM?

[mackrackit]

Remove this line

@ __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF

The above sets the configs in code space. You must be setting them in the *.inc file. Either way is good.

To read more about it
http://www.picbasic.co.uk/forum/cont...o-your-Program

[cncmachineguy]

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

Ken, I have been thinking about this, and IMHO the cleanest way may be to use 2 counters, one for the math/pwm, and 1 for the sonars

[Kenjones1935]

The PWM development works. Clearly LED #7 grows in magnitude through eight counts of #4.

The PWM is controlling the frequency of that signal's pulse. I do not unerstand
how the prescaler and the 8Mhz clock create the slowly blinking LED4.

KEn

[cncmachineguy]

There are plenty of machine cycles to do the math work and the control decisions. I think the 5 millisec interrupt timing should give me accurate timing for the PWM signals. I have no idea how much noise there is in the SONAR responses. I want to space them further apart in time so the trends are clear. Four triggers for each SONAR per second is my first guess.

Now to bed. Thanks.

Ken

I think once you have the PWM stuff sorted in your head, I feel like you may need to address this not knowing part. If your car is going a mere 10 mph, that's approx 14 feet per sec. If you only check each direction (front and side) four times a sec, your car will have traveled 3.5 feet!!! Ok maybe you are not going 10, but how bout 2 mph? That will still be 7.5 inches. At that rate, you will be correcting for things long past.

[Kenjones1935]

I have been forgetting that this car is capable of mph. Not just 10, but over 20. I am pushing some boundaries. I know nothing theoretical about control math. My gut tells me that knowing rate (ie trend) is of great importance -- somehow.....

Ken

[Kenjones1935]

Here's the WEB page for my SONAR SF05.

http://www.robot-electronics.co.uk/htm/srf05tech.htm

It says:
-10microsec trigger pulse
-produces an 8 cycle burst of 40khz sound (total duration 5millisec)
-can be triggered every 50millisec (20 per second)
-the beam pattern is conical.

Details! Details! Ain't technology grande!
Ken

[Kenjones1935]

cncmachineguy,

I sort of tried to do what you say:

goingforward:
HPWM 1,Straight,50
HPWM 2,Forward,50
'-------------------
keepgoingforward: '----Compare to right wall
IF rangeright > outertrack THEN
HPWM 1,QuarterRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,Straight,50
ENDIF

IF rangeright > desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,QuarterRight,50
ENDIF

IF rangeright < desiredtrack AND oldrangeright >= rangeright THEN
HPWM 1,QuarterLeft,50
ENDIF

GOTO main

I have three degrees of turning in each direction. My "oldrangeright" WORD is the previous reading of that SONAR. What I had not done was make this state machine "math" actually proportional. My present thinking is that with finer control I would get smaller oscillations.

Ken

[ScaleRobotics]

Ken, the one I suggested earlier http://www.acroname.com/robotics/parts/gp2y0a21yk_e.pdf... well, I just read the timing chart on page 4, and believe it or not, this infra red sensor is slower than your sonar! But, the good part is, you wouldn't have to wait for one to finish, before sensing the other. It would be nice to find a faster response sensor, if possible though, to allow your car to measure under 20 ms (at least for the side).

Here's a little bit about how they work http://www.societyofrobots.com/robot...p?topic=7991.0

[ScaleRobotics]

Ken, can you give us a bigger snippet?

[Kenjones1935]

I took my interrupt driven car to the gym this morning. It behaved about the same as my old HPWM design. When going slowly it just barely made the left turns at the corners. It did seem to go straight with less wiggle, but it still hit the wall occasionally.

It appears that the problem is reaction time. My delving into an interrupt driven system was motivated by the guess that randomly (in time) changing the HPWM command might be confusing the electronic speed control. On this account I detect little difference.

Another reason for regularly timed SONAR triggers was to take advantage of PID control. I have not coded that experiment. I am not convinced quicker reaction time will result.

I partially solved the TOGGLE problem by inserting the following code right after 'main:'. This system does not toggle control between PIC and RC, but it does stop (Brake) the car when the radio transmitter is turned ON. It is not a nice picture - a 75 year old man running around a gymnasium trying to tackle an out-of-control RC car.

The code samples channel3. This is the steering PWM signal from the car's radio receiver. There are pulses on that line as soon as the transmitter is activated.

main:
switchtoPIC = 2
WHILE switchtoPIC >= 2
COUNT channel3, 65, switchtoPIC
WHEELS = Brake
WEND

I am not sure what to do now. The reaction time seems quick enough on the bench.

[Kenjones1935]

In order to make sense of interrupt driven controls I need to know which PBP commands are 'blocking'. Why? During the blocking time no PWM pulses and no SONAR triggers are being emitted.

Ken