Printable View
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
Hey Ken,Quote:
Originally Posted by Kenjones1935
We would not know what it looks like, because we have not seen any code. We really do not know any details, HPWM settings, or oscillator settings even. But you do seem like you are getting along pretty well. This might help us answer your previous question too! I would be curious to see your oscilloscope measurements as well. The only way I know to use HPWM for the 20ms period HPWM, is to slow the oscillator down to 0.5 mhz . And the resolution kind of stinks using that method.
But I have a feeling you are using an "unkenventional" method, which is cool. Just would like to hear some details of what it is.
Thanks,
Walter
OKAY,
With the help of the new-to-me oscilloscope I saw what I had been suspecting. The PIC's HPWM signal is not structured like the RC receiver signal. This explains why the PIC has not been able to command a smooth gradation of steering servo positions or wheel driving torque.
The RC receiver produces a pulse every 20 milliseconds (50 Hz). The pulses are between 1 and 2 milliseconds long. The PIC's HPWM machine produces a pulse every 3.8 milliseconds (263 Hz). The pulses are between 1 and 2 milliseconds long.
This matches scalerobotics comment of yesterday. It also matches the PBP textbook. Now that I understand what it is saying.
What I have does give me steering and wheel drive control. It is more bang/bang than I would like. It goes FAST. Which leads me to the problem of getting the car to steer left soon enough when approaching a corner in the wall.
The RC versus PIC control toggle works. Under RC control the car reacts like the original system. RC channel 3 provides the toggle signal. The PULSIN command does a fine job differentiating short from long PWM on this incoming signal. The code then controls the AZ8222 Subminiature DIP DPDT Relay via the SN7407N DIP MOS driver. This DPDT switch selects either the PIC output or the RC receiver output to send to the electronic speed control and the steering servo.
I'll make a video when I get the kinks out. I am afraid my prototyping technique is not robust enough to withstand the bumps needed to straighten out the feed back loops.
Thanks again for your help and encouragement. :)
Ken
Here is a video of my RC car taken today at our Radio Control Hobby Shop's race track.
http://www.youtube.com/watch?v=seDKRDUdehE
Why does my code take so long to see and react to the information from the proximity sensors? :confused:There are no long PAUSE statements in my code. I am using HPWM to create the PWM control signals. Maybe I should take all the comments out of my code and post it for your consideration.
Ken
Here is my code as seen by WINDOWS notepad application. It does not make the PBP commands into capitals.
Were is the big delay?
Ken
WOW!!! That is cool!!! Very nice job so far.
After a quick look at the code I see a lot of things going on between range checks.
Just wondering what would happen it you setup a timer to trigger an interrupt routine.
The interrupt routine would be the range check. That way the range would be know almost instantly for corrections.
Or add range checking in between the IF/ENDIF statements. Places like this
Code:aftermain:
gosub skidandreverse
frontfreetostopreverse = frontfreetostopreversesetup
if rangefront < frontfree then 'turn left as there is something ahead in front
gosub SteerFullLeft
goto main
endif
IF rangeright = 0 then
endif
if rangeright > outertrack then 'turn right as we are too far away
gosub SteerHalfRight
endif
if rangeright < desiredtrack and oldrangeright < rangeright then
gosub SteerStraight
endif
if rangeright > desiredtrack and oldrangeright > rangeright then
gosub SteerStraight
endif
I thought that a PIC runs at micro second speed. I thought that a loop clean through all my code would be indistinguishable by my human eyes.
The SRF05 have little red lights that flash each time they are pulsed. While the PIC is running the little flashes come about one per second.
How can that be? What is consuming the time?
Where can I get some information about the relation between PBP commands and real 16RF887 machine language code?
Ken
I am not good at figuring execution times but there is a thread around here some place talking about it... i can not find it :(
I do see a 200 pause, add that to the IF/THENs...
On the bench just to see you could remove some of the code and see it the LEDs blink faster. A primitive way yes. All I can say at the moment.
What about PULSIN?
It has 16 bit resolution and at 4MHz, the PULSIN resolution is 10uS.
If you DON'T receive a pulse doesn't the PIC wait for 65535 x 10uS (0.655 seconds) before it "moves along" to something else?
Perhaps you need a define to determine the max PULSIN time?
IE:
PULSIN_MAX 1000 'Maximum counts allowed before pulsin times out
Just a thought.
steve
Is it possible to place the car on a stand and the camra above it. Then have an object approaching form the side and back again so we could see the reaction of your sytem.
Then I would suggest the ue of he PID routines of Henrik that are on this link to obtain smooth control: http://www.picbasic.co.uk/forum/showthread.php?t=5874
Ioannis
Inline code is probably faster than subroutine based code. I commented out all the HPWM subroutines and substituted in place of their calls the HPWM statements themselves.
My guess is that the SRF05's are blinking faster. That is very good.
I checked the SRF05 responses. They seem to be immediately after the one millisecond trigger pulse. PULSIN should not be timing out, but that is a vulnerability worth considering.
Ken
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.
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
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
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
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
This might help:Quote:
Originally Posted by Kenjones1935
http://www.mikroe.com/en/books/picmcubook/
Regards,
Anand
Hello Ken,Quote:
Originally Posted by Kenjones1935
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.
What oscillator speed are you running?Quote:
Originally Posted by Kenjones1935
8MHz on internal osc?
I believe the 16F887 will run up to 20MHz with external crystal.
That would speed things up a bunch.
steve
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:
http://www.picbasic.co.uk/forum/atta...achmentid=4092
Walter
You all suspected my usage of PULSIN.:rolleyes:
You were correct.:D
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
I don't think I have changed anything other than remove confusing comments.
Ken
Part of the reason my car keeps hitting the wall is that it is responding too slowly for the speed it is traveling.
Today I carefully calibrated my HPWM 2,xxx,50 commands.
If xxx = 110 the car does not move.
If xxx = 111 the car moves forward, but only on a non-carpeted floor.
If xxx = 112 the car moves forward forcefully but not too fast
xxx = 115 is too fast for my code.
xxx = 125 is full speed which is very fast.
Ken
Here's a video of our car running a hall in our house.
http://video.yahoo.com/watch/7164676/18657928:D
I moved the front sonic sensors closer to the front of the car and I figured out how to slow down the wheels a bit.
Next thing, I think, is to build a better looking and stronger prototype using a car with more room to attach stuff. What other kinds of sensors should I try and what other kinds of tasks will they help the PIC do?
Again, thank you for all your interest and help.
Ken
Looking good Ken!
Other sensors...
IR - Probably not do much better than the sonic, but they can be setup to "see" light and dark colors. Line follower. Maybe see the white wall...
Hall-effect - Have the car find and park or something on a metal plate, magnetic.
Solar cell or photo diode - Light seeking. You mentioned this at the beginning.
RFID - Place RFID tags along a path and have the car follow. (never done that myself)
Consider using PID control for your motors. This way your car will be less nervous in is reactions. Look for the routines by Henrik Olson at http://www.picbasic.co.uk/forum/showthread.php?t=5874
Ioannis
There is a large world wide subculture of robotics. Does it have a common higher level language? Are there some PIC's obviously better suited for certain kinds of sense and control tasks than others? Where can I read about such things? (I get SERVO magazine. I shall look more carefully for leads there. But where on the WEB?)
Ken
Maybe C is what you mean?
I think it's all in the software. Meaning the programmer.
Sure a dsPIC may do better in signal processing or faster, but requires that the programmer can code in C or assembly.
But generally speaking all micros can do more or less all sort of things.
Did you look at the link I posted? I think isthe key to your nervou problems. PID does just that.
Ioannis
This video is the same as the previous except it has an additional segment. The car goes down the hall, turns around and comes all the way back to me!!
http://video.yahoo.com/watch/7169550/18673820
Ioannis, I agree a potentiometer driven by a servo controlling direct current into the wheel motor would give the PIC smooth speed control.
For this home project with only my personal resources that is a complication I hope to avoid.
I would like some help directing me to a way to make interrupt driven PWM pulses delivered 50 times per second. My impression is with PBP GOSUB does not include arguments. This is very restricting. Am I correct?:(
Ken
I saw an article in SERVO which speaks about the VEX robotics computer package. The PIC is a 18F8520. My impression of the Microchip PICkit3 is that it is very close - it has a 18F8722 and a 18F87J11. The cost of a complete PICkit3 is only $164.00. Would using this tool make my project easier? more robust? more powerful? more flexible?
Ken
More code space is about all that you will get from those chip, might be some things that the 887 does not have but probably nothing to help you.
If you want to try one of those chips, check to see if the PicKit2 and PBP supports them, get on and put is on a solderless breadboard.
Save yourself $160.00
I may have not unerstood what exactly is your problem. Please can you repeat for me?
Ioannis
Been thinking that a good middle school STEM hook would be simple racing on an oval indoor (gymnasium basketball court) track delineated by large cardboard boxes (big enough to be detected by the SRF05 sonar proximity detectors) on the inside. I imagine a ten lap race. For six laps the kids control the cars with their radio transmitters. For four laps the cars are autonomous.
I think I can design a PBP template that would make coding the PIC reasonably simple. The template would contain the code state machine. The students' job would be to choose the steering/wheels commands associated with each state.
I have a question for you all.
If I were to add a black tape line around the track, what electronic gimmick might I put on an RC car to make it into a line follower? Is there a commercially available light source and photo cell combo similar to the pre-canned SRF05 sonar device?
Ken
The IR combo device is the least that I would be worry about.
Check the videos on YouTube and you will realize why I still insist on PID control.
Especially important on a line follower car! From the videos you will see that most ofthe cars are getting out of the path because they get very nervous. Or you have to make it really slow.
Ioannis
I too have noticed the "nervousness" of my car and other line following devices. I made a line follower out of LEGOrobotics last summer. It too was too nervous to make fast progress.
For my project to progress from its present state I need to:
1. Get my hands on an appropriate RC vehicle. The "stadium truck" style has been suggested. It has two wheel drive, excellent miniature steering and suspension, and a broad flat frame structure to which it would be easy to attach my PIC and things. Thing is they are expensive. If I get a "ready to run" it's about $200. It will have a two channel RC. I need three channels - anther $100 or so.
2. Corral the help of some friends with access to the correct facilities to help me design and build a robust kit that can be attached to most any RC 1/10 scale vehicle.
3. Prototype a "simple" state machine structure for my PBP code. Non-computer nurd middle schoolers will throw up their hands in dismay if they had to code PBP from scratch for this 'race'. I have neither the resources nor the contacts to create a LOGO or ROBOlab like language.
4. ioannis suggests potentiometer based motor control to calm down the bot's oscillations. My inclination is to try to get my HPWM signal down to the RC spec of fifty pulses per second. With my present code one gradation plus or minus on my PWM pulse width is the difference between stopped and going pretty fast. I saw this plan (below) for Interrupt driven PWM, but I have not yet studied it.
-------------here's what I found------------
Quote:
1) Decide on the resolution (the number of steps between off and 100% on. Go with 16. That's plenty.
2) Decide on a PWM frequency. Go with 30Hz. It sounds odd, but the reason becomes apparent next.
3) Set a 1:8 prescaler on an 8-bit timer.
4) Create a label "Count" and set it to the resolution (16).
5) Create a label "Demand"
6) In the interrupt service routine for the timer interrupt:
6.1) Decrement Count
6.2) When Count becomes zero, set it back to the resolution value again (16).
6.3) If Demand > Count, set the PWM output bit. Otherwise, clear it.
There you have a single PWM output. Put a value from 0 to 16 into "Demand" and the PWM output will perform accordingly. If you want two outputs, you create two Demands and perform two comparisons. (You only need one Count.)
What happens is that (assuming a 4MHz clock), this will interrupt every 256*8=2048us. Each time, the counter decrements by one. This happens 16 times meaning that each of your unique mark to space ratios is 2048us apart and that your PWM time is 2048 * 16 = 32768us, or 30.51Hz.
If your demanded PWM value is less that the PWM counter, then your PWM should be marking, otherwise, you should be spacing.
Of course 30Hz might be a bit lumpy. Swap your 4MHz crystal for a 20MHz one and suddenly you're at 150Hz. Irritatingly audiable. Your options are to reduce your resolution (half the resolution = double the frequency) or reduce your total pulse time (half the pulse time = double the frequency).
The disadvantage of reducing the resolution is obvious. The disadvantage or reducing the pulse time is that it leaves you fewer free processor cycles for your "main" program. In the example above, your interrupt is only called every 2048 cycles. Assuming it costs 200 cycles (that's generous) to process the interrupt, that leaves your main program 1948 cycles between interrupts.
You could come down to a 2:1 prescaler with a PWM resolution of 8 and a clock of 20MHz. that gives you a PWM frequency of 20/4/(2*256*8)*1000000 = 1.22kHz. BUT there are only 512 operations between interrupts then and 200(ish) of hem are taken up servicing the interrupt itself.
I just realized that the innards of an Electronic Speed Control device is a servo driven potentiometer. In the old days these were actually mechanical pots but today my guess is that they are completely electronic (however that can be)
If I am wrong on this, please set me straight. What is a modern ESC?
Ken
Here is an example of an Electronic Speed Control (for brushed motors) based on a PIC12F675 that might give you an insight. For more info, source code, hex file, etc. see here Bi-Directional Speed Controller
The ESC usually comes in two main flavors. I think the most common for the cars (might) still the DC pulsed controller (for brushed motors). You could build one of these pretty easily for your car using the hardware PWM, with much the same techniques that you have already used.
http://www.designsoft.com.au/ahome/rc/PIC-ESC/ESC.html
http://www.jimfranklin.info/microchi...ets/00847a.pdf
As far as modern, the modern ones for RC planes are 3 phase brushless ESC's. I suspect this has made its way to the RC cars as well. This is pretty complex, although it has been done by a few do it yourselfers.
http://ww1.microchip.com/downloads/e...tes/00857a.pdf
Walter
I keep saying that my RC car is meant to be a race car while being autonomous. Struggling to find its way around a room is not the demo that I want. I think an oval track in the gym bounded on the inside by many cardboard boxes at least a couple feet high. The kids with the RC transmitters must sit still in the lower seats of the roll out stands. The cars would be out of their sight when on the far side of the track.
My serious problem is that as a race car driver my 16F887 is not doing very well. It does not query the SRF05s quickly enough. The trigger pulses get to the sonars about one per second.
I am at a loss to figure what is consuming all the PIC compute time.
QUESTION? What would be the easiest, most efficient way for me to get on board with Assembly Language 16F887 coding? Machine language is not new to me. I used it professionally from 1957 till somewhere in the '80's. What is a clear and complete document on this ASM?
Ken
Have you looked here? Getting Started with MPASM/MPLINK