Will not help for you old stuff...
Write a value to the EEPROM representing the version using DATA then all you have to do is read the EEPROM.
Printable View
Will not help for you old stuff...
Write a value to the EEPROM representing the version using DATA then all you have to do is read the EEPROM.
How do I get MicroCode Studio PIC BASIC PRO compiler to tell me the check sum. All I have found is to go to the PICKIT 2 Programmer and look what it calculates then go back to the compiler to put the check sum into the DATA command. Why did doing that not change the check sum? Is EEPROM not part of the calculation?
Ken
MCS is just a fancy text editor and PBP just turns the basic code into ASM so neither one will do a checksum on the hex.
DATA not changing the checksum?
Not sure about that one :(
Will look into it though.
Hey Ken, the check sum doesn't care about the eeprom data area, just program memory. So any changes to DATA will not change the checksum. Just out of curiosity, why do you need to see checksum (other than finding what version is in your chip)? Seems like this should only happen once in a while.Quote:
Originally Posted by Kenjones1935
I've got three cars: one older HPI Sprint model level, one brand new HPI Sprint model level, and one toy level. The two model levels work with PWM signals. The toy car requires DC current switching. Each has its own idiosyncrasies. My version control system sucks. My memory sucks. Checksums to differentiate just came to mind.
Ken
Unfortunately, I can relate to that.Quote:
Originally Posted by Kenjones1935
However, I did remember reading a version control system here, and I found it too! I never used it, so my version control still sucks. But you might find it a possible solution.
http://www.picbasic.co.uk/forum/showthread.php?t=2641
It still won't tell you what is in the car though :)
I wish to email my PBP code. I want the BOLD commands to remain BOLD as they do in Microcode Studio. I have a PC running XP. When I select, copy and paste the BOLDness disappears.
Any suggestions?
Ken
Use the Save As *.RTF option.
In order to get someone or something interested in helping make my robocar available to school kids I need a better quality video. I have two HPI Racing Sprint cars.
I have access to an outdoor street hockey rink. Same size and shape as ice hockey only asphalt covered for in line skates. I'm going to see if I can race my cars. Both on the track at the same time hugging the right wall going around turning left. One lap. The probability of the sonars getting their echos interchanged is remote I hope.
They can go up to thirty mph. Real speed - not scaled speed. My PIC may not be able to react fast enough. I create PWM signals using HPWM. The robocar's reactions seem slower than my fingers on the trigger of the radio transmitter. This is going to be VERY interesting. You guys got any suggestions to add to the excitement?
Ken
My first robocar includes a PICKIT 2 proto board. It has a built in potentiometer. I would like to use that pot to control my code's PWM signal from PORTC.0.
Presently I preset the constant FORWARD to a number between 115 and 123. That number is one of the arguments to my HPWM command for PORTC.0. If 123, the car goes very fast. If 115, the car creeps. I would like to make FORWARD a variable which is set within these limits on-the-fly as a result of the position of the pot.
This will force me to use ASM code which is good. This also forces me to think which can be a problem. I am not good SEARCHing this forum. Any pointers would be most welcome.
Ken
Here's my first shot. I compiled fine, but did not work at all. Assuming I got the PORTs andQuote:
Originally Posted by Kenjones1935
registers correct, am I on the correct path? I am trying to break the 256 possible values of
the Pot reading down to seven that make sense to the Electronic Speed control.
pot PORTA.0,127,Potread
if Potread < 36 then
Forward = 112
endif
if Potread => 36 and Potread < 73 then
Forward = 113
endif
if Potread => 73 and Potread < 109 then
Forward = 114
endif
if Potread =>109 and Potread < 146 then
Forward = 115
endif
if Potread => 146 and Potread < 182 then
Forward = 116
endif
if Potread => 182 and Potread < 219 then
Forward = 117
endif
if Potread => 219 then
Forward = 118
endif
write 2,word Forward
write 4,word Potread
You would be better off using ADC to read the pot and SELECT CASE for the comparisons.
Here is my latest on reading the PICKIT2 pot and selecting PWM pulse width.
The word Potread follows the pot turns perfectly from 10 00 to FF 00 in addresses 4 and 5.Quote:
Checkpot:
adcin PORTA.0, Potread
write 4, word Potread
select case Potread
case Potread < 36
Forward = 112
case Potread => 36 and Potread < 73
Forward = 113
case Potread => 73 and Potread < 109
Forward = 114
case Potread =>109 and Potread < 146
Forward = 115
case Potread => 146 and Potread < 182
Forward = 116
case Potread => 182 and Potread < 219
Forward = 117
case Potread => 219
Forward = 118
end select
write 2, word Forward
The word Forward is always 70 00 in addresses 2 and 3. SELECT CASE always chooses CASE 1
above. ie the CASE where Potread is deemed less than 36. Any ideas? I think I have problems
with using WORDs when I am only interested in BYTEs, but I am not allowed to declare a BYTE
sized VAR. I suspect my selecting "left justified" is confusing it, but I do not see in what manner.
Ideas?? Ken
Since it doesn't have to be exact, you could simplify your code.
Instead of:
something like:Code:Checkpot:
adcin PORTA.0, Potread
write 4, word Potread
select case Potread
case Potread < 36
Forward = 112
case Potread => 36 and Potread < 73
Forward = 113
case Potread => 73 and Potread < 109
Forward = 114
case Potread =>109 and Potread < 146
Forward = 115
case Potread => 146 and Potread < 182
Forward = 116
case Potread => 182 and Potread < 219
Forward = 117
case Potread => 219
Forward = 118
end select
write 2, word Forward
8 bit ADC:
10 bit ADC:Code:Checkpot:
adcin PORTA.0, Potread
Potread = Potread/37
Forward = Potread+112
Code:Checkpot:
adcin PORTA.0, Potread
Forward = Potread/147 + 112
I chose your first suggestion:
Potread = Potread/37
Forward = Potread+112
It works beautifully. :D Tomorrow I shall make a video of my car on blocks in its "going forward" state with me making it go faster and slower by twisting the pot's knob. At least I intend to do that tomorrow.
THANK YOU!!!
Sorry for the delay. I have been discouraged. The new HPI Sprint R/C car has an ESC-15 that thinks for itself. The HPI manufacturing/sales organization refuses to give me the behavioral specs. This is a STEM educational project. Not a by guess and by golly exercise in inductive reasoning.
One solution is to make an ESC on my solderless proto board. (Complete with cooling fins?)
My PIC (like the R/C receiver) makes appropriate PWM digital signals. The car wheels want appropriate PWM bi-directional current pulses. Have any of you seen a design I could copy?
Ken
My PIC already produces quality PWM signal streams. Why can't I put this signal directly to a MOSFET circuit thereby producing a current switched wheel motor driving signal. My pic could use two HPWM's for the wheels. One for forward, the other for backward. It could steer the correct MOSFET signal with a third 'direction' output. Only trouble is I do not know how to detail design what I just typed.
Ken
Usually an H bridge is used for forward and reverse. It is pretty much what you describe, only using two more fets. Microchip has an application note about one here: http://ww1.microchip.com/downloads/e...tes/00893a.pdf . It shows a nice diagram of the different states of forward and reverse on page 3.
In your post, I don't understand the " It could steer the correct MOSFET signal with a third 'direction' output." part though.... Don't you steer with a servo?
When I wrote, "It could steer the correct MOSFET signal with a third 'direction' output."
I was thinking of simplifying the speed control functionality by separating out the FORWARD and BACKWARD aspect. HPWM can easily create a PWM signal between one and two millisec. A second digital HIGH and LOW could dictate rotation direction. I've seen reference to something like this, but I did not think it through.
Ken
I think I have the ESC nailed. I have a procedure for powering up that seems to give predictable robocar behavior.
Do you all have some creative ideas for things to do with this little car. Right now it follows a wall counter clockwise looking down at a leisurely pace. High speed introduces response time problems. :o Two sonar proximity sensors can be placed looking anywhere from the car and a pot controls the top forward speed the half forward speed.
I can show you all the code if you like. It is crude, but it works.
Ken
You say looking down. Do you also have it looking for drop offs? Along that line maybe something like a seeing eye dog/bot?
There is a new car out that parallel parks itself. My car could do that if I put one sonar on the back bumper.
It could also detect motion if it were standing still. A relay race? I just thought of that. I like it....
Ken
The model level car is too expensive for middle school use. It seems to be too fast for my level of software and SF05 sonar sensing. I have found a commercially available electronic speed control that has no 'smarts', but that's $50 added cost to the package.
The 1/10 size gives me more room under the plastic car body for my solderless protokit plus an extra 4 AA battery package. This $50 toy car comes with a 7.2 volt rechargeable battery. There is still a mystery. How can the PIC detect that the RC transmitter is turned on? Presently turning on the transmitter with the trigger in a particular position stops the car in its tracks, but does not toggle to RC control.
All this sounds soo good. But.... go look at:mad:
http://www.youtube.com/watch?v=oQqVkef0DTs
It is not good. This has been frustrating. You can hear the car spin its wheels on the cement floor. I've not been able to get it to follow the wall. It turns too far when making what should be small adjustments. Could be my code. I'll share it if you want.
On the plus side this car cost $50 retail. It is light and very robust - as you can see. All my solderless kit easily fit underneath the plastic shell with holes for the sonar sensors.
As of right now It does seem that the model level car with the POT to adjust the speed is the way to go.
Ken
Hi Ken.
I would like to ask, is the steering servos linear in control or just like ON-OFF switch?
I mean can you control the amount of turn, or the angle that the car will turn? Or is it full right, full left and center?
Also I cannot see if you really have speed control over the car. It seems that it accelerates fully in every direction.
Anyway, sure it is very nervous in reactions. I will repeat my self and tell you to have a look at PID control. It is the only way to have smooth control of the speed and steering.
Ioannis
Yes, the difference between the 1/10 scale TOY cars and MODEL cars is proportional controls and $150. The original idea came from the URL below. In it is a 1/12 scale TOY car (cost about $25). He took out the radio control electronics completely.
http://letsmakerobots.com/node/696
I put my toy car up on blocks and used a large cardboard to simulate the presence of a wall on its right. I could not, even with me in control of the distance, get the car to steer straight ahead. Using my model level car it was easy. My code gives a window of 12 to 24 inches from the right hand wall for which the car should steer straight.
Ken
I think the model level car is getting close to understandable. Not so the toy. This video shows one under control, not the other.
http://www.youtube.com/watch?v=Emsf46WpctI
One more step for the model level - get it more up to speed. This needs a bigger room. I've got that, but it needs cleaning. The toy level needs my understanding of the servo that drives the steering. Presently the car does not easily go straight hugging the wall. It just goes left or right. I will clean up and post my code.
Ken
It looks like your sensors are not detecting long distance and that is why it hits the walls.
Can you make a test program and see with RS232 or LCD the distance it actually measures? And then use both sensors as it may interefere each other.
Ioannis
I took the car to an old gymnasium this morning. I had adjusted the "frontfree" distance from four feet to five feet.
That's the proximity response from the front sonars which triggers the code to turn sharply left.
I left the potentiometer at the speed that was too fast for my garage. In the gym it negotiated the corners fine, but could not hug the wall.
I may need to recalibrate the steering, but more likely I need to restructure the wall hugging code.
Here's a link to the code I am presently running. The only difference between the toy car code and the model car code is the servo and DC motor driving commands. For the model code I use the HPWM PicBasic command. For the toy level I command certain pins to be HIGH or LOW.
http://www.employees.org/~kjones/HPI2_left_SyRen02.htm
Ken
I made a video today of my model level robocar going about 1/2 speed inside an old deserted gymnasium. It largely works. I am now pretty much at the end of my road. YOUR IDEAS???
1. The kit fits underneath the body skin. It is reasonably robust.
2. The kit costs less than $80. The model car costs ~$200 assuming we do not have to purchase the HPI ESC-15 and we can swap in the SyRen ESC.
3. PICBASIC code is not too difficult for middle school students.
4. A potentiometer controls the speed. No need to go back to the USB port for that adjustment.
5. Pulse Width Modulation is necessary ( and understandable).
6. Each car needs PWM calibration of its steering.
7. The characteristics of sound (sonar) must be understood.
8. This is a good example of 'how things work' in the 21str Century
http://video.yahoo.com/watch/8324343/22230090
Ken
Do not forget the cost of PBP.
Yes, the PBP is not freeware. But from the point of view of a middle school club or group project it is a 'one of'.
I did not anticipate the complexity of upping the speed of this car and only asking it to follow the wall. This has been a good lesson for me.;)
Ken
You may want to read the back cover of your manual.Quote:
Yes, the PBP is not freeware. But from the point of view of a middle school club or group project it is a 'one of'.
Something like this came up before, no group license.
That is why I get kids started with some basic ASM and/or what they can do with the demo version.
Hmm, have a look at the videos at YouTube about line followers with and without PID control of the robot.
Behaviour of non PID is similar to your nervous car. The same robot with PID control slides smooth on the line (or in your case follow the wall in a steady distance).
Why not give it a try?
Here is the same robot with and without.
http://members.jcom.home.ne.jp/felm/ltc_p.mpg
http://members.jcom.home.ne.jp/felm/ltc_pd.mpg
Ioannis
I just read the above mentioned Software License.
I'd rather use LOGO. But that does not seem forthcoming. Hmmm...
Ken
I would contact MeLabs, maybe they will work a deal with you.
Of course you are correct. Classic robotics is error signal driven.
My problem with PID is my lack of confidence. I do not know the capabilities and limitations of PBP and the 16F887. I have not figured out how to debug the stuff in real time on the bench etc. I have been lazy regarding the 300+ page PIC Owners Manual. I never mastered MPLAB.
Can you point me to some simple PID code in a familiar language - C or C++ (complete with libraries) for example.
Ken
My wall following code is state machine code. I am going forward. The right facing sonar tells me a distance. I compare that to constants and to the previous measurement. Given where I am relative to a line parallel to the wall and whether I am getting closer to or farther from the wall, I steer right, left or straight.
Here's the code:
Given my limitations this seemed the easiest path to take.Code:keepgoingforward: '----Compare to right wall
IF oldrangeright = rangeright THEN
HPWM 1,Straight,50
ENDIF
IF rangeright > outertrack THEN
HPWM 1,HalfRight,50
ENDIF
IF rangeright < desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,Straight,50
ENDIF
IF rangeright > desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,Straight,50
ENDIF
IF rangeright > desiredtrack AND oldrangeright < rangeright THEN
HPWM 1,HalfRight,50
ENDIF
IF rangeright < desiredtrack AND oldrangeright > rangeright THEN
HPWM 1,HalfLeft,50
ENDIF
GOTO main
Ken
No need to go far away from your PBP lanquage.
Have a look at Henrik's routines here http://www.picbasic.co.uk/forum/showthread.php?p=54846
It is not easy as A-B-C but also not too hard to follow. May the difficult part would be to tune the PID parameters.
Ioannis
I sort of understand using PID to set a POT value via a DC motor. The feedback is stable and static.
My robocar needs to stay in a path while moving. The feed back - change in the echo response from the wall - is dynamic and is a function of the car's speed and direction. The PIC is plenty fast. The sonar response is not "dynamic" in this sense. My response delay problem is in the physical reality of the steering mechanism and the physics of car motion.
Another issue may be that the HPWM signal is not "really" to radio control spec. It is not a 50Hz pulse of width varying between 1msec and 2msec with 256 gradations. The frequency is more than 50 per second. The arguments I use for HPWM I arrived at empirically. I do not have an appropriate oscilloscope to accurately measure what I am producing.
I need a better understanding of what you are suggesting.
Ken
In your case the "pot" signal would be the US Sensors signal. The result of the PID controller would be the steering signal. If the whole system is tuned correclty, the steering would be much more smooth.
You do not have to mess with the speed of the car at this point. May be later if all are working as expected.
As for the HPWM, why not use the DT-INTs with a 20ms timer to have it within specs? With 4MHz clock and TMR1 you can produce an interrupt every 20ms (50Hz) and then update the value to PWM module.
Ioannis