PBP projects for R/C models

Printable View

Show 40 post(s) from this thread on one page

- 20th November 2010, 03:01
mackrackit

Quote:

How'd that work out for you?

Worked well until I pulled up to the checkpoint doing it. Thought they were going to take me to secondary...

Ken,
Here is code using DT's INTs giving an interrupt at 200 Hz.
All I did was tweak Darrel's blinky example.

Code:

'FL PIC16F887 '16F887 DT INT RUPT '44 PIN DEMO BOARD 'REMOVE THIS LINE IF NOT SETTING THE CONFIGS IN CODE SPACE @ __config _CONFIG1, _INTRC_OSC_NOCLKOUT & _WDT_ON & _MCLRE_OFF & _LVP_OFF & _CP_OFF OSCCON = %01100000 '4 Mhz DEFINE OSC 4 LED1 VAR PORTD.4 wsave VAR BYTE $70 SYSTEM INCLUDE "DT_INTS-14.bas" ' Base Interrupt System INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR1_INT, _ToggleLED1, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM '5.0 mSec OR 200 Hz INTERRUPTS T1CON = %00000001 'Prescaler = 1:1, TMR1ON 'PRELOAD 60543 PreLoad VAR WORD PreLoad = 60543 TMR1L = PreLoad.LowByte TMR1H = PreLoad.HighByte @ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts Main: 'DO WHATEVER YOU WANT HERE PAUSE 1000 HIGH PORTD.7 PAUSE 1000 LOW PORTD.7 GOTO Main '---[TMR1 - interrupt handler]-------------------------------------------------- ToggleLED1: TOGGLE LED1 TOGGLE PORTC.6 'CONNECTED TO METER TMR1L = PreLoad.LowByte ' Load the timer with preload value. TMR1H = PreLoad.HighByte @ INT_RETURN
- 20th November 2010, 03:21
cncmachineguy

Hi Ken, Just looked over section 6. I always think about the prescaler like this:

With no prescaler, timer increments as I posted earlier, Every 4 counts of the ocs will inc the timer by 1. If you have prescale set to 2, timer will inc every 8 counts, or half as fast. set to 4 it will inc every 16 counts or 1/4 speed, and set to 8, timer will inc every 32 counts or 1/8 speed. does this make sense?

So in summary, the prescaler is really a clock divider for the timer.
- 20th November 2010, 03:32
cncmachineguy

Bravo dave

Quick question, how did you determine the preload value? I mean to say, I understand what it represents, just how did you determine the offset?
- 20th November 2010, 03:51
mackrackit

I cheated :p
http://www.picbasic.co.uk/forum/cont....-PICMultiCalc
- 20th November 2010, 23:20
Kenjones1935

Two steps forward, One step backward

Not much luck reading DT_INTS-14. I do not understand ASM and all the macros that have been written.

Soooo I installed the two blinky programs and they both looked correct. I activated the LOGIC TOOL from PICKIT2 and looked carefully at the 20millisec square wave. Close enough for government work. Next I changed the

Quote:

TOGGLE PORTC.6 'CONNECTED TO METER

command to

Quote:

PWM PORTD.7, 127, 1

and hooked up Channel 2 of the LOGIC TOOL to PORTD.7.

I expected to see a single pulse every 20millisec. I even hoped that the pulse would be 1.5millisec long.

I see many pulses seemingly not related to the edges of the interrupt driven 50Hz square wave. I would show you all a picture, but my FastStone Capture is screwed up.

Is there any PWM-like command that makes one pulse ranging from 1millisec to 2millisec in 256 gradations?

Ken
- 20th November 2010, 23:27
mackrackit

Quote:

carefully at the 20millisec square wave

That is odd, I must have something off...

Quote:

Is there any PWM-like command that makes one pulse ranging from 1millisec to 2millisec in 256 gradations?

The PULSOUT command might do the trick?
- 21st November 2010, 02:51
Kenjones1935

1 Attachment(s)

Here's a snap shot.

Here is what my LOGIC TOOL displays. The only change in the code is this substitution of a PWM command.

Code:

ToggleLED1: TOGGLE LED1 PWM PORTD.7,127,1 TMR1L = PreLoad.LowByte ' Load the timer with preload value. TMR1H = PreLoad.HighByte @ INT_RETURN

Attachment 4961
- 21st November 2010, 03:37
Kenjones1935

1 Attachment(s)

Hard to explain...

I do not understand this result. The gist is that the pulse generating command seems to influence
the interrupt frequency. Here is exactly our same code with a PULSOUT PORTD.7, 50 inside the
interrupt routine.

Code:

OSCCON = %01100000 '4 Mhz DEFINE OSC 4 LED1 VAR PORTD.4 wsave VAR BYTE $70 SYSTEM INCLUDE "DT_INTS-14.bas" ' Base Interrupt System INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR1_INT, _ToggleLED1, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM '5.0 mSec OR 200 Hz INTERRUPTS T1CON = %00000001 'Prescaler = 1:1, TMR1ON 'PRELOAD 60543 PreLoad VAR WORD PreLoad = 60543 TMR1L = PreLoad.LowByte TMR1H = PreLoad.HighByte @ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts Main: 'DO WHATEVER YOU WANT HERE ' PAUSE 1000 ' HIGH PORTD.7 ' PAUSE 1000 ' LOW PORTD.7 GOTO Main '---[TMR1 - interrupt handler]-------------------------------------------------- ToggleLED1: TOGGLE LED1 pulsout PORTD.7,50 ' PWM PORTD.7,127,1 ' TOGGLE PORTC.6 'CONNECTED TO METER TMR1L = PreLoad.LowByte ' Load the timer with preload value. TMR1H = PreLoad.HighByte @ INT_RETURN

And here's the LOGIC TOOL picture.

Attachment 4962
- 21st November 2010, 09:53
mackrackit

Looks like the PULSOUT is taking longer than the interrupt. And of course I do not have the interrupt timed correctly.
Hopefully someone will straighten me out on the math.
- 21st November 2010, 09:53
cncmachineguy

According to the manual, each "PWM cycle" takes about 5ms with a 4Mhz clock. My guess is the first example has the interupt routine taking longer than the time between interupts. And you are prolly getting lucky to ever leave the handler at all!

The second example using pulseout, looks much better. Hard to count the lines, is it the correct timing?

Now remember, you don't want the pulseout in the interupt handler.
- 21st November 2010, 11:35
Kenjones1935

1 Attachment(s)

LOOKs correct now

The correct picture is this one. PULSOUT is in the interrupt handler only after the RESET TIMER action. Why is this bad?

Attachment 4964
- 21st November 2010, 12:17
cncmachineguy

The general rule is to get in and out of an interupt as fast as possible. But in your case, the problem is a bit different. the pulse for the servo's should be every 20 msec. you have an interupt every 5 msec. so you are updating the servo 4 times as fast as you want to.
- 21st November 2010, 13:49
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.
- 21st November 2010, 14:03
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.
- 21st November 2010, 14:22
ScaleRobotics

That's a great question Bert. Well, you being an asm guy will probably get a few laughs at my first real attempt at using more than 20 lines of asm in my program. But I will show you anyway. This uses Timer1 for PWM measurement (read servo channels in). Basically, Timer1 runs non-stop, and when a state change interrupt is detected, the timer value is read. The start timer value is subtracted from the stop timer value to get the pulse width. This is done for all channels. After all channels are read, it is time to output pulses to the servos. So I do not have a 20 ms timer, it cheats and uses the R/C receiver as the 20ms timer. If all channels have been read, it must be 20 ms. The second interrupt is timer0. That is used for pulse duration on the output. I made the pulse base 1ms, then the timer gets set for a second interrupt to complete the pulse.

Here is an example of reading 5 R/C channels, and outputting 4 R/C channels using two timers: http://www.scalerobotics.com/PWMpassthrough.html

Something like that could be used. And in addition to detecting servo pulse in, and interrupt on change could time a pulse from two sonars at the same time. This could also read timer1 start and end times, so no additional timers would be needed. If you did not want to use the R/C receiver as the 20 ms timer, then timer2 could be used. But that is the last timer on this chip. But then, you can still throw more on those two other timers, if you wish.
- 21st November 2010, 15:09
cncmachineguy

