Can we attach the encoders to a rover wheel and still get an accurate measurement? Or will we have to add slippage to our code to make up for any sliding that may occur?
I think a lot of teams are planning on doing some sort of idle wheel in the middle of their bot for an encoder of some sort, thereâs a lot of questions in the Q&A about it and all of them have said this is legal.
Another thought about encoders that I know my team plans on using is using them in sync with an accelerometer and making traction control
The only ting weâre using encoders for is detecting slipping wheels. The actual navigation is being handled by a combination of vision processing(for obstacle avoidance) and inertial nav(for absolute position)
Plain and simple, if you put an encoder an a drive wheel and it slips, the encoder reading will be inaccurate. Itâs next to impossible to just throw code at it to deal with slippage.
If youâre dead set on using encoders to measure robot velocity and distances and etc, then itâs best to put the encoder on a nondrive wheel that will be pulled along with the bot. If the bot rolls, the wheel rolls, the encoder gets an accurate count.
If the bot doesnât roll, the wheel doesnât roll, the encoder still gets an accurate count. This means it doesnât matter if the drive wheels are slipping.
In direct answer, yes, if the wheels slip then the encoder will be wrong. An encoder measures a number of revolutions, and has no way of âknowingâ how much traction a wheel has. For traction control, you could look at either an idle wheel, current sensors on the motors, or an accelerometer. Encoders are a good choice to see what the wheels are doing in terms of speed - it will allow comparison to another sensor - and the comparison could provide the slip/no slip info you want.
In this case, would it be legal to use two omniwheels? Would this be considered using items other than the rover wheels for traction, even if they are designed not to mechanically affect the slippage or traction of the robot?
Check the Q&A for this, there is a large amount of posts on that, but in general they say it is ok but provide more specifics than just that
Thank you for all of your input and suggestions. I will approach our legal dept. tommorow to see exactly what wheela we can use but will probably end up listening to mechanical. Thanks!
We had the same idea. Using an undriven wheel with an encoder would provide a measurement to where your robot is moving, but I donât believe you would be able to translate that into a form of traction control without more data.
The only ting weâre using encoders for is detecting slipping wheels. The actual navigation is being handled by a combination of vision processing(for obstacle avoidance) and inertial nav(for absolute position)
Could you elaborate on what you mean by internal nav?
I believe it means the robot is recording its positional coordinates internally, and these coordinates correspond to a certain point on the field.
Nathan used the word âinertialâ, not âinternalâ. Inertial navigation uses accelerometers and yaw rate sensors to figure out where the robot is based on where it was when it was reset/calibrated and what accelerations it has been subject to.
In 2004 we built an omni-wheeled robot and included a pair of small, plastic, rover omni-wheels to measure x and y chassis movement on the field. The results were mixed. In the end, we decided that those plastic wheels were, sometimes, slipping on the carpet. This year weâre going to include one rover wheel. But, right now the plan is to use a wheel material with some grip.
yeah, my team was thinking about that, this would allow you to have a comparison between what your robot is doing and what it thinks its doing, allowing you to work this into an automatic acceleration code. because of how tricky the acceleration is going to be, this would help out loads. 