PBP projects for R/C models

[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

[Kenjones1935]

I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

Somehow I have to speed up my processing loop.

Any suggestions?

Ken

[ardhuru]

I am thinking that I need to better understand 16F887 machine language to make real progress.

This might help:

http://www.mikroe.com/en/books/picmcubook/

Regards,

Anand

[ScaleRobotics]

I am thinking that I need to better understand 16F887 machine language to make real progress. Certainly if I were to code in Assembly I would have a better feel for which macros take more time than others. I have not paid any attention to this until now.

This morning I looked at the ASM command list. I noticed that ASM has both a CALL and a RETURN command. This makes PBP's GOSUB and RETURN inexpensive I would think. Getting rid of subroutines will not improve speed.

I also note that PBP's IF, THEN, ELSE, ENDIF do not match straight into ASM code. Maybe I should write these case specific in ASM instead of PBP.

Somehow I have to speed up my processing loop.

Any suggestions?

Ken

Hello Ken,

I don't think your gosub's, or commands are taking too long, although it is possible they are too many nested. The PIC is a very fast piece of hardware, and nothing you have should take it a second to complete. After all, at 4 mhz, it can do one million instructions per second. Your pause 200 takes the most time here (the equivalent of about 200,000 lines of assembly code). I do not think you need to write this in assembly. You just need to find a bug that seems to be monopolizing your 16f887, or minimizing your sonar pings.

Can you write some simple code to make your sonar sense at more than 1 pulse per second? That would be my first test. You could also blink an led as your code passes different spots, to see if you get caught in any loops.

I would change most of your gosubs to just include the HPWM command to make for easier reading. That would make it cleaner, and easier to spot a problem. Any chance you could post the whole code, with the variables, and the config settings?

By the way, nice job! It is really progressing nicely.

Walter

Edit:

I don't think this will help anything, but how about changing all your HPWM's to HPWM x,x,245 since that is the minimum for 4 mhz? Maybe it is just defaulting to that anyway, but it is outside the range given in the manual.

[Byte_Butcher]

Somehow I have to speed up my processing loop.

Any suggestions?

What oscillator speed are you running?
8MHz on internal osc?

I believe the 16F887 will run up to 20MHz with external crystal.
That would speed things up a bunch.


steve

[ScaleRobotics]

Another thing you could do, is ICD compile it in micro code studio (for something like a PIC16f876a) and run it to see where it is getting stuck. Of course, you would need a serial port, and a PIC16f876a laying around to test it that way.

It would show you step by step, or animated, something like this:


Walter

[Kenjones1935]

You all suspected my usage of PULSIN.

You were correct.

To determine whether to take control itself or let the radio receiver do its thing, my PIC must read the PWM code from the radio receiver channel 3. That PWM comes in only fifty times per second.

I was asking PULSIN to measure that pulse without setting an interrupt for when it sees a rising edge. What are the chances of my PULSIN moment (plus delay waiting according to pulsin_max) seeing something happening only 50 times per second. Answer, not good.

What are the chances of my PIC seeing that pulse when the radio transmitter is not powered? None whatsoever!

So: When testing my car up on blocks in my "lab" and not remembering to turn on my radio transmitter the poor thing spends 99% its time waiting for a pulse that never arrives.

Yep. Turn on the transmitter (even with channel 3 in the autonomous control position) and my SRF05 blinkers flash like crazy. They are being continuously triggered.

I still have a problem with response time, but it is not because the PIC is lacking sensor information.

Ken