Closed samiamlabs closed 3 years ago
If I remove the option-switch related setup, everything seems to work fine on kinetic-devel though. Is this a known issue?
--- a/src/motor_node.cc
+++ b/src/motor_node.cc
@@ -191,12 +191,12 @@ void initMcbParameters(std::unique_ptr<MotorHardware> &robot )
// Tell the MCB board what the I2C port on it is set to (mcb cannot read it's own switchs!)
// We could re-read periodically but perhaps only every 5-10 sec but should do it from main loop
- if (robot->firmware_version >= MIN_FW_OPTION_SWITCH) {
- g_firmware_params.option_switch = robot->getOptionSwitch();
- ROS_INFO("Setting firmware option register to 0x%x.", g_firmware_params.option_switch);
- robot->setOptionSwitchReg(g_firmware_params.option_switch);
- mcbStatusPeriodSec.sleep();
- }
+ // if (robot->firmware_version >= MIN_FW_OPTION_SWITCH) {
+ // g_firmware_params.option_switch = robot->getOptionSwitch();
+ // ROS_INFO("Setting firmware option register to 0x%x.", g_firmware_params.option_switch);
+ // robot->setOptionSwitchReg(g_firmware_params.option_switch);
+ // mcbStatusPeriodSec.sleep();
+ // }
Hardware Revision 5:
A new chip, U3, and some circuit changes allows host CPU to read over I2C board revision, motor power switch state and a 3-bit option jumper block.
So I guess that means that trying to read the switch on hw revision: 4.9 would not work.
It's probably a good idea to add a param that determines if reading the switch state over I2C should be attempted for those of us with first production run boards :)
By the way, I've ported the majority of this repo to ROS2 galactic using ros2_control this week for our own use. Would you be interested in helping us maintain the port? I can make a pull request if you make a galactic-devel branch for me to submit it to.
I think the best resolution for this will be to change this line
if (robot->firmware_version >= MIN_FW_OPTION_SWITCH) {
to check the controller_board_version parameter and skip the i2c read on boards older than 5.0.
Hi Rohan!
I suppose that is the most obvious solution. The 4.9 version of the hardware can't know what hardware version has, so it would require the user to manually set it as a parameter right? As long as the documentaion is clear and obvious about it, it should be ok.
I think it could be possible to make it work for 4.9 without the user manually specifying the hardware version, but up to you if you want to go that route or not :)
// Sam On Fri, Jul 23, 2021, 00:30 Rohan Agrawal @.***> wrote:
I think the best resolution for this will be to change this line
if (robot->firmware_version >= MIN_FW_OPTION_SWITCH) {
to check the controller_board_version parameter and skip the i2c read on boards older than 5.0.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/UbiquityRobotics/ubiquity_motor/issues/139#issuecomment-885277388, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLLNSDQESHSF3KFEW3KMELTZCLYZANCNFSM5AEQEMFQ .
Hi folks!
I'm trying to use the kinetic-devel branch instead of the indigo-devel that is distributed with apt for kinetic for my Magni. It works fine with indigo-devel, but when I switch to the new branch I get this error:
The wheels don't spin when I publish to /cmd_vel and
rostopic echo /motor_power_active
gives medata: False
I thought it could be something with the new
system_control
topic, but publishingmotor_control enable
andspeed_control enable
did not seem to help.I have this firmware version at the moment:
Any idéas about why this is happening? Maybe I have old hardware that is not compatible? Do I need to do something to enable the motors when using the new branch?