Ubiquity magni silver robot smoother movement

General Questions
1

Hi,

I’m using magni_bringup (https://github.com/UbiquityRobotics/magni_robot/tree/noetic-devel/magni_bringup) package and core.launch to bring up the motor node.

When I control the robot by sending velocity commands (at a rate of 20Hz) from the command line, I observed that the robot is not moving continuously. It moves forward to some distance (let’s say 0.3m - 0.5m), stops suddenly and then moves forward again. Movement is intermittent

Is this the expected behavior?

All the parameters are kept as mentioned here (https://github.com/UbiquityRobotics/magni_robot/blob/noetic-devel/magni_bringup/param/base.yaml)

Then I changed the controller loop rate from 20 Hz to 40Hz, which enabled the robot to move continuously without any intermittent stop.

Had I done it in a right way? Or, is there any another way to do this?

And with the changed controller loop rate, sometimes; when the robot is about to change it course of movement (let’s say robot is moving towards a goal, now I cancel the current goal then issued a new goal), it stops suddenly and then moves which creates jerky movement.

I noticed a parameter where we can set max and min jerk limits and it was not in the base.yaml file.

Could you please suggest a recommend value for jerk limits?

Also would appreciate the recommended parameter change to make the robot move as smooth as possible.

Note : In all cases, max velocity is set to 0.3m/s

2

This robot has a ‘deadman timout’. If you do not continue to send velocity above that deadman rate then the robot stops and starts again on next command.

What you had effectively done is a ‘little bit’ dangerous as it alters our robot in ways not yet tested.
I suggest you from YOUR controller up the rate you publish to /cmd_vel and in that way you will not impact our Magni ‘dynamics’.

So what you did is likely to work but is not the best or rather supported yet solution.

1 Like
3

Shorter answer: Modify your code to send at 25hz

4

Hi Mark,

Thanks for the warning.

I have performed a quick check by reverting the controller loop rate to 20 Hz and publishing the velocity at 25Hz as mentioned below.

Terminal - 1: roslaunch magni_bringup core.launch
Terminal - 2 : rostopic pub /cmd_vel -r 25 geometry_msgs/Twist – “[0.3, 0.0, 0.0]” “[0.0, 0.0, 0.0]”

Yet, I observed the jerky movement.

5

Are you sure you’re not having a bad wifi signal? That sounds somewhat like lost packets engaging the deadman timer. Then again if the rostopic pub is running on the robot via ssh it may not matter.

It’s definitely not expected behaviour, not something I’ve ever observed.

6

Hi MoffKalast,

I’m running all these via ssh. So as you said, it shouldn’t be a problem. Anyway, I will try running it again in a isolated network.

Before we discuss further on this, I think there is another issue that needs to resolved which may be the reason for our current one.

I’m getting a constant and repeated error from the ubiquity controller, which is “GOT error from Firm 0x00”

''process[robot_state_publisher-1]: started with pid [14483]
process[diagnostics_agg-2]: started with pid [14484]
process[controller_spawner-3]: started with pid [14485]
process[motor_node-4]: started with pid [14496]
[ WARN] [1634880150.810366439]: Analyzer specification should now include the package name. You are using a deprecated API. Please switch from GenericAnalyzer to diagnostic_aggregator/GenericAnalyzer in your Analyzer specification.
[ WARN] [1634880154.126950197]: Encoder Resolution: ‘Enhanced’
[ WARN] [1634880154.127102550]: Wheel type is: ‘standard’
[ WARN] [1634880154.127189494]: Wheel direction is: ‘standard’
[ERROR] [1634880154.190801119]: GOT error from Firm 0x00
[ERROR] [1634880154.193481127]: Failed to read from I2C device /dev/i2c-1! ERROR: Remote I/O error
[ERROR] [1634880154.194045672]: Error -2 in reading MCB option switch at 8bit Addr 0x40
[ERROR] [1634880154.213670588]: GOT error from Firm 0x00
[ WARN] [1634880154.371484577]: Setting PidParam P to 5000
[ERROR] [1634880154.387805293]: GOT error from Firm 0x00
[ WARN] [1634880154.397693735]: Setting PidParam I to 7
[ WARN] [1634880154.421096838]: Setting PidParam D to -110
[ WARN] [1634880154.445669959]: Setting PidParam V to 1500
[ WARN] [1634880154.468987269]: Setting PidParam Denominator to 1000
[ WARN] [1634880154.492729989]: Setting PidParam D window to 10
[ WARN] [1634880154.516868581]: Setting PidParam max_pwm to 250
[ WARN] [1634880154.523917048]: Resetting controller due to time jump 0.000017 seconds
[ERROR] [1634880154.640217838]: GOT error from Firm 0x00
[ERROR] [1634880154.943774104]: GOT error from Firm 0x00
ERROR] [1634880155.641938942]: GOT error from Firm 0x00
[ERROR] [1634880155.691769763]: GOT error from Firm 0x00
[ERROR] [1634880156.189194578]: GOT error from Firm 0x00
[ERROR] [1634880156.588607739]: GOT error from Firm 0x00
[ERROR] [1634880157.494394091]: GOT error from Firm 0x00
[ERROR] [1634880157.836224283]: GOT error from Firm 0x00
[ERROR] [1634880158.235590951]: GOT error from Firm 0x00
"

And I didn’t see this error on the ubiquity robot that I worked with earlier. There was a board failure on that robot, hence I’m working on this robot now

Inspite of this error, robot seems operational i.e. I can navigate the robot, able to get odom data and the transforms are getting published. In short, all the basic functions are working good.

Could you please check and explain when can this error will be raised?

7

Hmm well it’s likely to be this line here, but that won’t tell us much without the error list for the firmware.

I’d suggest grabbing the latest ubiquity_motor off github and also doing a firmware upgrade to see if that helps.

8

I see something in your latest log. What version MCB board are you running?
We recently fixed a bug that had problems with rev 4.9 and earlier versions because there was no I2C option switch. This is the ‘clue’ Error -2 in reading MCB option switch at 8bit Addr 0x40

A recent fix made the code so if there was no option switch it assumed a rev 4.9 board.

See this page to identify the MCB rev if you don’t see it in big white text on left side of board.

9

Hi MoffKalast,

I tried to perform the firmware upgrade as you have suggested and Im getting the following error,

rosrun ubiquity_motor upgrade_firmware.py --device=/dev/ttyUSB1 --file v40_20201209_enc.cyacd

Welcome to the Ubiquity Robotics Firmware Updater!

Please make sure that you are not running any ROS nodes.

  • sudo systemctl stop magni-base

Note: Updating the firmware requires access to the internet.

Updating firmware now. Do not power off the robot. This is expected to take less than a minute.
(‘Encryption:’, True)
Writing row 54 for 0 process at 0.00 percent completion
Traceback (most recent call last):
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 490, in
send__encrypted_program_row(ser, flash_id, row_number, data)
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 347, in send__encrypted_program_row
p.send()
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 262, in send
raise Exception("Packet did not start with valid status, instead: " + cstr(status_code) + " – header: " + cstr(header))
Exception: Packet did not start with valid status, instead: ← [‘0x4’] – header: ← [‘0x1’, ‘0x4’, ‘0x0’, ‘0x0’]

and

rosrun ubiquity_motor upgrade_firmware.py --device=/dev/ttyUSB1

Welcome to the Ubiquity Robotics Firmware Updater!

Please make sure that you are not running any ROS nodes.

  • sudo systemctl stop magni-base

Note: Updating the firmware requires access to the internet.

Please enter your email address: k.manodhayan@mobiveil.co.in
An access token was sent to your email address
Please enter your access token: e2bcdcbe614f60a2
What version would you like (press enter for latest):

Updating firmware now. Do not power off the robot. This is expected to take less than a minute.
(‘Encryption:’, True)
Traceback (most recent call last):
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 434, in
silicon_id, silicon_rev, bootloader_version = send__enter_bootloader(ser)
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 317, in send__enter_bootloader
p.send()
File “/home/raj-mailapalli/Haystack_ws/src/ubiquity_magni_silver_driver/ubiquity_motor/scripts/upgrade_firmware.py”, line 262, in send
raise Exception("Packet did not start with valid status, instead: " + cstr(status_code) + " – header: " + cstr(header))
Exception: Packet did not start with valid status, instead: ← [‘0x4’] – header: ← [‘0x1’, ‘0x4’, ‘0x0’, ‘0x0’]

could you please check this out?

Also could you please mention the python version and version information for the python packages used in upgrade_firmware.py?

10

Hi Mark,

MCB revision of the board that I’m using is 5.3 and the response for

rostopic echo /diagnostics | grep -A 1 ‘Firmware [DV]’
key: “Firmware Version”
value: “37”

11

Hello. Ok so for sure version 37 should be upgraded.
I suggest you see or full page that goes into detail so you do everything correct for the upgrade.

12

Now getting back to the error of 0x00. This is very likely to happen when there is a large difference between the Pi host side code and the firmware. I can tell you that we fixed several issues with v37 firmware and it would be best to get at least up to v40 which I believe is the one we will give you using upgrade_firmware tool.

The version I use now all the time which is still beta but for sure has full ability is v43.
To get this one you would have to get it from our repository here:

Then get v43_20210829_beta2wd_enc.cyacd

Then on the page I just gave for upgrading look at upgrading using a file and get this file on your Pi then specify the path to the v43 file as this is the very latest of everything.

13

Hi Mark,

This is what I did after reading the page that you just shared,

  • sudo systemctl stop magni-base
  • rosrun ubiquity_motor upgrade_firmware.py --file v40_20201209_enc.cyacd (or)
    rosrun ubiquity_motor upgrade_firmware.py --file v43_20210829_beta2wd_enc.cyacd

Still I’m running into same error

Do I have to do anything else?

14

I may have lost track of this but are you using an approved shipment version OR are you trying to use the newest beta Noetic Image? You can only load firmware on pre-Noetic images as python changed RADICALLY and badly broke our firmware upgrade tool. It is a very ‘hot’ issue but is also insanely complex issue.

I am sorry when I said I am using the Noetic image. I am indeed using it BUT my firmware was up to date PRIOR to use of the Pi image for Ubuntu 20.04.

If you really want current firmware you need to burn a supported image like the 2020-11-07 image on Ubiquity Robotics Downloads and only that can load firmware as latest Ubuntu 16.04 Linux thus using Python 2.7

The next thing is you are on v37 from /diagnostics. That tells me your Pi is able to talk to the MCB and there is no pure serial issue.

Please clearify if you are trying to run the beta Noetic (Ubuntu 20.04) stuff that is for SURE ‘cutting edge, not officially supported image’ still in development

15

For the upgrade, I’m using the raspberry pi that came with the robot and the image in it has never been modified. When I checked it has ros-kinetic in it.

16

Hi Mark,

I freshly burnt a 2020-11-07 image on a sd card and tried to do the firmware upgrade and I end up with the same error.

Could please help us with the issue sooner, may be can we have the discussion over a call and get this done with?

I’m kind of stuck at this point, not able to move anything further.

17

I am seeing this late, but I am curious if you see the same jerky movement with a Logitech Joystick? Of course that only makes sense if you have a Joystick. Sometimes I get jerky motion if my WiFi is weak and I am using keyboard teleop either directly via ssh or throught a remote laptop talking to a ROS_MASTER_URI. I’d also see if things are different working over a local network or direct via the default WAP at 10.42.0.1

Finally, always always always check your battery voltage. I spent two hours yesterday fiddling with software while may batteries were only putting out 18 volts!

18

You seem to be using a USB to serial adapter so from what you typed you have a working serial dev at /dev/ttyUSB0.
One important typo is you have an = sign but there should be no = so you should have in that line --device /dev/ttyUSB0
That for sure would lead to a python error.
Not specifically said before but of course you must get any firmware file you are going to upgrade into the directory you run the tool or of course it will not find the file. When in doubt use full path from /

Lastly you have not mentioned actual running firmware rev so try this when robot is fully up and running (can be moved)

rostopic echo /diagnostics | grep -A 1  'Firmware [DV]'
19

Hi Mark,

Sorry to follow this on a delay. I was on a vacation.

Yes that true. As I mentioned earlier, I’m using NVIDIA Jetson instead of raspberry pi.

To be in the same page with you, I switched back to raspberry pi (mounted it back on the MCB) for firmware upgradation and did the steps mentioned in the post below.

Surprisingly, it doesn’t make any difference. And by looking at the error, it seems like the problem is somewhere around the parsing the firmware and converting into a UART packet.

Actual running firmware is also “37”.

20

You MUST get your firmware to v43 please or at least v40 please.

Are you saying you cannot get the upgrade_firmware.py to run? I forget where we left off
Mark