Printable View
I have built four cars.
Two 1/10 scale model level. My original and my new one. The new one is inherently much faster. They are both the same car from the same company.
Two toy level:
One 1/12 scale which is similar to Frits'.
One 1/10 scale which you saw in my video.
Maybe I should bring them all to the gym on a sunny day for a grand comparison.
Ken
What I am really trying to do is get some numbers together for things like : at half speed, must turn by XX inches or we will crash/skid. Also after watching your video again, the wall tracking appears to be a combination of 2 things. too much time between sensor readings, and too much turn (over driving)
'side note
My personal feeling is to get all the driving out of the int and in the main, but it might not matter. Just good coding. Imagine on your next project, when an int occurs, you could not tolerate a 4ms delay from what ever you were doing.
'end side note
Back on topic: so why not try increasing the sonar to every 50ms for each? This would more than double the resolution of your readings. Then we need to address more choices for how much to turn. A couple pages back you had asked if the math could be done digital. the answer is yes of course, just type more if statements. maybe instead of 2 stage steering, how bout 10% increments? fom 0-100%
something else picking at me is the timing. right now, every half sec, your int could take longer than 5ms. this is because of :2 servo updates could be 4 ms, plus at cnt=50*2 cnt2=4 so you have to ping sonar 2 also. Actually, come to think of it, sonar could last up to 30 ms!!!! so that is definantly too long for the 5 ms interupt.
sample int handler:
simular written in asm:Code:reload timer
cnt=cnt+1
cnt2=cnt2+1
flags=0
return
I would have to check your datasheet again to make sure the inc's are correct and I'm not sure about using your PBP variables like that, but I think its correct.Code:movlw _preload.lowbyte
movwf timer1L
movlw _preload.highbyte
movwf timer1H
inc _cnt
inc _cnt2
movlw 0
movwf _flags
return
I gave you the ASM equalviant so you could see what it is and if you want to use asm, you don't need to include PBP_include or whatever it is
Some time ago, I know not when, I purchased PIC MICROCONTROLLERS from MikroElektronika. Then I put it in a pile and forgot. It reappeared this morning. Looks like I have much of the ASM info I have been seeking.
My old HPWM system uses a TRIGGER: subroutine for SONAR triggers. The leds on the SONARs blink many times per second. They are too fast to count accurately. Each SONAR blinks at least 55 times in ten seconds. My non-mathematical guess is fast's enough if the steering servo and the wheel motor are reacting 'instantly'. Which they are not.
I think I have learned that there is no advantage keeping the PWM signal down to 50hz. All that is necessary is to calibrate the pulse widths as they appear in HPWM 2, xx, 50.
A number of your suggestions push me to work quantitatively. I have been 'eying' my distances - measuring with outstretched hand tip of thumb to tip of little finger = about ten inches.
I would have a better handle on the behavior of my robocar if the SONAR measurements were in decimal inches. Right now I have a system of translating the echo pulse size to inches that I derived empirically. It would make my life easier if when I do a READ of numbers I have stored in EEPROM Data they came out as digital. How with PBP do I do that?
Thats an easy one Ken :) sinec your result is measured in 10uS steps, according to the spec for your sonar, "If the pulse is measured in uS, then divide by 148 to get inches". So all you have to do is inchesright = rangeright/148. And inchesfront = rangefront/148.
Now I am not sure you really need to convert it in your program. You could just look at the range results and use a calc so you can get a feel for it. your car won't care about the units.
EDIT: heres what keeps haunting me. lets assume most of the time the front is >33.783 inches (5ms pulse divided by 148). that means your interupt will retrigger while in the interupt. Maybe thats ok, as long as you have stack space for all the saves and returns. Also, the reason for changing the servo pulses to interupt drivin from HPWM was to be able to more properly command the servos.
I have been multiplying by .066 (in my head). Give or take a decimal point. I want to be able to READ the EEPROM and see inches. Not easy?? Is there a PBP routine that does this?
My interrupts are once every 5 millisec. I count 25 of them between each SONAR trigger. They are 125 millisec apart. The servos do work well with properly timed pulses, but they do not seem to react any quicker or with any finer precision. I have no accurate means of measuring this.
Thank you for thinking along with me. My computer experience was all digital data communication. Ultimately I retired from CISCO. I know nothing about real time control systems.
Ken
I think its this easy:Quote:
Originally Posted by Kenjones1935
To get the result from EEprom:Code:inchesfront = rangefront/148
write SomewhereInEEprom,inchesfront
inchesright = rangeright/148
write SomewhereElseInEEprom,inchesright
Code:read SomewhereInEEprom,frontanswer
read SomewhereElseInEEprom,rightanswer
Ok, first I have demonstrated my inability to do simple math somewhere in some posts about your sonar timing. But no matter. Heres whats going on right now. you trigger every other sonar 125 mS apart, so if only talking about the right sonar for now, it is triggered every 250 mS, or 4 times per sec. I think that is just too slow!!!. your steering servo can and does react fast enough, but it gets the same signal 12 times before you have a new range to adjust with. So thats 6 missed opportunities to get a better correction.Quote:
My interrupts are once every 5 millisec. I count 25 of them between each SONAR trigger. They are 125 millisec apart. The servos do work well with properly timed pulses, but they do not seem to react any quicker or with any finer precision. I have no accurate means of measuring this.
its all fun for me, I am learning PBP far faster this way so its mutually benifical for both. :) And BTW, I switched majors in collage because I didn't want to learn the communication side of electronics. Something about "transform anaylases" just scared meQuote:
Thank you for thinking along with me. My computer experience was all digital data communication. Ultimately I retired from CISCO. I know nothing about real time control systems.
Ken
I do write SONAR proximity results in EEPROM. I use the WRITE command. It comes out in HEX with reversed words. Here is an example:
Address 00 contains BC
Address 01 contains 02
This reads as BC 02 when looking at the EEPROM readout.
These are HEX and they are reversed. They represent:
$02BC = 256x2 +16x11 + 12 = 512 + 176 + 12 = 700decimal
Take 2/3 of 700 and get about 48 inches. I do that with in my head or with scratch paper.
Your system of dividing 700 by 14.8 gets 47.29 inches. My brain can figure out "two thirds of" easier.
I want addresses 00 and 01 to look like 4729, or preferably rounded down to 0047 or up to 0048. Can PBP do that?
Ken
This will write asci to your eeprom data. Your PicKit2 can be set to read data as asci with the little drop down box. By the way, I hope you are not writing to the eeprom each time a distance is measured, because you will wear your chip out pretty quick that way.Quote:
Originally Posted by Kenjones1935
Then you can view it like this:Code:distance var word
inches var byte
distance = 700
distance = distance * 10
distance = distance + 74 'add half of divisor (148) , this is not needed, but will "round up" if you want to be a little more accurate
inches = distance / 148
write 0,61 'For "=" (standard asci character set)
'the + 48 changes it from dec to asci
write 1, inches dig 2 + 48 'will be a "0" if inches = 47
write 2, inches dig 1 + 48 'will be a "4" if inches = 47
write 3, inches dig 0 + 48 'will be a "7" if inches = 47
Attachment 4971
Today I brought both of my PIC controlled cars to the old gym to see how they fared together on the same track. Here's the video. Which do you think was the winner? Remember the TOY car is red. The MODEL car is blue. The TOY cost originally cost $50. The MODEL cost $200. Both have my kit.
http://www.youtube.com/watch?v=7Bw-svW1n3Y
What do you think? Should I show it on Access Television?
Ken
They look pretty much equal to me.
What if you took some paste board and made the corners a radius?
Overall they look good!!
I have a new plan to control the much faster 1/10 scale toy car which is fast, but does not contain proportional controls. The trick is to turn the wheels only for a short period of time (150 msec at the moment) then 'kick' (supplement the springs) them back to neutral.
If the neutral is well calibrated (the 1/10 cars have a knob that centers the wheels) this method makes the car turn with little swerve. I need this while wall following. Otherwise the car crashes into the wall before the code/DPDT relay/steering wheels can react.
I'll make a video if this really works.
Ken
Great Idea Ken
Worked for me :D
Quote:
Originally Posted by mackrackit :
I just drove home trying to simulate Ken's car. Pulsed the same degrees left or right, more pulses left or right for turns but always the same, say 5 degrees off center, and after each pulse returned to center.
GEE, I thought no one was listening - LOL
My toy car has neither toe in nor caster. But it should be able to react. It does not. If you are in a helping mood here is both a (disappointing) video, and a pointer to my code.
http://www.youtube.com/watch?v=ykn8MkGDm28
http://www.employees.org/~kjones/ToyCarKickTurn3.htm
Could the PIC be resetting? Am in a looping loop? The whole thing is only 503 words compiled. My guess is that I am not seeing something that right in front of my eyes...
Ken
Wondering if the part in RED is causing the trouble? If it were eliminated and sent to
CheckIfInDanger:
after
keepreversing:
was satisfied???
Code:keepreversing:
WHILE rangefront < stopreversing
' We have not reversed far enough
HIGH stopgo 'go
LOW forrev 'back
GOSUB triggers
WEND
'------------------------------------
'done reversing. Go straight or turn left depending on right
'ping. If > outertrack then out in the middle. If < desiredtrack
'then stuck on wall.
IF rangeright > desiredtrack THEN
'steer left
LOW turnon 'steer
HIGH steerto 'left
steeringstate = 1
HIGH stopgo 'go
HIGH forrev 'forward
PAUSE 500
'hpwm 2,Forward,50 --Already going Forward
ENDIF
GOTO main
Went to bed last night puzzled.
Checked the car (untouched since disastrous demo yesterday) on the bench. Seemed to react correctly and quickly. The stimuli are my hands moving as quickly as I can make them.
Hmmmm.....
Could it be that somehow this tight loop eliminates the ability to react to the front SONAR. The video shows the car stuck against the wall in total silence with the front LED constantly on. This WHILE loop could cause that if somehow the two drive motor instructions were being short changed. Maybe I need a PAUSE in here. It would do no harm.
Code:keepreversing:
WHILE rangefront < stopreversing
' We have not reversed far enough
HIGH stopgo 'go
LOW forrev 'back
GOSUB triggers
WEND
Take a look at:
http://www.youtube.com/watch?v=_4Cm-9W2KNs
Please tell me what you think.:eek:
Ken
Ken that is just stunning!!!!!
Please share with us the change that made it happen, or was it multiple changes? Looks like now you can tweek the distances to get closer to the wall.
COOL!!!!
What did you do??
The changes were of two types.
1. Instead of "braking" by turning off the DC voltage to the wheels (thereby relying on reverse polarity created by the rolling momentum of the wheels in the DC motor) I now use the DPDT relays to reverse the polarity for a few hundred milliseconds.
2. I put some PAUSE commands in to make sure wheel and steering related commands had time to actually do what I had expected.
Thanks...
Ken
I put the car up on blocks and found that when going forward it only turned left in my patented incremental way. It also flashed the SONARs at about 1/2 the usual rate.
The Vcc wire for the right side SONAR had become disconnected.
Soooo with the front SONAR working and the right SONAR always saying zero distance to the wall, the car turns left in little bits except when it approaches a wall head on. Then it brakes and swerves left.
That's exactly what my video shows.
Given that information, what if anything should I fix?
Ken
Well now you know exactly where the problem is. Connect the side scan and start tweaking that part of the code.
The issue is controlling the steering. It is bang-bang but I can modify the length of time and the frequency of each 'bang'. The plastic wheels slide easily. This is true of turning as well as forward or reverse drive.
I hope not to introduce an adjustment POT. It appears that the plastic mechanical parts are not consistent. Kicking the steering wheels back from full reach seems not to be symmetric. Hmmmm. :(
Ken
The car turns left when the right SONAR says it is further away from the wall than "desiredtrack". The car then moves a bit more as it rotates (turning right) its distance to the wall increases as a function of its rotation.
So it decides to keep turning right. Wrong!!
I need to think more about this.
Ken
I typo'd. The car turns left when the right hand SONAR says it is too close to the wall - ie less than "desiredtrack". It then crosses the imaginary "desiredtrack" line which is parallel to the wall.
Now it starts to turn right - as it should. As the right turn aims the front of the car more at the wall, the right SONAR finds that same wall farther away. It exceeds the "desiredtrack" distance and therefore keeps turning right.
CRASH
Sounds like you need to limit your angle as you turn into the wall.Quote:
Originally Posted by Kenjones1935
When adjusting right to get to your imaginary line (closer to the wall), if front distance < 3 * side distance, then turn left (until front distance > 3 * side distance). Something like this should help keep from making too big of a right turn, but still get you closer to the wall.
Changing the 3 would change the angle you would allow.
Ken,Quote:
Originally Posted by Kenjones1935
Not been following this thread for a while, but simply based on that video my guess is that due to the wheels having limited grip it slides / wheelspins each time the controller nakes an adjustment. If you are able to change the tires for something that grips better you might find it has better control of it's destiny :)
I am pretty sure this method will lead to oscillations. In fact in the Ken's video this really happens. The car "oscillates" around its desired path.Quote:
Originally Posted by scalerobotics
With simple if-then commands this cannot be compensated. As discussed in previous post, a PID loop control can help.
Ioannis
it worked better. Now it goes pretty straight but does not turn left hard enough when confronted with a corner. Watching and listening to my video I conclude that at this speed with this little friction the PIC needs more warning (I only gave it 53 inches) to turn sharply left. I'll change that and try again tomorrow. Also this sharp left turn should not be modulated. It should be bang.
It is a bit of a drive to my deserted gym. It has no heat and no electricity. My laptop crashed a few weeks ago. So one fix on my desktop PC, one test.
A question: Do you folks recommend any editor that automates my version control? I would like to start with version 1.0 then activate an editor that automatically adds each of my code changes one batch at a time. If I had that I could recreate any past version.
Presently I am saving the versions identified by their checksum. That is clumsy.
Ken
I like the sliding robocar. If I want solid control I would go back to the 1/10 scale hobby level car. There are many available rubber compounds for the hobby car wheels. They have caster, toe-in, four wheel drive and weigh four pounds.
Sliding looks like dirt track racing. When I was a kid we had midget car racing with little four cylinder Offenhouser engines on a 1/4 mile dirt oval. I did not do it, but I sure did watch.
Ken
Versions..
Might be kind of crude, but I just copy the *.bas file and paste it into the same directory. The the copy has Copy(x) added to the file name. Then the date and time stamp can be referenced.
How do you keep track of the details of each change? Comments grow and grow and grow...
Dave,
do you keep the *.bas, *.pbp in the default directory? Does compiler have any problem with the path?
I am considering to keep my files there too.
Ioannis
Ioannis,
I let PBP and MPLAB install to their default directories, but my actual code and related project files are kept here.
C:\MAC\My Dropbox\PIC PROGS\"project name here"
Cad/CNC files and such are in a sub directory of the above.
Another benefit from having an off site backup... My CNC machine's PC is also DropBoxed so the machine always has the latest files automatically.
No problems with the path, the path name is still under the length limit this way.
OK, Thanks Dave.
Ioannis
Ladies and gentlemen - I am bamboozled. My 1/10 toy level car seems to be a bit confused also. Garbage in. Garbage out. The old give-no-quarter rule of programming. Is the issue response time? Is the issue inconsistent friction? Is the issue - no it couldn't be - my PBP code? I believe the electronics are consistent and the hookup wires are stable ( I used Silicone household sealant)
In the video I say, "As soon as it starts to turn right, it's in trouble." That now seems not to be the problem. After it successfully negotiates a corner-caused left turn and it is too close to the new wall, it turns left to get out to desiredtrack, but never straightens out.
The code is at: http://www.employees.org/~kjones/ToyCarKickTurn4.htm
http://www.youtube.com/watch?v=7n5_0PlZmzs
Any insight would be greatly appreciated.
Ken