-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialization problem on real robot: wheels immediately start rotating after bringup #30
Comments
Hardware Interface log
The problem might be that the encoder values are not zero after launching the bringup package. And also the read velocity in the hardware interface is something quite high at the start:
At the start the set_velocity from the controller should be zero. But as you can see in the log at the first read cycle:
this velocity difference (set_vel = 0, measured_vel = "something high") leads to a |
Initialize values in encoder_ticks_ member array of hardware interface to zero because receiving meaningfultick values from the microcontroller might take some time. Alleviates problems in #30
I think I found the problem and work on it in the hw_init branch. After it is fixed completely I will do a PR to the main noetic-devel branch. There are/were mainly three errors causing the problem:
For the last unsolved error I think the best way to solve it, is to let the hw intf control loop wait for the encoder messages being published. Another way in solving this, could be to send the |
Sounds like you're fixing it, Franz! I'll have to check through my Teensy code when you finish, as mine is controlling the motors, too. (No Grove device.) |
To fix issues in #30 launch the encoder scrip on the microcontroller before launching the hardware interface control loop. This will make sure to send actual tick values from the encoders to the hardware interface before the control loop is running.
Initialize values in encoder_ticks_ member array of hardware interface to zero because receiving meaningfultick values from the microcontroller might take some time. Alleviates problems in #30
To fix issues in #30 launch the encoder scrip on the microcontroller before launching the hardware interface control loop. This will make sure to send actual tick values from the encoders to the hardware interface before the control loop is running.
Initialize values in encoder_ticks_ member array of hardware interface to zero because receiving meaningfultick values from the microcontroller might take some time. Alleviates problems in #30
To fix issues in #30 launch the encoder scrip on the microcontroller before launching the hardware interface control loop. This will make sure to send actual tick values from the encoders to the hardware interface before the control loop is running.
This is a bug, I encounter the same problem on my robot. I suspect missing zero initializations in the
diffbot_hw_interface.cpp
but couldn't find the exact problem so far and didn't investiage further yet. I do set the joint states and commands to zero here in the code at the beginning but it doesn't seem to help.Another source of this problem might be the motor driver code.
What I do to "solve" this, is to send an empty message on the
/diffbot/reset
topic to the encoders that might not be zero while the wheels spin. And then in my case I can stop the wheels by just blocking the wheels of the robot during this resetting, or I also make use of the motor driver reset button.Originally posted by @fjp in #24 (comment)
The text was updated successfully, but these errors were encountered: