My original project was a hobby RC car
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
Two steps forward, one back.
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
Have the hobby car doing wall-racers
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
PULSIN sets the register to zero!
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----------
Is there a robotics good forum?
Maybe a PICBASIC robotics forum would know what is wrong with my PULSIN. They are always dealing with sensors.
Suggestions?
Ken
Could it be as simple as the choice of input pin??
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
I think I've got it. By George I've got it.
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:
Quote:
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
My idea may have a basic flaw....
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
Running straight poling continuously
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
Up on blocks it does the correct stuff
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
Solved at least one problem
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
It ran around the walls at the RC Hobby shop
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
Of course you are correct
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
Next step is the SN7407 MOS driver
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
Serious technical question
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