Walter I never find things to laugh about in code that works! Besides, 20 lines of asm isn't really much. Thats one of the reasons I wanted to convert to a high level language. Fewer lines to type :)

Ken is worried about firing both sonars at the same time cuz he may not know who the source is when it comes back.
- 21st November 2010, 15:25
ScaleRobotics

Quote:

Originally Posted by cncmachineguy

Ken is worried about firing both sonars at the same time cuz he may not know who the source is when it comes back.

Ken was thinking smarter than I. Good point. Maybe keep your sonar for front view, and for side view something like this: http://www.acroname.com/robotics/parts/gp2y0a21yk_e.pdf . Or use infra sensors for both, since you can get updates every 20 ms to keep up with the fastest that you can change your servos. Besides, they are cheaper than sonar! You do need to pick your distance range though. The one I gave a link to was 4 inches to 30 inches, which seemed ok for following a wall. If its 30 inches or more, get closer....
- 21st November 2010, 15:28
Kenjones1935

Blocking commands

Yes, "blocking commands" is exactly the word. I figured that out while lying in bed with the LOGIC TOOL image in my head. I could see that the length of the pulse was being added to the interrupt time. I could not find any information on that in any of my documents. Please tell me where in which .INC file is the ASM code which is activated by PULSOUT. Without access to those details, PBP is just guess work.

My plan is to insert counters into the interrupt service routine. Every four interrupts (20millisec) do a PULSOUT. Every 25 interrupts, TRIGGER one SONAR or the other alternatively. My TRIGGER is built of HIGH and LOW commands totaling 10 microseconds (or so). These are not blocking.

I'll give this a try and see how the car reacts (if at all.....)

Thanks again for the support.

Ken
- 21st November 2010, 15:50
ScaleRobotics

Quote:

Originally Posted by Kenjones1935

Please tell me where in which .INC file is the ASM code which is activated by PULSOUT. Without access to those details, PBP is just guess work.

I would approach it a different way, and avoid that pain. Especially since interrupts may grow on you, and you may get rid of your pulsin/out someday :)! Say you want an interrupt every 20 ms and have a single servo to control, but you want to use pulsout since you are still learning interrupts. Since we can be a little off on our 20 ms, as Bert mentioned, the easy way is to say the average servo pulse is 1.5ms, so I need to interrupt every 18.5 seconds. If you add in the time of your pulsout, it will be very close to 20 ms, and your servo will be happy and grateful.
- 21st November 2010, 16:21
ScaleRobotics

Quote:

Originally Posted by Kenjones1935

My plan is to insert counters into the interrupt service routine. Every four interrupts (20millisec) do a PULSOUT. Every 25 interrupts, TRIGGER one SONAR or the other alternatively. My TRIGGER is built of HIGH and LOW commands totaling 10 microseconds (or so). These are not blocking.

If that plan is just for testing, it sounds like a great plan. But if you plan to use it while doing 20 mph, you will be doing a "ping" every 3.66 feet, or 8 times per second. If your reflexes are quick, you might be able to blink your eyes quickly at about 8 times per second. While your R/C car is doing 20 mph around a turn, try blinking your eyes as fast as you can, while steering your R/C car. I think your results might be similar to the ones we saw in the video.
- 21st November 2010, 16:28
cncmachineguy

see, this is one of the reasons I love this stuff. To do what Walter describes, with the same resources (1 interupt and pulsout), I would set my timer for 20 ms. My int handler would set a flag, and I would get out. Then in my Main, if the flag is set, hit my pulseout routine and clear the flag. This way I would get a new pulse every 20 ms on the dot. But mostly cuz I just always want to get out of the handler. I seem to feel like by name "Interupt" I was busy doing something before I went there. Maybe it was important and I need to get back to it.

As for PBP being guess work, I don't think thats the case. Pulseout/in serout/in and the rest of them, take exactly as long as you think. if you PULSEOUT for 1 ms, thats how long it will take.
- 21st November 2010, 20:04
cncmachineguy

