PBP projects for R/C models

[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

[Kenjones1935]

I have avoided translating to digital any of my measurements. I have used > and <, but no actual arithmetic. To go proportional per the PID, requires that I do arithmetic. HEX or digital, that is the question. I'd like to think in digital, may I?

I'm going to reveal my age. I wrote in machine language on the IBM 370 back in the last century. Well back in the last century. Since then it has been C, C++, shell, tcl. I am used to having a large library backup and writing in a modular fashion. Now it is PBP. I think I need to know more about ASM coding and the architecture of the PICs. What is the easiest (best) way to learn?

Ken

[Kenjones1935]

cncmachineguy, TIMER1 interrupt with a carefully chosen pre-set sounds good to me. I am not succeeding in figuring out how to do it. Page 32 in the 887 spec talks about PIE1. Page 70 talks about T1CON. I do not know where to look for an example.

Is there a collection of PBP and ASM code samples? If so, where?

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

[Kenjones1935]

Back a couple weeks one of you mentioned using infrared distance detector instead of a sonar detector. How do I find that posting? What was he product's name? How does it work? Or am I mistaken.

Ken

[ScaleRobotics]

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.

Interrupts are the way around blocking commands. With interrupts, you can be listening for 4 separate pulses in, while pulsing 4 separate pulses out, while listening for the sonar ping, and blinking a few led's, etc, etc. With PicBasic commands alone, you are still stuck at pulsin, listening for a single pin for x duration. Don't get me wrong, blocking sounds so bad, but what it really does, is give the user a simple way do some complex things, with a single line of code. And without having to read about 50 extra pages of the data sheet. This is one of the best features of PicBasic. But there is a time for interrupts. Pulsin, Pulsout, PWM, serin, serout, freqout, count, debug, debugout are a few blocking commands.

That said, they will not block an interrupt. An interrupt, does what it does best. It butts in an interrupts, gets out, and then whatever PicBasic command it was in the middle of completes.

[Ioannis]

Up to this moment I have not seen any specifications of the cars.

What speed they reach, how fast thay accelerate and how fast do they stop.

If youhave this figures then you may do the calculations about reaction time and maximum speed to reach in order to hit the brakes in time, before crashing on the walls.

Ioannis