For a science project, I need to build a small “electric vehicle” that must travel (in a straight line) to a given point (1 cm increments) anywhere between between 9 and 12 meters as fast as possible. After it starts its run, for the first 8.5 meters, the time will be measured. After that, the vehicle can move slowly and stop at the target point.
Basically, my plan is to use an optical rotary encoder that would send pulses to the Arduino. The Arduino, with the pulses, would calculate speed and distance. Based on these factors, the Arduino would send commands to the ESC that would control the brushless motor. For setting the distance that the vehicle will travel, will use buttons and an LCD of some sort.
What I don’t know is whether or not it is feasible on the Arduino end. When the car is moving at 25MPH will the Arduino be fast enough to count every pulse from the encoder? If this is too much for one Arduino, I could easily use another to read button inputs and control an LCD and the ESC.
For the encoder, I plan to use a 200 PPR one with a +/- 2.5 inch wheel attached to it. With this configuration, 1 pulse will almost be 1mm. In terms of accuracy, I am hoping to get better than 2cm away from the target point.
Does anybody have a clue if it is feasible for the Arduino to count/store/process this many pulses at such a high frequency? Any help would be greatly appreciated!
if you want a better way, add a second encoder with 1 count / revolutions.
if 8.0000 increments per revolution... you count 7,560 at speed, but then correct to 8,000 when the second channel indicated a zero point, then you can correct for any missed pulses.
at higher speeds, you might be able to just use the zero point and then at lower speeds strart reading the high count encoder.
more about the project.
are you scored on speed to 8.5 meters?
are you scored on how close to the target you can be ?
I can see that a 2.5 dia wheel will have a circumference of 200 mm, so a 200 count encoder would allow you to move to a point with a 2mm certainty.
if you are only requied to be within the 1cm, then change your encoder to a 50 and you would be well within 1 cm.
another suggestion is that 2.5 in dia does not equate to exactly 200 mm, and the tires are not exactly 200mm in circumference, and the road may have gravel so physical slippage could mean uncertainty. do to incremental errors in tire size or road conditions. at 25 mph, does the tire expand to a larger diameter ?
i can see you race at highest speed, 1 count per revolution
decelerate , keep looking at the 1 count, start reading the 200 count and once they have returned exactly 200 for say, 5 revolutions, then at that speed the higher resolution becomes usable. at half of that speed, they should be reliable.
Thank you dav-in-nj for the 2 encoder idea! I will probably end up using 2 arduinos. For the first 8.5 meters, the arduino can completely ignore the high PPR count encoder while it measures speed and (rough) distance from the 1 PPR encoder. When the vehicle is going slow enough, the Arduino will begin to read the high PPR count encoder.
More about the project:
A large part of the score is the the time it takes to cover the first 8.5 meters.
Scoring Rules are like this:
Total Score = (RunTime * 10) + Distance (in cm) from the Target Point + any penalties. Lowest score wins.
The vehicle will be on very small scale probably a 1:10 scale rc chassis.
The encoders will have their own wheels which would be mounted on the back. This way, I will have no inaccuracies because of slippage.
In terms of a 1 PPR rotary encoder, I looked on Mouser, Digikey, and Newark but with no luck.
The few that I found were all over $300. Maybe I could mount a rare-earth magnet on a wheel and use a reed switch as the 1 PPR input but it may be too fast for the reed switch to respond.
For the Target Point, the only thing that I know about it is that it will be marked with a clear line on masking tape of some sort. I am not allowed to use anything that an IR/Ultrasonic would be able to pick up although I am allowed to align the vehicle to the track with lasers.
dave-in-nj:
slippage on accel and decel ?
effect of centrifugal force on tire diameter ?
In the way of slippage, hopefully I will build in a traction control system because slippage = inaccuracy!
TomGeorge:
Hi,
No, you do not need 2 arduinos, what you want to do is two proceedures one AFTER the other, so one controller can do the job.
Tom...
I was thinking to use to Arduinos because I thought that just 1 would become overloaded because it would:
read 2 rotary encoders
receive input from an ultrasonic range finder (so it won't hit a wall during calibration etc....)
display data on an 8x2 LCD
read inputs from 4+ buttons/switches
control the ESC with PWM
increment motor speed up and down to prevent slippage
maybe more
Do you recommend that I use just 1 because it would be to difficult to sync 2 of them?
Or, will 1 Arduino easily manage to do all of this at the same time?
