PBP projects for R/C models

[mackrackit]

I am not good at figuring execution times but there is a thread around here some place talking about it... i can not find it

I do see a 200 pause, add that to the IF/THENs...

On the bench just to see you could remove some of the code and see it the LEDs blink faster. A primitive way yes. All I can say at the moment.

[Byte_Butcher]

What about PULSIN?

It has 16 bit resolution and at 4MHz, the PULSIN resolution is 10uS.
If you DON'T receive a pulse doesn't the PIC wait for 65535 x 10uS (0.655 seconds) before it "moves along" to something else?
Perhaps you need a define to determine the max PULSIN time?

IE:
PULSIN_MAX 1000 'Maximum counts allowed before pulsin times out


Just a thought.


steve

[Ioannis]

Is it possible to place the car on a stand and the camra above it. Then have an object approaching form the side and back again so we could see the reaction of your sytem.

Then I would suggest the ue of he PID routines of Henrik that are on this link to obtain smooth control: http://www.picbasic.co.uk/forum/showthread.php?t=5874

Ioannis

[Kenjones1935]

Inline code is probably faster than subroutine based code. I commented out all the HPWM subroutines and substituted in place of their calls the HPWM statements themselves.

My guess is that the SRF05's are blinking faster. That is very good.

I checked the SRF05 responses. They seem to be immediately after the one millisecond trigger pulse. PULSIN should not be timing out, but that is a vulnerability worth considering.

Ken

[Kenjones1935]

I did a DEFINE PULSIN_MAX 1000 and the car is falling into my 'failed' because 'rangefront' or 'rangeright' equals zero. Interesting!! Something there is not consistent.

[Byte_Butcher]

You'll probably need a longer timeout than 1000.
That would only be 10mS that it waits.
Maybe try 10000?

Fool around with it a bit. It needs to be long enough to see the whole pulse, but short enough that it doesn't waste excessive time waiting.


steve

[Kenjones1935]

When running independently off the 7.2v voltage regulated battery the SRF05's seem more consistent with their responses than when running off the PIKkit2 USB provided 5volt supply. Interesting if true.

Thanks again, all...

Ken

[Kenjones1935]

Added complexities. Classic amateur robot stuff I would guess.

1. The sonar proximity detectors have a fairly wide field of "vision". If the car bumps against the side wall at a sharpish angle, the front detectors see the wall. The program thinks the car has come to a corner in the room and makes a maximum sharp left turn. This sets the car up for a very zigzag pattern.

I tried making a "megaphone" for the front sonar pingers out of the cardboard tube on a toilet paper roll. The sonar "detected" the tube. Hmmmm

2. When the battery begins to fade the car has a difficult time moving from a dead stop. Given a nudge, it takes off. The net behavior becomes quite different. Discombobulating to say the least.

3. The wheels and the steering servo still appear to be reacting too slowly. Exactly what is the problem is not clear.

That is the report for today...

Ken