Yes, I’m not able to upgrade with upgrade_firmware.py
There was one assumption I was making that may be the core issue here.
The upgrade_firmware.py script must be run on python 2, we have 2.7 installed.
Verify you are not using python 3 by using ‘python --version’.
On our Nov 2020 image on the raspberry pi all would be setup for use of python 2.7
WE CANNOT AND SHOULD NOT RUN THE upgrade_firmware script using python3 versions.
I mentioned to get the firmware file from the noetic-devel branch but was not saying to run from our noetic image, doing so is never to be done. I am failrly sure you are using kinetic for all your work here.
Next just in case there is some download issue lets stick with use of the --file form of upgrade.
Use: rosrun ubiquity_motor upgrade_firmware.py --file v40_20201209_enc.cyacd
Do that from a folder where you have obtained the v40_20201209_enc.cyacd and it is located in the same folder you run the upgrade_firmware script from after verification of python version using ‘python --version’.
I am going to
Beyond that I can only ‘suspect’ that something is wrong on your MCB with the bootloader segment of the code that is in the system area of the MCB PSoc processor itself.
Such a fault is not possible to detect in the field.
I say this because I am out of ideas for not being able to run the upgrade if python is ok, serial port is the default (Or you manually specify serial port). All serial comm is 38.4kbaud 8 bit 1 stop bit sort of standard parameters AND your magni is running so clearly the actual serial is intact making it to your magni MCB from the host.
I will in the next several hours do an upgrade using a firmware file, then copy that exact file to my system and email you the very same firmware file I have just done. This would be a test for some sort of corruption in the file from the download process which is also a possibility.
We have established there is an issue with firmware upgrade. That we will deal with offline.
In your 1st post you said you went to publish cmd_vel at 40hz and running was smooth. After that I said, ok, try 25 but frankly if you CAN publish at 40hz do that. I was just wondering if you could get it ok at 25. That rate is a property of our host software and not of the MCB. Sorry if that got us off course.
Also in the 1st post you begin to talk about issues with the canceling of goals. That is far far above the motor node as well as certainly the MCB. So I know v37 is not good for several reasons but v37 cannot be changed right now so leave it. Your issues with command canceling are a higher level app issue thus belong in this thread still.
I must bring this thread to the attention of our higher level software expert(s) and they must talk to you on that point. I will continue to work with you on the firmware upgrade issue but in emails like from today.
Hi Mark,
I’m now able to perform the firmware upgrade, but it’s a very strange way.
I mounted the raspberry pi on the MCB, and connected the FTDI to UART convertor back to raspberry pi, it will be mounted as a USB device (say /dev/ttyUSB1) and then attempted the firmware upgrade with the command
rosrun ubiquity_motor upgrade_firmware.py --device /dev/ttyUSB1 --file v43_20210829_beta2wd_enc.cyacd
It was successful, but when I try from the default serial port with raspberry pi, I’m not able to perform the upgrade.
I can also perform the firmware upgrade from the nvidia by switching the ubiquity_motor repository to kinetic-devel branch
Yet, intermittent movement or jerk is still there. This behavior is not noticeable when I run in no load condition but when I try with payload of at least 13Kg or more, it would be easily observed.
I’m expecting the robot move in straight line without any stoppage in the middle when I try the below command
rostopic pub /cmd_vel -r 25 geometry_msgs/Twist – “[0.3, 0.0, 0.0]” “[0.0, 0.0, 0.0]”
Can I expect that when the robot carries a payload?
You probably need to do as follows.
-
Once you have upgraded firmware (which I think you have)
-
plug the raspberry pi in to the conventional port, put in our standard software distribution and see if it drives correctly. If it drives correctly with the raspberry pi but doesn’t drive correctly with the nVidia then almost certainly the problem is with the nVidia and / or your software setup.
-
If that’s what’s going on then we can suggest further debugging steps after that, but ultimately you need to isolate whether the issue is with
a) The USB connection (which are frequently problematic)
b) Your USB to serial connection (which are even more frequently problematic particularly if using low cost USB-serial devices - the market is awash with fake devices which often don’t work well)
c) The software distribution on your nVidia device
In order to isolate the problem we would suggest that you should try connecting to the Raspberry pi over ethernet and sending your cmd_vel commands to the RPi. USB to serial converters can create lots and lots of problems, and USB itself also creates lots of issues due to the relatively high kernel overhead to operate it.
- If it still doesn’t work after bypassing the USB then its likely to be a problem with your software stack on the nVidia - as my colleagues have already noted you are almost certainly not supplying the motorcontroller with commands at sufficiently regular intervals.
Let me know how you get on
We have been having a holiday here since Thursday. Getting back to this now.
If I put a couple of your observations together I have a theory which is there is something weak about your serial lines/driver chips between the Pi and the MCB processor. When you connect directly to the FTDI port you are in effect bypassing the 3.3 to 5V level converters. That is a good observation you have made there for use of FTDI.
I was earlier surprised that firmware upgrade did not work but basic unit ‘seemed’ operational except for the odd behavior your see in being jumpy. This means serial must be working to some extent but appears to be marginal in the signal itself so every once in a while a packet gets corrupted.
The ROS topic publication to /cmd_vel is a good test and yes it is supposed to also be smooth in that mode even with a load although depending on the PID loop settings may experience some uneven acceleration as it is starting.
My next test would be keep the use of the FTDI port from /dev/ttyUSB1 and we will tell the code to use THAT port by edit as root of /opt/ros/kinetic/share/magni_bringup/param/base.yaml
In that file change in 2nd line: serial_port: “/dev/ttyAMA0” to be serial_port: "/dev/ttyUSB1"
A change to this file is overwritten if you do an ‘apt upgrade’ or of course if you use a different image.
See if this helps. If so then the issue is garbling of characters due to some degraded drivers for the 3.3V to 5V serial level converters which are little chips of U1 and/or U2 center of MCB 3cm down from top.
A second thing that may be involved is the PID parameters you had shown in base.yaml in 1st post.
This is what you copied (which matches some setting we used a year ago):
ubiquity_motor:
controller_loop_rate: 20
pid_proportional: 5000
pid_integral: 7
pid_derivative: -110
pid_denominator: 1000
pid_moving_buffer_size: 70
pid_velocity: 15000
In order to simplify these parameters we sometimes revert them like this (as a test):
pid_proportional: 5000
pid_integral: 0
pid_derivative: 0
pid_denominator: 1000
pid_velocity: 0
This operates the control loop in the simplest of ways and since you are only running 0.3 mps and light loading of 15 kilogram this set of parameters may be used with fair performance. As a minimum we now tend to set pid_integral to 3 and set pid_velocity to 0 these days. What you show has led to some cases of not very smooth control.
Hi Mark,
Changing the values of pid as below does makes an impact, is it completely safe to use this values?
pid_integral: 0
pid_derivative: 0
It is in fact ‘safer’ but less responsive I think is the best way to say it.
For a great many people having only a ‘P’ term is ok. Where it leads to issues is going up ramps and also you may see some behavior where if you start the robot from 0 velocity with just P term then you may see the robot increase speed then slow down then speed back up again (oscillation).
So decide for yourself if it is ‘acceptable’ the I and D terms are for tuning performance but they bring in other behaviors.
So basically it is ‘safe’ as you word it for sure but may not yield ideal performance is the only issue.
I do suggest you have pid_velocity set to 0, that is a ‘Ubiquity Robotics’ custom term best left to 0 unless you really are going for maximum response. So I suggest to MOST customers set pid_velocity to 0, rarely do you need that term .
Hi Mark,
Thanks, that’s a great news. I think we can safely close this discussion as we are now able to move the robot without any intermittent jerks. Adding a velocity smoother between move base and motor node really makes the robot move much smoother.
Again, thanks for the great help.