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:
When everything is turned OFF, there is no resistance offered by the hub motors/wheels whatsoever and they free-wheel just fine.
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.
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.
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.
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.
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.
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;
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.
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,
mark
@mjstn2011 Just following up on this conversation, to have the wheels in “free easy to move” mode, while the Magni Board and Pi are On.
Has this feature been implemented yet? It is something that is quite a problem for our robot as well. We like to keep magni and our pi on, while we push it from one location from an another. As you can imagine this isn’t possible without killing the entire board, as there is so much resistance on the wheels.
Yeah it’s not really possible without turning on the estop, since you need to physically disconnect the power to the motors. The switch board (picture below) is luckily designed to accommodate this sort of thing though, so you could simply replace the stock jumpers that short the ESTOP and run that through a relay that can be switched by one of the Pi’s GPIO pins. Or more easily just a switch somewhere else on the robot that the person moving the robot can grab on to.
Well that’s odd, on my robot I get about the same resistance regardless if the robot is powered off or on if the ESTOP is breaking the circuit.
There is still some resistance of course, and if I push it at a reasonable pace I can see the MCB lights turn on. The motors definitely remain linked and are backfeeding the ESCs and generating power, which causes the magnetic field to fight back and brake the motor. I think you’d basically have to unplug a few of the motor phases for them to spin completely freely. I’m not sure if that would cause any problems with the MCB firmware if done while the robot is powered on.
It may be easier to just put a switch on it that has it drive forward when pressed, similar to those larger lawnmowers.
Power is cut to the system (ie. Battery disconnected)
In State 1, I can confirm you can not move the robot by hand at all, as there is full resistance to the wheels (I believe we agree on this).
In State 2, I can confirm the robot can be moved slightly, but I wouldn’t move it far as there is a fair bit of resistance.
In State 3, I can’t actually confirm this, as we no longer use this button. We’ve created a loopback wiring configuration, that always has this ON. If this could be turned off, but keep the rPi on - it may be what we’re looking for!
In State 4, With no power going to the board, I can confirm it is VERY EASY to move, however if moved fast enough (brisk walk), it will generate some power, and potentially power the board.
Ideally, I’m hopefull to make a software update to the magni motor code that would remove any robotic inputs, thus making the wheels move freely while the rPi still has power.
Hello Kris, you are correct in that we are not able to cut off the wheels and thus back-emf impact as far as resistance. What you are in fact asking for is to keep track of wheel encoder (odometry) when the wheels are on a disengaged mode of some sort. The resistance you feel is because the current generated by the wheels is fighting with the motor driver state. We have at this time no task to look into making this possible. Doing this would impact other modes of operation for safely and just general wheel odometry. This is a business decision that is likely to impact the overall state machine we manage for safety and ESTOP modes and so on and as such it is not without the potential for regressions in our ESTOP management. It is in sort not a small task and our amount of MCB left over resources for code space and variables has become very ‘tight’ over the years. We will have to evaluate this and see if we can take this on. I do realize the need here. Thanks for your continued inputs as they help us move forward to address the needs of the customers.
