PBP projects for R/C models

[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

[Kenjones1935]

I have forgotten most everything I ever knew about v=iR.

Is there any reason that you all can recall why I should not just put the a digital 16F887 output pin directly into one of the input lines of the SN7407N?

Ken

[Kenjones1935]

How does HPWM work when the pulses are set for 50 per second (20msec) period and the code loops more quickly than that. ie the next HPWM command happens before the last one got a chance to count out the 20 msec.

Is it obvious if I study the ASM code? I wish I could find a compact library so I could read ASM easily.

Ken

[mackrackit]

The hardware parts of the PIC run independant of the code.
That is one of the reasons we use interrupts. Gives the code a chance to see what the hardware is doing.

I do not think reading ASM will help much. The chip does not really care about the language.

[ScaleRobotics]

How does HPWM work when the pulses are set for 50 per second (20msec) period and the code loops more quickly than that. ie the next HPWM command happens before the last one got a chance to count out the 20 msec.

Is it obvious if I study the ASM code? I wish I could find a compact library so I could read ASM easily.

Ken

I don't know if I understand the question. To set HPWM at 20ms, you need to slow your pic down to 0.5 Mhz (if you are using the hardware PWM). But then you only get about 32 different settings from 1ms to 2ms. Maybe you are asking what happens to the servo when you send the 1.5ms pulses quicker than 50 hertz?

How are you doing it Ken?

[Kenjones1935]

When I toggle from radio control to PIC control I would like the car not to go through a sudden change of commands. I would like the PIC to know what the RC receiver had just told the electronic speed control and the steering servo so that at the instant of toggle it can duplicate these commands.

Hopefully a solution is while in RC mode to loop two PULSIN commands looking at the signals the radio receiver is sending to the ESP and the servo. The technical question I have is, "How do I process the input from a PULSIN to create a HPWM that is equivalent?"

The PBP textbook description is not clear to me.

Ken

[Kenjones1935]

The question I was trying to ask was this.

All my code is a continuous loop. The PIC is way fast compared to the fifty pulses per second which is the specification for the radio control car PWM.

I am doing many HPWM commands within a fiftieth of a second. What does that look like on the output pin? Actually now that i have an oscilloscope I can find out for myself.

Ken