PBP projects for R/C models

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

[Kenjones1935]

A number of your suggestions push me to work quantitatively. I have been 'eying' my distances - measuring with outstretched hand tip of thumb to tip of little finger = about ten inches.

I would have a better handle on the behavior of my robocar if the SONAR measurements were in decimal inches. Right now I have a system of translating the echo pulse size to inches that I derived empirically. It would make my life easier if when I do a READ of numbers I have stored in EEPROM Data they came out as digital. How with PBP do I do that?

[cncmachineguy]

Thats an easy one Ken sinec your result is measured in 10uS steps, according to the spec for your sonar, "If the pulse is measured in uS, then divide by 148 to get inches". So all you have to do is inchesright = rangeright/148. And inchesfront = rangefront/148.

Now I am not sure you really need to convert it in your program. You could just look at the range results and use a calc so you can get a feel for it. your car won't care about the units.

EDIT: heres what keeps haunting me. lets assume most of the time the front is >33.783 inches (5ms pulse divided by 148). that means your interupt will retrigger while in the interupt. Maybe thats ok, as long as you have stack space for all the saves and returns. Also, the reason for changing the servo pulses to interupt drivin from HPWM was to be able to more properly command the servos.

[Kenjones1935]

I have been multiplying by .066 (in my head). Give or take a decimal point. I want to be able to READ the EEPROM and see inches. Not easy?? Is there a PBP routine that does this?

My interrupts are once every 5 millisec. I count 25 of them between each SONAR trigger. They are 125 millisec apart. The servos do work well with properly timed pulses, but they do not seem to react any quicker or with any finer precision. I have no accurate means of measuring this.

Thank you for thinking along with me. My computer experience was all digital data communication. Ultimately I retired from CISCO. I know nothing about real time control systems.

Ken