PBP projects for R/C models

[Kenjones1935]

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

[ScaleRobotics]

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:

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.

[Kenjones1935]

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.



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

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

[Kenjones1935]

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

[Kenjones1935]

I have built four cars.

Two 1/10 scale model level. My original and my new one. The new one is inherently much faster. They are both the same car from the same company.

Two toy level:
One 1/12 scale which is similar to Frits'.
One 1/10 scale which you saw in my video.

Maybe I should bring them all to the gym on a sunny day for a grand comparison.

Ken

[cncmachineguy]

What I am really trying to do is get some numbers together for things like : at half speed, must turn by XX inches or we will crash/skid. Also after watching your video again, the wall tracking appears to be a combination of 2 things. too much time between sensor readings, and too much turn (over driving)

'side note
My personal feeling is to get all the driving out of the int and in the main, but it might not matter. Just good coding. Imagine on your next project, when an int occurs, you could not tolerate a 4ms delay from what ever you were doing.
'end side note

Back on topic: so why not try increasing the sonar to every 50ms for each? This would more than double the resolution of your readings. Then we need to address more choices for how much to turn. A couple pages back you had asked if the math could be done digital. the answer is yes of course, just type more if statements. maybe instead of 2 stage steering, how bout 10% increments? fom 0-100%

something else picking at me is the timing. right now, every half sec, your int could take longer than 5ms. this is because of :2 servo updates could be 4 ms, plus at cnt=50*2 cnt2=4 so you have to ping sonar 2 also. Actually, come to think of it, sonar could last up to 30 ms!!!! so that is definantly too long for the 5 ms interupt.
sample int handler:

reload timer
cnt=cnt+1
cnt2=cnt2+1
flags=0
return

simular written in asm:

movlw _preload.lowbyte
movwf timer1L
movlw _preload.highbyte
movwf timer1H
inc _cnt
inc _cnt2
movlw 0
movwf _flags
return

I would have to check your datasheet again to make sure the inc's are correct and I'm not sure about using your PBP variables like that, but I think its correct.

I gave you the ASM equalviant so you could see what it is and if you want to use asm, you don't need to include PBP_include or whatever it is

[Kenjones1935]

Some time ago, I know not when, I purchased PIC MICROCONTROLLERS from MikroElektronika. Then I put it in a pile and forgot. It reappeared this morning. Looks like I have much of the ASM info I have been seeking.

My old HPWM system uses a TRIGGER: subroutine for SONAR triggers. The leds on the SONARs blink many times per second. They are too fast to count accurately. Each SONAR blinks at least 55 times in ten seconds. My non-mathematical guess is fast's enough if the steering servo and the wheel motor are reacting 'instantly'. Which they are not.

I think I have learned that there is no advantage keeping the PWM signal down to 50hz. All that is necessary is to calibrate the pulse widths as they appear in HPWM 2, xx, 50.