PBP projects for R/C models

[mackrackit]

Ken,

You are doing one heck of a job. Four months from your first post here, give or take a day or two, with an idea and a new language.

Now you have a working project ready for fine tuning.

Nice Job!!!

[Kenjones1935]

I took the car to R/C Excitement yesterday and gave it a try. It worked quite well. It followed the wall then negotiated the left turns to go completely around the room. It was fast. I had to run to keep up. The wall following was too zigzag. Classic case of over compensation.

Took it to R/C again today. It did not work at all well. I screwed something up!!

Question: What makes the 16F887 reset or restart. I know a power glitch will do it, but I don't see how that can be. Possibly an inductive surge from telling the motor to reverse itself without first telling it to stop. That might do it. I am changing my code so that can not happen. What else? Anything?

Another question. Have any of you seen a PBP command snippet that interprets an incoming PWM signal and puts it into a register so that I can do IF statements like, "IF signal < 110 THEN ....." There's some code in the Q&A article in this month's SERVO magazine that seems to do that, but not in PBP.

Ken

[ScaleRobotics]

Another question. Have any of you seen a PBP command snippet that interprets an incoming PWM signal and puts it into a register so that I can do IF statements like, "IF signal < 110 THEN ....." There's some code in the Q&A article in this month's SERVO magazine that seems to do that, but not in PBP.

Ken

If it is just the pulse measurement that you need, a simple:
(w = pulse width)
PULSIN PWInputPin, 1, w
will get you there. But you must call this quite regulary if you need updated values.

Edit: Below is not really a PBP command snippet, but it does what you are asking:

I know it is different hardware than you were planning. But with $2.50 you could buy a board from Radio Shack, and a $2.00 12f683, you could solder your own hardware together. The only variables you would need to pay attention to is the Main. You can read and do your math to RC1, RC2, RC3, RC4, and read only for RC5.

http://www.scalerobotics.com/PWMpassthrough.html

[Kenjones1935]

I was not thinking. I am already using PULSIN to measure the echo from the sonar pinging. My code goes round and round. All I want is the signal from channel 3 on the RC receiver that toggles from RC control to PIC control and visa versa.

ken

[Byte_Butcher]

Hey Ken,
It sounds like the car moves pretty fast!
I'm not really familiar with RC car drive mechanisms. Is the motor connected to the wheels directly, or with belts or gears.. or?
Is there a way to change the gearing to make the top speed more manageable for your purpose? Or maybe run the motor on a lower voltage to mellow it out a bit and slow things down?

As far as the PIC resetting, it would be helpful to see a schematic of your circuitry. Got voltage regulators for your PIC?

You should probably have a fairly large electrolytic capacitor (maybe a few hundred to a couple thousand uF) in parallel with one or more ceramic caps of .001 to .1 uF placed fairly close to your PIC as well as on the input side of your regulator if you've got a motor running on the same battery as your PIC.

And probably a .001uF cap across right across the motor terminals would be beneficial as well?
DC motors can generate a lot of noise and trash as well as draw large current surges that can drop the battery voltage below "acceptable" levels.

Got a schematic of your PIC and motor drive circuitry to refresh our memory?


Sound like you're making good progress!


steve

[tenaja]

Another reset culprit is stack overflow. If you have too many nested gosubs, or gosubs without returns, the PIC will reset.

[Kenjones1935]

Today I took the proto to Main Street. We have a park that is surrounded by an old (Victorian?) cast iron fence seated in a straight curb that runs next to the sidewalk. A perfect spot to test Proto's ability to follow a wall.

It did very well. In that environment I could run and keep up

So, feeling confident, I took it to a store front that had inset entrance doors. It could follow the in going wall below the plate glass then turn left when it got to the doors themselves.

WRONG! It did not turn at all. It crashed straight into the right hand glass door.

Then it stopped working correctly. It behaved very strangely. NUTS.

Seven hours later I realized the impact had moved the forward looking proximity sensor. It was now reacting to that thing-a-ma-gig to which the 'C' clip is attached for holding on the plastic car body.

I had not calibrated the numeric proximity sensor responses relative to the speed of the car. I have now more than doubled the "WATCHOUT" threshold for the front facing sensor.

Technical question. How many nested subroutines brings down the code. Any idea?

Ken