0
$\begingroup$

I have a couple of motors on my mobile base other than the drive motors, and they tend to create vibration in the robot. When these motors are turned on, the wheel's encoder ticks increase without any actual movement. This is destroying my odometry. As I need the motors to be on all the time, I need some help to figure this out.

How to avoid false encoder counts like these due to vibration?

$\endgroup$
  • $\begingroup$ what kind of encoders are you using? ... what is the code that reads the encoders? $\endgroup$ – jsotola May 31 at 12:20
  • $\begingroup$ @jsotola I'm using magnetic/hall sensor encoder $\endgroup$ – jash May 31 at 18:02
  • $\begingroup$ is it an incremental encoder with two outputs? $\endgroup$ – jsotola May 31 at 21:53
  • $\begingroup$ maybe the problem is not related to vibrations, but to a magnetic field interference $\endgroup$ – jsotola May 31 at 21:56
1
$\begingroup$

As @jsotola guessed in the comments, it is possible you have magnetic interference between your motors and hall effect encoders. This exact thing happened to me on a very compact electo-mechanical design for a robot hand seen here. If I remember correctly, we wanted to keep our magnetic encoders so we moved the motors farther away. But you might be able to switch to an optical encoder.

The other possibility is to switch to a full quadrature encoder. Most encoders already do this, but some very cheap encoders (like on the Roomba Create) are only half-quadrature. With full quadrature, you should be able to determine the direction of travel from the signals, so any vibration will only make it oscillate between 2 values, not increase indefinitely. With half-quadrature, it is only a square-wave and you have to assume a direction of travel, so noise might make the values increase as you said.

| improve this answer | |
$\endgroup$
0
$\begingroup$

The one easy solution is to put in logic in your odometry that lets it know if your robot is moving. Just have a flag that tells your odometry to stop reading encoder inputs. when you know the robot is standing still.

If this doesn't work for you then it becomes quite a hard problem to solve. You can either try and model the vibration error(that seems to be the approach in this paper), or you can try and detect false positives using an additional sensor like an IMU. This approach is often used to help detect false encoder values during conditions like wheel slip. There are a ton of papers on this approach. E.g. this one. You just have to understand and adapt it to your specific problem.

| improve this answer | |
$\endgroup$
0
$\begingroup$

If you're talking about vibration causing the effect, then the encoders are giving you readings because the system is actually moving. It shouldn't affect odometry because a vibration is a back and forth thing; it should net zero counts over time.

If it is causing you problems then it could be noise, or you're not sampling fast enough, or your arm is too rigidly constrained. Rigid systems are rigid because any effective spring constant is very high, which would cause very fast oscillations that may happen faster than you can count.

Also your encoder may be too sensitive.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.