Walter, I like your idea of the 18.5 ms plus servo out to make up the 20ms loop. I need just that for my project. I will want to use 1 timer to control the loop and the pulse, so that seems the best idea to me.
- 22nd November 2010, 03:58
Kenjones1935

I've come to a screeching halt

"Verification of Program Memory failed at address 0x00000000"

I tried some old code that I KNOW loaded. Not today.

I swapped out the PIC. That was not the problem. I reseated all the patch wires. That made no difference.

I restarted the PICKIT2 programmer. That did not help.

I tried with a PICKIT2 board - the one on which I ran the blinkys - no problem. It liked to load and blink.

Where do I start?

Ken
- 22nd November 2010, 04:24
Kenjones1935

Fixed it!!

It was a wire I had added to give the LOGIC TOOL more information. I do not understand why the PICKIT objected. But all is well.

The interrupt driven system sort of works. We'll see more tomorrow.

Thanks again for your help and support.

Ken
- 22nd November 2010, 16:16
Kenjones1935

Works as good as before

I've got the system working interrupt driven. I do not have proportional controls implemented - yet.

On the bench the car seems as responsive as before. We'll see when I take it to the gym.

One thing I have not figured. How, now, to I disable interrupts when the radio transmitter has been
turned ON? At the very end of this code pack is my old WHILE loop that worked - in the day.

Code:

