PBP projects for R/C models

[ScaleRobotics]

Hey Ken,

Don't know if you saw it, but some progress was made on the 12F683. It is decoding 5 channels, and encoding 4 channels. You could modify the servo output as you like in the main section, using PBP. The DT interrupts are done in assembly. (No pauses) All you would need is a $2.00 12f683, a capacitor, 3 diodes, and a breadboard.

http://www.picbasic.co.uk/forum/showthread.php?t=12657

[Kenjones1935]

The wall racer code contains subroutines that do all the bang/bang controls by switching DC current through relay DPDT switches

The 16F887 has CCP1 and CCP2 each of which can be controlled by the HPWM Pic Basic Command. I could replace the six subroutines above with six that use HPWM. They would use these two outputs with three pulse widths each.

If I were to add a parameter to each GOSUB command thereby giving more nuance to the pulse width I could command in between wheel speed and steering angle.

Sounds like a piece of cake. What do you think?

Ken

[ScaleRobotics]

The 16F887 has CCP1 and CCP2 each of which can be controlled by the HPWM Pic Basic Command. I could replace the six subroutines above with six that use HPWM. They would use these two outputs with three pulse widths each.

Hey Ken, I don't think I understand where you are heading. If you are talking about generating pulses for the servo's using HPWM, the low side for HPWM is 1.2 khz. Too fast for servos.

[rmteo]

Using a single CCPx module in Compare mode, trigger special event (CCP2M<3:0> = 1011), you can do 8 servo outputs within a 20mS frame (50Hz) and 1uS resolution with a 4MHz clock.

[Kenjones1935]

My original project uses a hobby level RC car. It has an electronic speed control which directs the DC power into the wheels. This ESC expects a pulse width modulated signal from the RC receiver. Last month I wrote very simple code using HPWM commands running in my 16F887 that made the wheels go forward, backward, stop and controlled the steering . With a little playing I got various speeds and less than full stop steering.

I jumped over to the wall-racer to get a feel for coding in BASIC on my PICkit 2. I stopped because the power requirements of the relay driven DPDT current switches exceed the capabilities of the microprocessor. I ordered some SN7407's. They never arrived. (I am in the process of complaining to EBAY.)

The only reason I need the DPDT switching for the hobby level car is to toggle from RC control to autonomous control. I have decided to start off by making wall-racer run on the hobby level car. Once that is going, I will implement the switch over.

Ken

[Kenjones1935]

My long awaited SN7407N's arrived today by priority USPS First Class mail.

I thought the package was empty. I could not feel the DIPS.

They are D package. I did not know this size dip existed. I can barely see the individual pins. They do not fit into any of my .100" grid prototype boards.

I think I need to specify J or N. Is there a difference from the prototyping point of view?

Ken

[rmteo]

This will tell you SN7407

[Byte_Butcher]

Yep, the "D" package is SOIC (Small Outline Package)

You would want the "N" package for DIP. According to the TI data sheet, the "J" package is obsolete.

Don't feel bad, You ain't the first one to order parts in the "wrong" package.
I've got a few 16F727's sitting here that I meant to order in a nice compact 44-tqfp package and instead I ended up with these HUGE 40 pin DIP's. Cripes, they're bigger than the whole circuit board they're supposed to go on!



steve

[Kenjones1935]

The hobby car using HPWM seems to behave correctly.

I need to calibrate the wheel torques associated with the various PWM pulse sizes. The steering servo seems slow. I know it can work well because it did so with the radio receiver in charge.

My proto is too fragile to run the car on the floor. I have it up on a stand making the wheels free. It runs on its own 7.2V battery unattached to the USB port. I can make it think there are walls near by using an oak cutting board to fool the proximity detectors.

Once this thing makes sense I will post a video.

Ken

[Kenjones1935]

Suddenly and without warning my PICkit2 programmer is not doing its job. See this picture. Any ideas? I can get rid of the Code Protect by erasing. Then it comes back. The memory error just starts happening...



NUTS! Or am I repeating myself.

Ken

[mackrackit]

Maybe it got turned on here?

[Kenjones1935]

