Is there a way to find the robot speed usings sensors, instead of just driving your robot for a certain distance and timing it?
Sorry about the typo in the subject I typed it too fast and was eager to post it
I hope there isn’t a thread out there for this already I looked I really did
Thanks
use encoders
they are a sensor that counts wheel axle rotations
there are some tutorials on how to set up come basic code with encoders
hope everything works out!
good luck
If you don’t want to use encoders, I suppose you could use an ultrasonic. Just find a nice wall and drive away. This wouldn’t work for turning and you lose accuracy if your wall is not perpendicular to the direction of travel.
Me and BJC frequently use the counts per iteration (the first derivative of distance in a fixed time step) to calculate the speed for drivetrain efficiency and benchmarking testing.
I just setup everything in my main RepeatingTimer (in easyC), at 25ms, and sampled the encoder then reset it, and printed it to the debug terminal. On the other end, I recorded it, opened it in LibreOffice as a space-delimited file, and filtered the data to get a nice reading.
In my case, I found that I was getting ~31 counts per 25ms, with 360 count encoders on 2.75" wheels, and could then calculate the RPM at the motor and ft/sec of the whole system.
I also use this data (and a few other datapoints in the program) to tune drive controls. I can look at the ramp up/down of motor power and encoder speed, and see how I can improve response while keeping current draw down.
Use shaft encoders
I actually did this for several teams at a league play event yesterday. I used a handheld laser tachometer with reflective tape to get free speed RPMs of each side of the robots. I then plugged the numbers along with wheel diameter into a spreadsheet to give them RPM, velocity, amount of drift over 6’, PWM adjustments to compensate, etc. Some teams were very surprised that their robot speed varied as much from one side to the other.
An optical shaft encoder effectively does the same thing if used with appropriate programming. Through programming, you can count the number of pulses from the encoder and take this (with wheel diameter) over a period of time and you have velocity (distance/time). If you are just doing this for evaluative purposes you can have your terminal screen in EasyC (if thats what you are using) to return the calculated RPM and/or ft/sec for each wheel. If this is for use in an actual competition program, your robot probably has very little use for knowing what its actual ft/sec is. Most teams use the data from the encoders to correct for drift, make accurate turns, travel a certain distance, etc.
I suppose there are teams that probably use the encoders to maintain a certain robot velocity rather than set a specific power level for their motors, but I have never done that myself.
Probably not that practical, but you could just run a timer on a lap setting. Just find a long, open area to drive the bot, set up tape at increments along the hallway, drive the bot right to the end of the last piece of tape, and time each tape increment as a lap.
I would think that having at least 5-7 different spots to time would give you a good set of numbers to average out. Probably the easiest way to test it without any extra hardware/programming.
I’ve done that in FRC. The algorithm isn’t that hard, but the error handling (how do you know if you’ve lost an encoder or just not moving?) is a bit difficult. I don’t plan on doing it in VRC, though.
The advantage that provides is that, it will:
-Hold both sides to the same speed (depending on HMI and if the sticks are exactly the same), to drive straight - This is harder at max speed without logic to lower the power to the slower side, but still quite possible
-If the driver is holding a non-max speed and hits an object, the control loop will add more power until it reaches the set speed or can’t add any more power, so you can maintain velocity through obstacles.
-In autonomous, you know you’re going straight (a gyro is also useful to verify or correct for course offset, and possibly easier to implement)
On the flip side,
-If you are using it only for the purpose of driving straight, a gyro is easier to implement
-The cost-benefit analysis is not usually favorable - PID to speed requires integrating the output, making the I term the primary term, causing windup and rise time lag issues, although adding a feed-forward term helps.
-It takes a while to tune (due to the tradoff between rise time and stability)
-I would only recommend it if you know you have the programming skill to do so.