symbol trigright = PORTB.0 ' Define output pin for Trigger pulse symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse symbol trigleft = PORTB.3 ' Define output pin for TRigger pulse symbol echoright = PORTC.6 ' Define input pin for Echo pulse symbol echofront = PORTC.5 ' Define input pin for Echo pulse symbol echoleft = PORTC.7 ' Define input pin for Echo pulse SYMBOL channel3 = PORTC.4 ' Define input pin for Channel 3 PWM ' PORTC.0 'High is R/C. Low is PIC control TRISC = %11110000 DATA $C0,$0C 'his version's checksum goes here. define ADC_BITS 8 TRISA.0 = 1 'PORTA.0 as analog input for POT ANSEL.0 = 1 ADCON1 = %00000000 'left justified ' We use low eight bits. 0 -> 255. ADCON0 = %01000001 'divide 4Mhz clock by 8. '------------ OSCCON = %01100000 '4 Mhz DEFINE OSC 4 LED1 VAR PORTD.4 wsave VAR BYTE $70 SYSTEM INCLUDE "DT_INTS-14.bas" ' Base Interrupt System INCLUDE "ReEnterPBP.bas" ' Include if using PBP interrupts ASM INT_LIST macro ; IntSource, Label, Type, ResetFlag? INT_Handler TMR1_INT, _ToggleLED1, PBP, yes endm INT_CREATE ; Creates the interrupt processor ENDASM '------------ '5.0 mSec OR 200 Hz INTERRUPTS T1CON = %00000001 'Prescaler = 1:1, TMR1ON 'PRELOAD 60543 PreLoad VAR WORD PreLoad = 60543 TMR1L = PreLoad.LowByte TMR1H = PreLoad.HighByte '@ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts '------------ WHEELS VAR WORD STEERING VAR WORD 'The following may be a big part of the wall hugging probllem Potread var word Forward var word ' was fixed 122. Now sweeps 7 steps. See Checkpot HalfForward VAR WORD ' Potread/2 +x + 1. See Checkpot Back VAR WORD 'See Checkpot HalfBack VAR WORD 'See Checkpot Brake con 100 'Only used just before Main. Straight con 150 '? Right CON 130 '? HalfRight con 135 '? QuarterRight CON 140 '? Left con 170 '? HalfLeft con 165 '? QuarterLeft con 160 '? '--------------------------- frontdanger var word stopreversing var word frontfree var word desiredtrack var word outertrack var word '--------------------------- 'some of the following are not used. CNT VAR BYTE 'counts interrupts for TRIGGERS cnt = 0 CNT2 var byte ' counts interrups for wheels and steering CNT2 = 0 b0 VAR word rangeright var word rangeright = 100 'about 6 inches preset rangefront var word oldrangeright var word oldrangefront var word reversing VAR WORD reversing = 0 switchtoPIC VAR WORD switchtoPIC = 1 radiocontrol var word radiocontrol = 0 steeringleft var word steeringleft = 0 steeringright var word steeringright = 0 '------------------- Checkpot: ' I think Potread goes from 0 to 6. adcin PORTA.0, Potread Potread = Potread/37 Forward = 160+Potread HalfForward = 155+(Potread/2) 'seems to work. Back = 140-Potread HalfBack = 145-(Potread/2) '---------- frontdanger = 210 + Potread*55 '210-540, 14-36 inches stopreversing = 180 + Potread*25 '180-330, 12-22 inches frontfree = 700 + Potread*60 '700-1060, 48-70 inches desiredtrack = 180 + Potread*20 '180-300, 12-20 inches outertrack = 360 + Potread*15 '360-450, 24-30 inches '---------- write 2, word Potread write 4, word frontdanger write 6, word stopreversing write 8, word frontfree write 10, WORD desiredtrack write 12, word outertrack '------------------- @ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts '------------------- low PORTC.0 'hpwm 1,Straight,50 STEERING = Straight 'hpwm 2,Brake,50 WHEELS = Brake 'pause 4000 'Wait so I can put the car down and get out of the way. '------------------- main: CheckIfInDanger: if rangefront < frontdanger then STEERING = Straight WHEELS = back reversing = 1 goto reverseoutoftrouble ' loop till this is secured endif '------------------- tryleftturn: if rangefront < frontfree then 'something ahead - turn hard left. STEERING = left WHEELS = halfforward steeringleft = 1 goto main 'loop till this is secured endif '------------------- goingforward: STEERING = straight WHEELS = forward '------------------- keepgoingforward: '----Compare to right wall if rangeright > outertrack then STEERING = quarterright endif if rangeright < desiredtrack and oldrangeright < rangeright then STEERING = STRAIGHT endif if rangeright > desiredtrack and oldrangeright > rangeright then STEERING = STRAIGHT endif if rangeright > desiredtrack and oldrangeright < rangeright then STEERING = QUARTERRIGHT endif if rangeright < desiredtrack and oldrangeright >= rangeright then STEERING = QUARTERLEFT endif goto main '------------------------- reverseoutoftrouble: while rangefront < stopreversing STEERING = RIGHT WHEELS = RIGHT wend if rangeright > outertrack or rangeright < desiredtrack then STEERING = LEFT steeringleft = 1 WHEELS = HALFFORWARD endif goto main '***********INTERRUPT HANDLER************ ToggleLED1: TMR1L = PreLoad.LowByte ' Load the timer with preload value. TMR1H = PreLoad.HighByte TOGGLE LED1 '------------ ' Trigger SONAR alternatively every 25 interrupts if CNT=25 then pulsr: oldrangeright = rangeright ' produce 10uS trigger pulse (must be minimum of 10uS) low trigright HIGH trigright high trigright high trigright LOW trigright 'zero could be legal below pulsin echoright,1,rangeright 'measures the range in 10uS steps endif '------------- if CNT=50 then pulsf: oldrangefront = rangefront low trigfront hIGH trigfront high trigfront high trigfront LOW trigfront pulsin echofront,1,rangefront ' measures the range in 10uS steps CNT=0 endif CNT=CNT+1 '-------------- if cnt2=4 then ' PWM pulses are between 1 and 2 millisec. low PORTC.1 low PORTC.2 pulsout PORTC.1,WHEELS PULSOUT PORTC.2,STEERING CNT2=0 endif CNT2=CNT2+1 @ INT_RETURN checkchannel3: 'works with four AA batteries pack. Radio receiver puts pulses 'on this line whenever the transmitter is turned ON. switchtoPIC = 2 while switchtoPIC >= 2 count channel3,65,switchtoPIC high portc.0 wend low portc.0 end
- 22nd November 2010, 19:15
cncmachineguy

Code:

@ INT_ENABLE TMR1_INT ; enable Timer 1 interrupts

that line turns the interupt on, or enables it. there must be a simular line like INT_DISABLE maybe to turn it off.
turn it off when the while loop is true, or when under Tx control. then turn it back on when Tx control is over.
- 22nd November 2010, 23:10
Kenjones1935

