|
Two steps forward....
1. I cobbled together the working parts of two DELL 8600 lap tops and created one that works!! I installed the PBP tools and have a strong new battery. I will be able to modify my code in the building - sans electricity and heat - where I test.
2. I found that putting a cardboard right up to the front SONAR makes it behave as if there is nothing within range. Sooo up real close is far away as far as it is concerned.
|
Science, Technology, Engineering - not so much math
Got a new video to show you all. The code is much the same as the last time. I included it below.
The video speaks for itself. Would this be a good context for a public school engineering project? It certainly shows the real world as I know it. The kids could see whether they can make the car go around the room staying outside traffic cones which define the inside of the course.
Code:'************************************************* *************** SYMBOL trigright = PORTB.0 ' Define output pin for Trigger pulse SYMBOL trigfront = PORTB.1 ' Define output pin for Trigger pulse SYMBOL trigleft = PORTB.3 ' Define output pin for TRigger pulse SYMBOL echoright = PORTC.6 ' Define input pin for Echo pulse SYMBOL echofront = PORTC.5 ' Define input pin for Echo pulse SYMBOL echoleft = PORTC.7 ' Define input pin for Echo pulse SYMBOL radiotransmitterON = PORTC.4 ' Define input pin for Signal 'inside radio receiver indicatin that the transmitter has 'been turn on. Used to stop the car by turning ON the xmitter. TRISC = %11110000 DATA $1C,$B5'This version's checksum goes here. ' Speed of sound echo is about 2mS per foot distance. ' define pulsin_max 2800 '28mS SF05 spec says it drops at 30mS. ' don't forget channel 3 every 20mS or 50Hz. '-------------------- frontdanger CON 180 'about 12 inches. Was 450 about 30 inches stopreversing CON 390' about 26 inches frontfree CON 1080 'about 72 inches. Was 800 about 53 inches. desiredtrack CON 540 'about 36 inches. Now only one line. 'outertrack con 450 'about 30 inches. Was 360 about 24 inches SYMBOL turnon = PORTC.3 ' the signal that if HIGH makes the car steer straight SYMBOL steerto = PORTC.2 ' the signal that if on turning is on, then decides 'the direction SYMBOL stopgo =PORTC.1 ' the signal that if HIGH makes the car go SYMBOL forrev =PORTC.0 ' the signal that if on and is not on stop makes 'the car reverse '--------------------------- rangeleft VAR WORD 'experimental timing. rangeright VAR WORD rangefront VAR WORD oldrangeright VAR WORD oldrangefront VAR WORD CNTR VAR WORD CNTR = 0 CNTL VAR WORD CNTL = 0 steeringstate VAR WORD steeringstate = 0 ' 0=straight,1=left,2=right,3=skid left,4=rightback, '-------------- 'Looks like I need to kick the steering back into straight. LOW stopgo 'stop HIGH turnon 'pause 2000 'Wait so I can put the car down and get out of the way. main: GOSUB triggers CheckIfInDanger: IF (rangefront < frontdanger) AND (steeringstate <> 3) THEN HIGH stopgo 'go LOW forrev 'back LOW turnon 'steer LOW steerto 'right steeringstate = 4 GOTO reverseoutoftrouble ' loop till this is secured ENDIF tryleftturn: IF rangefront < frontfree THEN 'something ahead - turn hard left. 'gosub leftforward IF (steeringstate <> 3) THEN HIGH stopgo 'go LOW forrev 'reverse LOW turnon 'steer HIGH steerto 'left steeringstate = 3 'skid left PAUSE 150 ENDIF HIGH steerto 'left HIGH stopgo 'go HIGH forrev 'forward GOTO main 'Loop until secured ENDIF goingforward: keepgoingforward: IF (rangeright < desiredtrack) THEN 'steer left CNTL = (CNTL+1) IF CNTL = 2 THEN LOW turnon 'steer HIGH steerto 'left steeringstate = 1 HIGH stopgo 'go HIGH forrev 'forward CNTL = 0 ENDIF PAUSE 150 ENDIF IF (rangeright > desiredtrack)THEN 'steer right CNTR = (CNTR+1) IF CNTR = 2 THEN LOW turnon 'steer LOW steerto 'right steeringstate = 2 HIGH stopgo 'go HIGH forrev 'forward CNTR = 0 ENDIF PAUSE 150 ENDIF IF steeringstate = 1 THEN 'left LOW steerto 'right PAUSE 100 ENDIF IF steeringstate = 2 THEN 'right HIGH steerto 'left PAUSE 60 ENDIF HIGH turnon steeringstate = 0 GOTO main '------------------------- reverseoutoftrouble: ' below seems reduncant except for the pause. LOW turnon 'steer LOW steerto 'right steeringstate = 4 'new steeringstate HIGH stopgo 'go LOW forrev 'back PAUSE 200 'added to do some reversing. We have a problem of bumping 'against the wall and not backing up. This pause should fix that. keepreversing: WHILE (rangefront < stopreversing) OR ((oldrangefront = rangefront) AND (oldrangeright = rangeright)) ' We have not reversed far enough HIGH stopgo 'go LOW forrev 'back PAUSE 250 'maybe this will get car to back off wall 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. This did not work. See TOY_CAR_KICK_TURN_3.wmv 'Try no IF statement. 'if rangeright > desiredtrack then 'steer left LOW turnon 'steer HIGH steerto 'left steeringstate = 1 HIGH stopgo 'go HIGH forrev 'forward PAUSE 250 'hpwm 2,Forward,50 --Already going Forward 'endif GOTO main '-------------------------- triggers: ' Check two sonars and xmitter ON signal. oldrangeright = rangeright ' produce 10uS trigger pulse (must be minimum of 10uS) LOW trigright HIGH trigright HIGH trigright HIGH trigright LOW trigright 'zero could be legal below PULSIN echoright,1,rangeright 'measures the range in 10uS steps PAUSE 10 'Wait for ringing to stop - read SF05 spec. 'pulsin echoleft,1,rangeleft 'see if this slows the triggers to one 'per second. That it did, but it crashed straight into the wall. pulsf: oldrangefront = rangefront LOW trigfront HIGH trigfront HIGH trigfront HIGH trigfront LOW trigfront PULSIN echofront,1,rangefront ' measures the range in 10uS steps PAUSE 10 radioON: ' make ON = LOW for 1/10 toy car to radiotransmitter do WHILE radiotransmitterON = 0 LOW stopgo loop HIGH stopgo 'get going again RETURN END
|
Since you will have a Laptop with you, how about getting telemetry data from your car to analyze them? Like echo, steering acceleration/braking.
Ioannis
|
The code is very simple
The code is a very simple state machine. I shall post a flow diagram if I can figure out an appropriate CAD tool.
Can (should?) middle school kids be asked to deal with the uncertainties of the real world? I think this TOY level car demonstrates that ambiguity in an appealing and dramatic fashion.
The code consists of a set of hardware related constants which need not be changed.
11 Variable definitions and the following four car behavior constants.
frontdanger - 12 inches
stopreversing - 26 inches
frontfree - 72 inches
desiredtrack - 36 inches
A routine that triggers the SONARS and puts the code in a tight loop when the radio transmitter has been turned on.
Six IF statements. These are each state machines. They evaluate the SENSOR data and tell the wheels what to do. Their labels are:
CheckIfInDanger
TryLeftTurn
TooCloseToWall
TooFarFromWall
ReverseOutOfTrouble
Keepreversing
At one level all the students need to modify are the constants. At another level they can modify these six IF statements. An advanced student could add more states.
Ken
Last edited by Kenjones1935; - 17th December 2010 at 19:08.
|
New video
It's a race. Which car wins? Depends......
|
What is the next step?
I suspect a major resistance to getting my robocar into public education is insecurity and uncertainty on the part of the teachers. We are talking about 'how things work' in 2011. My 2004 General Motors automobile contains upwards of 20 PICs. Each tire air valve has a pressure sensor and enough of a computer to maintain a presence on the car's internal wireless network. How did I discover this? I could not make sense of the little tire pressure warning messages on the dash board. A previous owner had rotated the tires. How many public school teachers could explain that in a hands-on way?
Ever tried to explain to a thirteen year old how a microwave oven works?
My robocars are very hands-on and available. All the components are visible including the hook up wire. The little cars react dramatically to programming changes. How do I communicate that to adults schooled in Education, not Engineering or Computer Science.
Ken
|
How Microwave Cooking WorksOriginally Posted by Kenjones1935
|
Re: PBP projects for R/C models
Hey Ken, I am often caught taking things too literally, so this may just be another case of that. But from the data sheet for the sensor you are using, it says:
So me taking that literally, since you have two sensors, the best you could get following the data sheet, is every 100 ms. At 20 mph, that's 30 feet per second, or about 3 feet in 100 ms. But maybe 20 mph is a bit fast anyway.The SRF05 can be triggered as fast as every 50mS, or 20 times each second. You should wait 50ms before the next trigger, even if the SRF05 detects a close object and the echo pulse is shorter. This is to ensure the ultrasonic "beep" has faded away and will not cause a false echo on the next ranging.
At that rate, you would only be able to steer the servo's every 5 servo pulses, before you got new information from the sensors. But looking on the bright side, you would have time for 500,000 instructions to chew on the data you collected.
Last edited by ScaleRobotics; - 28th February 2011 at 17:45. Reason: actually every 5 servo pulses, you would get new data from sensors
|
Darn! I can't fault your logic.
Yes, that is what my SRF05 says too. Presently my code has been pinging at about 5 times per second for each SONAR. I can up that rate.
My thoughts have been that more sophisticated math might give my car better control. I am thinking about mapping - sort of. If the car knows what it is trying to do, where it is relative to the walls and how fast it is going, it may not need so many SONAR pings. I may be just dreaming. I know nothing about classical robot positional and navigational code.
Hmmmmm.... Suggestions anyone? Has the "Robotics for Dummies" paper back been published?
Ken
Last edited by Kenjones1935; - 28th February 2011 at 18:02. Reason: missed a phrase
|
Re: PBP projects for R/C models
Maybe the folks on the MPLAB C32 Compiler forum can help: http://www.microchip.com/forums/f204.aspx
|
Hello everybody, I'm back
I got the PICket 3 to program both my 16F887 and my 32MX460. That's fine, but I am not doing well with C. I have not programmed in C since 1992. In those days I was part of a large corporation that had a support staff.
rich, you mention rd0 - rd4 on the PIC32. I was hoping to see reference of that kind of hardware detail in the PIC32C User's Manual. Nope. No mention of a MACRO either. I have to read the PIC32 Data Sheet? Oh dear....
I am inclined to return to this forum and PICBASIC PRO and 16F887. To work with higher speeds my car needs to know better where it is and what it is doing. It needs some rate of approach calculations and a bit of trigonometry. It needs to increase the number of SONAR triggers per second and their attendant drive wheel and steering adjustments.
I have not pushed the limits of the 16F887. I am not sure how to find them.
Ken
|
Re: Hello everybody, I'm back
Richard is the author of the StickOS operating system. Great to see him here! Yes, RD0 through RD4 are portD.0 through portD.4. They are mentioned in the data sheet, and also labeled (I think) on your board. What macro are you referring to?rich, you mention rd0 - rd4 on the PIC32. I was hoping to see reference of that kind of hardware detail in the PIC32C User's Manual. Nope. No mention of a MACRO either. I have to read the PIC32 Data Sheet? Oh dear....
If I remember right, you were caught with a limit of how often you could pulse your sonars. This was made worse by using two of the same type, as you had to wait for the other to be done, as they would get false readings from eachother's echo. I think there was a calculation done way back on this thread about how many feet you would travel at 20mph before you had data back. If I am correct, your limiting factor was your sensors, and not your 5 million or so instructions per second 16F887 chip.I am inclined to return to this forum and PICBASIC PRO and 16F887. To work with higher speeds my car needs to know better where it is and what it is doing. It needs some rate of approach calculations and a bit of trigonometry. It needs to increase the number of SONAR triggers per second and their attendant drive wheel and steering adjustments.
I have not pushed the limits of the 16F887. I am not sure how to find them.
I would agree, I don't think you have pushed the limits of the 16F887. I would go back to the thread about the time your sensors take, and regroup.
|
16F887 limitations...
The SONARs respond within a few milliseconds of each trigger. At 1100 feet per second the SONAR hears an echo from a wall five feet away in less than ten msec. There may be problems with the shape of the response pattern and how the ultra sound wave bounces back from a glancing blow. I have no technical means to evaluate that effect.
To figure attack angle I need to have a function that returns the angle given the ratio of the two sides of a triangle, the inverse tangent. I do not see that in PICBASIC PRO. It would be nice in degrees, -90 to 90. With this information I could more intelligently tell the car to turn hard or not-so-hard. It might minimize the weaving down the straightaway.
Calculating velocity would be nice. Without a gauge on the wheels themselves, the only means I know is to divide distance traveled by time. How to get these accurately is iffy in my head.
Gotta do some thinking and experimenting.
Ken
Members who have read this thread : 2You do not have permission to view the list of names.
Posting Permissions
Bookmarks