Disabling the Motor but not the ROS nodes for the wheel encoders for wheel odometry

Is there a way to electrically disable the two hub motors only while keeping the wheel odometry encoders up and running with everything else powered ON and running? By everything else, I mean the Raspberry Pi is up and running and all the ROS nodes on it are running. We want to freely push the robot around and not have it’s wheels/hub motors locked-up, as they are now when the robot is powered ON. We want to push the robot around freely and get the wheel encoder odometry from the ‘/odom’ ROS topic info into a ROS bagfile while everything is up and running.

Right now we can drive the robot with a Logitech joystick or the keyboard when the robot is powered-up, but we can’t push it around freely since the hub motors/wheels are locked-up.

Of course we can push the robot around freely if the robot is powered OFF, but we won’t be able to get the wheel odometry encoder info ffrom the ‘odom’ ROS topic into a ROS bagfile.

You can do what you are asking by releasing the red switch which turns of motor power but encoders still run. Verify this as follows:

In a window to the robot use: rosrun tf tf_echo odom base_link
Then release red button so motor power is off.
Now move robot and the translation and rotations will change based on how much you pushed the robot.

I do not know what you want to do AFTER that point is one issue. After you turn power back on we do some initialization internally in encoder counts in the robot firmware itself.

But to just do as you requested try what I have said above.

We already tried this before I contacted you and it definitely did not work then. Not sure why the hub motors/wheels remain damped (ie, offer resistance to movement) even when the red switch (power supply to motor control board and motors) is in the OFF position?

Yes, wheel encoders do put out data as verified by running the command:
rosrun tf tf_echo odom base_link when the red switch is in the OFF position, but the magni’s hub motor wheels offer resistance to movement (damped) even when red switch is in the OFF position. This does NOT help us.

So there are three states of resistance in the hub wheel motors we’ve observed:

  1. When everything is turned OFF, there is no resistance offered by the hub motors/wheels whatsoever and they free-wheel just fine.

  2. When the Raspberry Pi is powered up (black switch is in the ON position), but motor control power is powered OFF (red switch is in the OFF position), the hub wheel motors are damped and offer a lot of resistance to movement. Magni is not able to be easily pushed around.

  3. When everything is powered up, ie the Raspberry Pi is powered up (black switch in ON position) and the motor controller board is powered powered up (red switch in ON position), then Magni’s hub motors/wheels are essentially locked-up and cannot be moved at all by pushing it. Although it can be driven with the joystick and keyboard just fine as one would expect.

We did some poking around and found a block of code that seems to control the power and speed logic to the motors. The code is in this file in the source code for ROS motor controller node here:
https://github.com/UbiquityRobotics/ubiquity_motor/blob/kinetic-devel/src/motor_node.cc (specifically line 269):

The boolean estop_mode_power_off mode is enabled when power is turned OFF, but it writes a zero speed value of ‘(0.0, 0.0)’. I’m wondering if that’s the reason why the wheels offer significant resistance but are not locked-up? (resistance state 2. in my description above).

What’s the consequence of commenting-out that logic and re-building the motor_node.cc ROS node? Will hub motors/wheels free-wheel and offer no resistance if no speed value of ‘(0.0, 0.0)’ is being written to them? Thanks in advance.

Hey Ravi,

I just tried to push the robot with the Raspberry Pi powered off, and the motor power turned off, there is still resistance from the motors. I don’t think the host side code comes into this at all.

I believe that you are seeing the passive braking action of the motor, I believe it would require a firmware change to put the motors in a fully coasting mode (all FETs off). @mjstn2011 can provide more insight.


Hey Rohan,

We are definitely seeing three distinct modes of resistance on our Magni as I described in my previous post. One of my team members tried these modes besides myself and they had the same observations. Regardless, will wait on Mark’s leads on this.

The key word in your request is ‘freely’. When we are in ESTOP mode we let the motors break themselves with their back EMF.

What you are asking is for the wheels to be totally free and spin easily.

There is a possible ‘feature’ here that you are requesting but it is not implemented like that now. You see some people WANT there to be some resistance to minimize rolling.

So there is no one size fits all and what you are asking is for a new mode. I will look into it.


Great, thanks Mark. In the meantime let me know if its safe to comment-out line 269 in motor_node.cc and rebuild to test? Thx

The motor_node.cc file works in conjunction with assumptions about what the firmware is doing. The purpose of those lines is to prevent the MCB firmware from seeing velocity and thus adjusting position. The PID loop is not a velocity based loop. The ESTOP logic is spread around so I’ll say that if you remove the sending of velocity 0 from motor_node.cc there is a chance you open a small hole in certain conditions where when you turn back on the ESTOP switch it gets non zero velocity commands while re-initializing the PID loop. So the issue is that if non-zero velocity is comming in you may see a jump in the robot right after estop is enabled rather than a smooth ramp back up to speed.

We would not approve a pull request with such a change but if you want to mess with that and are not sending non-zero velocities when you re-enable the ESTOP it is ok to disable that part of sending 0 velocity while estop is active.

Because you are not showing me the lines I looked at code just pushed yesterday so line number references are a bit troublesome unless I know you are extremely current with the code as of today for example.

Lines 268-271 from motor_node.cc as of now (10:33am PDT, 12 June, 2020) cut-pasted below:

    // Update motor controller speeds.
    if (robot->getEstopState()) {
        robot->writeSpeedsInRadians(0.0, 0.0);    // We send zero velocity when estop is active
        estopReleaseDelay = estopReleaseDeadtime;


Ok, that lines up with what I suspected.

What I would suggest is put your robot on blocks with this code taken out of commision. Then run and verify it seems ok. I suggest part of your test is use a joystick or something and put joystick to max forward. OR continuously command forward with twist or other. Then turn off Estop so motor power is off. Continue to hold down and issue fast move commands. Then release Estop and see if it is ‘violent’ as ESTOP is released.

See this page for some ESTOP normal tests: (section 1.3) https://learn.ubiquityrobotics.com/verification

We do hear you and recognize your request as a valid feature request. We have to fit it into our workload which at this time is extremely high. To suspect a mode that does everything you request may break other things and so will require a lot of regression tests and so on as well as investigation into side effects that may impact product safety. It is a heavy robot so we have to be careful.

It is a useful mode and thank you for your inputs.
Thank You,