Ladies and Gentlemen:

My project and I have a problem. PULSIN is putting zero into its target register even though my PICkit 2 LOGIC TOOL sees a reasonable pulse. See picture, below.

It is happening on the inputs from both SRF05 proximity detectors. My code, below, looks for zero and blinks some LED's if it sees a zero. They blink on the very first proximity tests.

Any suggestions? Is my code incorrect? Are there vulnerabilities or idiosyncrasies of which I should be aware?

symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

puls:
GOSUB blinkloop0
DEFINE PULSIN_MAX 65535
pulsout trigright,2 ' produce 20uS trigger pulse (must be minimum of 10uS)
pulsin echoright,1,rangeright ' measures the range in 10uS steps

pulsf:

pulsout trigfront,2 ' produce 20uS trigger pulse (must be minimum of 10uS)
pulsin echofront,1,rangefront ' measures the range in 10uS steps
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
return

[mackrackit]

What I see of your code and your description I will guess the code never loops back for a second check.

[Kenjones1935]

That was just a segment of the whole wall racer code.

Here is a short piece written to test the hypothesis that the registers never get set. The blinkloop subroutines are simple blink ten times loops. And, yes, the blinker blink to their little hearts delight.

[QUOTE:]
symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

rangeright var word
rangefront var word
CNT VAR BYTE

main:
GOSUB blinkloop01
DEFINE PULSIN_MAX 65535
pulsout trigright,2
pulsin echoright,1,rangeright

pulsout trigfront,2
pulsin echofront,1,rangefront
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
goto main: [QUOTE:]

[Kenjones1935]

I wrote a snippet of code that:

1. set the 'range' registers, rangeright and rangefront, each to 1
2. gosub blinkloop01 if the 'range' registers are both 1
3. do the pulsout, pulsin exercise
4. gosub blinkloop45 and blinkloop67 if the range registers are 0

I ran the code. The LED's told me that pulsin is loading the range registers with 0. Why??

---------start code-----------
symbol trigright = PORTB.0 ' Define output pin for Trigger pulse
symbol trigfront = PORTB.1 ' Define output pin for Trigger pulse

symbol echoright = PORTB.2 ' Define input pin for Echo pulse
symbol echofront = PORTB.3 ' Define input pin for Echo pulse

rangeright var word
rangefront var word
rangeright = 1
rangefront = 1

if rangeright = 1 and rangefront = 1 then
gosub blinkloop01
endif

main:

DEFINE PULSIN_MAX 65535
pulsout trigright,2
pulsin echoright,1,rangeright

pulsout trigfront,2
pulsin echofront,1,rangefront
pause 10 ' recharge period after ranging completes

'*****test for zeros******
IF rangeright = 0 then
gosub blinkloop45
endif
if rangefront = 0 then
gosub blinkloop67
endif
goto main:

------------end code----------

[Kenjones1935]

Maybe a PICBASIC robotics forum would know what is wrong with my PULSIN. They are always dealing with sensors.

Suggestions?

Ken

[Kenjones1935]

Channel 2 is PULSOUT.
Channel 3 is the corresponding PULSIN.

PULSOUT is waaayyy to long. It is supposed to be 20 microseconds since I am using the 4meg oscillator and my command is

PULSOUT trigfront 2

PULSOUT is about 14 millisec according to the LOGIC TOOL. See picture. Oops. The forum won't honor my request to upload the picture. You'll have to take my word for it.

Any ideas?

[Kenjones1935]

I chose, by flipping a coin, to have my PULSIN inputs on pins PORTB.2 and PORTB.3.

Is it possible that these pins can not accept pulses for width measurement? I read a two year old posting that seemed to say by changing his PULSIN pins from PORTA to PORTC everything suddenly worked. He was having the same problem as I. The pulse is on the pin, but the PIC does not act upon it.

KEn

[Archangel]

Hi Ken, Are you still using 16F887. If so PortB is lousy with analog functions, just waiting to be disabled.

[Kenjones1935]

Joe,

Are you saying that all I need to do to use PORTB is figure out how to appropriately configure it?

If so, please give me a hint? I am soooo close.

Ken

[Archangel]

Joe,

Are you saying that all I need to do to use PORTB is figure out how to appropriately configure it?

If so, please give me a hint? I am soooo close.

Ken

Ken,
I am not an expert on pulseout or pulsein, and I have not read the manual lately, but I believe they are digital commands, which by default should require you to disable the analog functions on the pin you are using.
On this chip you have,
ADCON0
ADCON1
ANSEL
ANSELH
CMCON0
CCP1CON
CCP2CON
CM1CON0
CM2CON0
CM2CON1 and a couple more which all have effect on the I/O. Get into the data sheet and read about them, they are all listed in the index of the data sheet, and see how to set them up. Remember if a bit is SET it is a 1 if cleared it is a 0.
When you come out of the data sheet you will be a much more "Savy" programmer.

[Kenjones1935]

My problem was that the length of the PULSOUT pulse was way toooo long. This was true even if I did a PULSOUT trigfront, 1.

So I changed it to:

HIGH trigfront
PAUSE 1
LOW trigfront.

It seems to respond correctly on its blocks with me moving a oak cutting board in front and on the right side to simulate inside a room with no furniture.

The battery needs charging and I need to neaten up the bundle of wires. I feel a video might not be long in coming.

Thanks, gang. Whomever you are.

Ken

[Kenjones1935]

I've got the car driving around using HPWM to control the electronic speed control and the steering servo. This is a high quality hobby level car. It seems to not react quickly enough to the PIC commands. It was designed to have a person at the radio transmitter controlling with finger and wrist movements while watching how the car performs. This is a beautiful mechanism when human judgment is included.

A toy level car runs the wheels with direct current. The steering is a bang bang servo with a mechanical mechanism forcing it straight. Fritzl used a toy level car in his wall racer. http://letsmakerobots.com/node/696

I have added 'kickers' to the steering commands. Realizing that steering straight is the servo's action when given no current, I figured that transitioning from hard left or hard right to straight might be faster if the go straight HPWM command were preceded by a momentary hard shot to the opposite extreme. My first experiment did little to improve response.

Of course it might be that my car needs a grease job.

Hmmm....

Ken

[mackrackit]

COOL!!! It works!!!
Videos???

Of course it might be that my car needs a grease job.

Or may the code is rusty?

Are you using interrupts or just running straight?
The PIC should be able to react faster than humans.

[Kenjones1935]

It is not that he PIC is slow, I think it is that the steering mechanism is too complex. It is a close match for what is in a real automobile. I need to get the car to go slower if it is going to drive along a wall no more than 15 inches away.

My code also needs some serious tweeking.

Ken

[Kenjones1935]

When up on blocks and I am fooling the sonar with my hands. (Remember it is supposed to hug the walls and thereby go around a room counter clockwise looking down.)

It:
1. goes straight when my hand is about 10 inches away on the car's right side and nothing is in front.
2. turns right when my hand is more than 10 inches away on the right
3. turns left when my hand is 15 to 20 inches away up front
4. goes backward when my hand is much closer up front. Once it has retreated 15 to 20 inches it turns left and tries again.

When on the floor the car is too fast for the PIC driven steering mechanism. It bumps into things, retreats, turns, and comes flying forward. It is too fast for me.

It is behaving similarly to those floor vacuuming robots only way too fast. I have the electronic speed control at its slowest PWM settings.

Needless to say, manipulating a video camera while waving my hand at this machine ain't easy.

Ken

[malc-c]

Ken,

Either the car needs to travel slower, or you need to increase the range / sensitivity of the sensors, or possibly use different servos which can react quicker (digital ?)

[Kenjones1935]

Took the car to the local radio control hobby shop. They played with the steering mechanism and told me that it was "all bound up". The ball joints had ceased within their plastic housing. (I got the car as a freebe.) The solution was new tie rods. (Fashioned out of two bits of plastic, tiny metal ball joints and #4-40 screws with their heads cut off. It took the guy behind the counter no more than five minutes.)

Now the thing steers like mad. Gotta calm it down a bit.

Ken

[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

[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