That's what I tried.

For some reason disabling interrupt during the WHILE loop did not work. I could have done
something stupid.

What I want to know is where is the list of "blocking" commands. I do not see such a list in
my PBP book. For example, is COUNT a blocker?

Here is what I coded immediately after main:
main:

'-------------------

Quote:

checkchannel3:
'worked with four AA batteries pack. Radio receiver puts pulses
'on this line whenever the transmitter is turned ON.
switchtoPIC = 2
while switchtoPIC >= 2
@ INT_DISABLE TMR1_INT
count channel3,65,switchtoPIC
high portc.0
wend
low portc.0
@ INT_ENABLE TMR1_INT

Ken
- 23rd November 2010, 03:08
ScaleRobotics

Ken, can you give us a bigger snippet?
- 23rd November 2010, 22:40
Kenjones1935

Seems litte different than the HPWM technique

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.
- 24th November 2010, 00:47
Kenjones1935

Serious problem...

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
- 24th November 2010, 02:57
Kenjones1935

Infrared distance detector?

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
- 24th November 2010, 04:47
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
- 24th November 2010, 06:48
ScaleRobotics

Quote:

Originally Posted by 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.

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.
- 24th November 2010, 07:49
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
- 24th November 2010, 16:30
ScaleRobotics

Looking back at one of the examples you gave of this idea (from kind of the beginning), Wall Racers used no interrupts. It was all done using basic statements, and blocking commands. These cars seem to go a bit slower than yours though, if I were to guestimate. Is the accuracy and speed they have in this video what you are aiming for? I think I saw them hit a wall here and there ... maybe. I am guessing around 4 to 5mph in the video?

http://vimeo.com/1162192

Here is the code they used in PicAxe Basic.

Code:

