Using A USRF In Place Of An Encoder

So I had the bright idea at the beginning of the season to not buy any encoders. Instead, I decided to use an ultra sonic range finder. I’m currently using the one from the FIRST choice catalog, and my team is using the chassis from the KoP.

The premise of the idea is that the sensor will be placed to bisect one of the radii of the wheels. Because the wheels have spokes, the sensor will return a high voltage when a spoke comes in front of it. Each wheel has 6 spokes, so it can only accurately move 1/6 of the circumference, but the “resolution” can be increased by adding more spokes.

Any thoughts or questions on the idea? I’m thinking my team will fly with the idea instead of using any encoders for this season, just for fun.

I’m not sure that the ultrasonic sensor will be useful at the short distance you’ll be sensing the spokes at and the spokes may move too fast for the sensor to detect correctly. I like the creative idea, but an encoder would be more effective and simpler to implement.

I don’t really understand why you wouldn’t use a tried and true method like encoders

So your distance resolution is probably about 3.14 in (if you’re using 6" wheels). That will be a problem if you want to use that encoder measurement to position precisely. Big steps in sensor readings are never good and in this case, the step is about as big as you’d want your tolerance for error to be. It would be difficult to make that work.

You’ll have much bigger problems if you want to use the encoder for velocity readings. Let’s say you want to check your velocity every 50 ms (in teleopPeriodic, every time the robot gets a packet). Every tick corresponds to 3 in / 0.05 s = 60 in/s = 5 ft/s. That’s completely useless velocity resolution. You could filter it or measure it less often, but then you start to introduce lag problems.

If you can get maybe 5x the resolution you’re talking about, it gets to the point where the data might be good enough. But that sounds like a lot of work for less good results compared to putting an encoder on.

You are going to have no end of problems. Response time of the sensor, width and range of the beam, etc. Good luck.

I think it’s a cool idea. I am not going to comment on the viability, except to say that I think that you should do this in the offseason and not with ~1 week left in build season. Offseason is the time for fun and ambitious ideas like this, build season is where you get something working properly. If you have good results in the offseason then it’s something that you could use next year.

I’ve gotten the sensor to accurately count the spokes at ~0.225 speed, but that’s without touching the trigger duration time I set within the program. We have successfully autonomously and accurately driven the robot a set distance, and the speed given is also fast enough to move the robot to do things in autonomous.

As for not using encoders, we have been very tight on money this season, and we’re no where close to affording to go to championships. The remainder of our money is going to building materials and not more electrical components, sadly. Maybe next year!

Thanks for the feedback though, I do accept and appreciate the criticism over its viability, but I think it will be enough to meet the needs of my team. Hopefully next year we will be more competitive and use real encoders, but I will not be there to see it.

As a mentor, I’m proud of students like you, who give ideas a shot rather than never try. A long time ago, a couple of my students at 972 tried interfacing a mouse to the robot controller of the time. They wanted to track the bot’s movement on the field carpet; that controller couldn’t handle quadrature or higher-count encoders. No quad encoder meant the program had to make its best guess as to the direction the ‘bot was going. I had to admit I was skeptical but encouraged them anyway. They got it to work but discovered the mouse couldn’t track that fast. They learned a lot and that “crazy” ideas were worth a try, just like you did.

Hey thanks! I’m gonna have to give that concept a try as well with the new mouse we got from FIRST choice, during the post season of course.

Using an ultrasonic sensor is a pretty novel idea. However, I’ve not had good experiences with ultrasonic sensors- FRC events are so noisy, they tend to have sporadic readings because of all the background noise.

You might be able to accomplish the same thing with an infrared beam-break sensor, with a fair bit more accuracy.

If you have an ultrasonic rangefinder for autonomous, you might be better off aiming it at an opaque wall of the field, driving towards it, and using that for accurate distance measurement in auto. Then again, not sure how much noise you’ll encounter, that’s why I recommend LIDAR.

As pointed out by many, using an ultrasonic sensor for odometry will be a struggle. However, as EmileH pointed out, there are other uses for this sensor that can provide useful information. Rather than using the ultrasonic to determine how far you’ve traveled, you can use the ultrasonic to determine how much distance there is remaining between you and a solid object (which hopefully would be the object you’re trying to drive to). This may require some degree of calibration and attempts to limit the width of the detection area to get useful results, but the information will likely end up being far more useful than attempting to use this sensor to count wheel rotations.

Whether or not an object is opaque should not impact an ultrasonic rangefinder. It will impact LIDAR.