' WALLRACERS By Frits Lyneborg ' Right turns on the track must be gentle (this code does not skid/slide on them), left can be hard (skid/slide is build in) ' <"left"> opposite just <left> in the remarks means that wheels are turning left, but direction is backwards, so "left" is actually moving right symbol trigright = 0 ‘ Define output pin for Trigger pulse symbol trigfront = 1 ‘ Define output pin for Trigger pulse symbol echoright = 7 ‘ Define input pin for Echo pulse symbol echofront = 6 ‘ Define input pin for Echo pulse symbol rangeright = w1 ‘ 16 bit word variable for range symbol rangefront = w2 ‘ 16 bit word variable for range symbol oldrangeright = w3 ‘ 16 bit word variable for range symbol differencerangeright = w4 ‘ used to calculate how hard a turn is symbol frontfreetostopreverse = w5 symbol turnon = 7 ' the relay that if on makes the car turn to one side symbol steerto = 6 ' the relay that if on turning is on, then decides the direction symbol stopon = 5 ' the relay that if on makes the car stop symbol forrev = 4 ' the relay that if on and is not on stop makes the car reverse symbol frontdanger = 200 ' At what point should we realize we are getting too close? (note that breaking takes a lot, so this should be much higher than the real distance) symbol frontfreetostopreversesetup = 201' must be higher than "frontdanger" - higher value means more backing out after close encounters symbol frontfree = 350' set higher to turn earlier when something is in front, and get less skid-turning, but more likeliness to miss sharp right turns symbol desiredtrack = 100 'symbol innertrack = 50 symbol outertrack = 150 high stopon wait 5 low stopon ''''''''''' main: oldrangeright = rangeright gosub puls gosub skidandreverse if rangefront < frontfree then 'turn left as there is something ahead in front high turnon low steerto goto main 'this is second priority above all loop till this is secured end if '' Normal drive to the right - we are too far away from the lane, so turn. This code contains no right-slide-turn for cool long right turns without slides to give more of a race-feeling oposed to zig-zag and robot-behaviour, so space must on thr track be higher than turning-radius in front of right turns - or the car vill turn left and miss the right turn. if rangeright > outertrack then 'turn right as we are too far away high turnon high steerto end if ' Now we know that there is nothing closer than (frontdanger and) frontfree - and we are on track - so let's keep on track '*** ' First check if we are on the right path and have a positive development. ' If so, then keep us there by straightening up wheels that might be turned if rangeright < desiredtrack and oldrangeright < rangeright then low turnon low steerto ' drive straight forward as we are on the wrong side of desired track, but we are moving the right direction end if if rangeright > desiredtrack and oldrangeright > rangeright then low turnon low steerto ' drive straight forward as we are on the wrong side of desired track, but we are moving the right direction end if '*** ' Then see if we are moving away from the good path and do something about it if so. if rangeright > desiredtrack and oldrangeright < rangeright then high turnon high steerto 'turn right as we are in the outer lane and getting away end if if rangeright < desiredtrack and oldrangeright > rangeright then high turnon low steerto 'turn left as we are in the inner lane and getting closer end if goto main '*************************************** yankright:' there was an empty space to the right. Skid right to be sure we are turning if it is a turn in the track '''''''''' Skidsecure start high turnon high steerto 'turn right pause 25' wait short for the car to give a small yank to the left before reversing.. all to start a skid turn to the right side '''''''''' Skidsecure end high forrev 'set in reverse gear Skidright: b0 = 0 do gosub puls b0 = b0 +1 loop while rangefront > frontfreetostopreverse and rangeright > outertrack and b0 < 20 'dildo: 'high stopon goto dildo low forrev 'set in forward gear pause 300 return '*************************************** '*************************************** reverseoutoftrouble: '''''''''' Skidsecure start high turnon low steerto 'turn left pause 25' wait short for the car to give a small yank to the left before reversing.. all to start a skid turn to the right side '''''''''' Skidsecure end high forrev 'set in reverse gear rev: frontfreetostopreverse = frontfreetostopreversesetup keepreversing: frontfreetostopreverse = frontfreetostopreverse - 3' making sure we are not backing and reversing and going nowhere, as we have a wall behind us if frontfreetostopreverse < 50 then gosub stuckerror end if gosub puls if rangefront < frontfreetostopreversesetup then if rangeright < desiredtrack and oldrangeright < rangeright and rangefront > frontdanger then low turnon low steerto ' drive ahead as we are on the wrong side, but we are moving the right direction and we are not too close end if if rangeright > desiredtrack and oldrangeright > rangeright and rangefront > frontdanger then low turnon low steerto ' drive ahead as we are on the wrong side, but we are moving the right direction and we are not too close end if if rangeright > desiredtrack and oldrangeright < rangeright and rangefront > frontdanger then high turnon low steerto 'turn left (reversed) as we are in the inner lane and getting closer end if if rangeright < desiredtrack and oldrangeright > rangeright then high turnon high steerto 'turn right (reversed) as we are in the outer lane and getting away end if goto keepreversing end if high turnon low steerto 'turn "left" low forrev 'set in forward gear return '************* skidandreverse: if rangefront < frontdanger then ' too close, reverse out of trouble! gosub reverseoutoftrouble goto main ' this is first priority above all - loop till this is secured end if return '************* puls: pulsout trigright,2 ‘ produce 20uS trigger pulse (must be minimum of 10uS) pulsin echoright,1,rangeright ‘ measures the range in 10uS steps pulsf: pulsout trigfront,2 ‘ produce 20uS trigger pulse (must be minimum of 10uS) pulsin echofront,1,rangefront ‘ measures the range in 10uS steps pause 10 ‘ recharge period after ranging completes return stuckerror: high stopon low forrev low steerto low turnon dadaa: goto dadaa
- 24th November 2010, 16:48
Kenjones1935

Good thinking....

You are right about the specs on the RC cars. I do not know that they officially exist. My car weights exactly four pounds. Has good rubber tires with plenty of friction against the gymnasium floor. I have been told that it is good for at least twenty miles per hour, but I have no means to verify it. The car is a HPI-Racing 1/10 Scale, 4 wheel drive, Sprint model.

Regarding the blocking commands. All I want to know is which ones block TMR1 and hence TMR1 based interrupts? Judging from my LOGIC TOOL images PULSIN blocks. True?

Ken
- 24th November 2010, 17:21
ScaleRobotics

Quote:

Originally Posted by Kenjones1935

Regarding the blocking commands. All I want to know is which ones block TMR1 and hence TMR1 based interrupts? Judging from my LOGIC TOOL images PULSIN blocks. True?

I thought I read somewhere that most of the commands which involve time, like Pulsin, Pulsout, etc, use timer1. But I can't find anything documenting that. Maybe someone can correct this for me? I did a little testing, and if you put your 20 ms timer on Timer2, it will be unaffected by pulsout, and I expect pulsin as well. These blocking commands DO NOT block an interrupt. For instance, you can have a pause 10000 in your main, while an interrupt gives you a heartbeat LED indication every second. But they will interfere if they are trying to load the same timer with a value.

EDIT: Turns out I was way off base here. Here Darrel corrects me:

Quote:

The only PicBasic command that uses a timer is HPWM, which uses Timer2.
No PBP commands use Timer1 unless you tell it to.

And all PBP commands are blocking (while they execute).
They might interface with harware peripherals that are doing other things at the same time, but the statements themselves are blocking.

As you pointed out though, they don't block interrupts.
And it's the commands that do software based timing that get disturbed by the interrupts.
PAUSE, PULSIN/OUT, RCTIME, SEROUT/IN(2) etc.
They stop keeping time while the interrupt code executes, so all that time gets lost.

When using interrupts, you should use Hardware Timers to do things like PAUSE or PULSIN, and the USART instead if SEROUT/IN(2).
And when not using interrupts, use the easier versions (PBP), or still use the hardware which are the NON-BLOCKED functions.

You can do PULSIN with the CCP module at the same time you're sending serial data to a PC without any interrupts.
- 24th November 2010, 17:34
Kenjones1935

Yes, Frits' code was not interrupt driven

You are correct. I got the whole idea from Frits. I have learned some since then.

1. His cars were 1/12 scale toy level cars. They are not fast by RC standards. They have only bang bang steering and wheel control. They are small. They do not have enough room for much electronics to be added. Frits removed the RC receiver. I tried the Frits thing on a 1/10. I was not successful. The 1/10 car is much faster than the 1/12 car. This video shows the difference.

http://www.youtube.com/watch?v=Emsf46WpctI

I have been asking for suggestions for a 'game' that can be played with the 1/10 Toy level cars. They are $50 each vs $200 for a model level car.
I thought up the 'swarm the teacher with the light bulb' game to be played with multiple light sensing diodes on the roofs of the cars. I have been diverted by this idea of interrupt driven model level control.

Thanks for everything.

KEn
- 24th November 2010, 19:51
cncmachineguy

Ken, Sorry, I'm not very good at thinking up games. Follow the light sounds like fun to me. I have a lot of things I want to comment about your current effort, but time won't let me right now. I will tonight. Let me say this though, I think you are on the right path.

I wonder if you can do some testing for us. I want to help you get better control over the car, but need some parameters.

1. How close can you get to a wall at top speed and still be able to execute a turn?
2. How close do you want to be to the right wall?
3. At what percentage of speed can you still make a hard left without the car skiding?
4. If the Tx is NOT on, will there be any pulse from the RX?

Maybe you can put some tape lines on the floor and film that section of the floor to capture speed and distance from the wall. Of course this will be under manual control, So we will also get to see your reflexes-lol

I for 1 believe you can get the car to go much faster and be WAY more accurate!!
- 24th November 2010, 20:13
Kenjones1935

Can't get to the gym for a couple of days.

My gymnasium has no electricity. Need bright sunny day to take video. Tomorrow is Thanksgiving and the following day is occupied by family stuff.

The model car does not skid. The toy car does.

In my older model level car, the receiver created no pulses on channel3 input when the transmitter was off. My newer model level car, somehow has noise on that line. The circuits are the same. I have not been able to figure out the difference.

I started trying to code my 1/10 toy car to do a skid turn then I realized that it's real problem is the subtle issue of staying parallel to the wall. I think you have a real good idea asking me to see whether I can control that car with its RC inside my gym.

Thanks for the encouragement. I have been bumping my head for a while.

Ken

Show 40 post(s) from this thread on one page