Problem with taking off UAVs of specific ids and (un)pauzing gazebo

[bconvens]

Hi,
I have been using the mrs system before and I have my own code compatible with yours. It has been working great up to now.
I did not touch it for some months, and recently I did a fresh install of the mrs_uav_system (commit of 11 Jan 2023).
For some reason I can't figure out, some of my drones do not start spinning their props and do not takeoff anymore.

The problem seems to be robustly reproducible if you do the following:
Adapt the three_drones_gps test by deleting the on_project_start secton and changing pre_window section in the session.yml from:
on_project_start: nums=$(shuf -i 1-30 -n 30 | tr '\n' " "); echo "UAV_NUMBERS=($nums)" > /tmp/random_uav_numbers pre_window: source /tmp/random_uav_numbers; export UAV_NAME="uav${UAV_NUMBERS[1]}"; export RUN_TYPE=simulation; export UAV_TYPE=t650; export WORLD_NAME=simulation; export SENSORS="garmin_down"
to
pre_window: UAV_NUMBERS=(1 2 3); export UAV_NAME="uav${UAV_NUMBERS[0]}"; export RUN_TYPE=simulation; export UAV_TYPE=t650; export WORLD_NAME=simulation; export SENSORS="garmin_down". I omitted the randomization of the uav ids as to make sure I always simulate with the same uav ids.
I observed some very strange, but reproducible pattern when I play with the UAV_NUMBERS and the UAV_TYPE:

• UAV_NUMBERS=(30 5 16); works* for both f450 and t650
• UAV_NUMBERS=(30 3 16); works* for t650, but uav3 does not work for f450
• UAV_NUMBERS=(1 2 3); works* only for uav3 of t650 and for no f450 uavs

• with works, I mean the props spin and the uavs take off.

Was this built like that on purpose? If so, why? What's the cause, as before your system allowed to run any uav id and any uav type combination?

Thanks!

[spurnvoj]

Hi, we have updated the system to a new Pixhawk firmware and mavros. Both uav_core and simulation repositories have been updated. Notes for the update:

• If you already have the MRS system installed, probably the best way how to update is to remove uav_core and simulation and clone them again. You will also need to remove all folders sitl_uav$ in ~/.ros folder.
• New version of mavlink and mavros: Call installation script in uav_core.
• Jinja2 tool is now used instead of xacro templated description of the robot models.

The behavior that you are describing is, in my opinion, related to old config files in ~/.ros folder. Please remove them as I suggested above.

[bconvens]

Hi, thanks for the quick reply. After doing what you suggested, my problem is indeed solved now!
For what concerns the pixhawk firmware, I updated the firmware on my pixhawks somewhere at the beginning of December 2022.
So can you confirm if the latest firmware version is the one on branch 1.11.2, commit 1ee88ac? That is the one I installed. Also, did you guys already test the new firmware in practice (just to now what to expect if you would not have done that yet)? Thanks!

[spurnvoj]

That is the old version of the firmware. The current version of the firmware is the one locked inside our simulation repo https://github.com/ctu-mrs/simulation/blob/master/.gitman.yml#L27-L29, which is now v1.13.2. We needed to update to the new version of firmware to have support for Pixhawk 6X and 6C versions, which are only available Pixhawk autopilots nowadays. We have already done some tests flights with it, and there was no issue. However, I cannot promise that everything will run as it should. We will see after some time and more testing flights.

[bconvens]

Ow, I did not know that. I thought the v1.11.2 was the latest one as that's the default branch when installed via git clone https://github.com/ctu-mrs/px4_firmware.git as described on your documentation page.
With the latest version of your code, do you think the firmware of the v1.11.2 should work or do you advice to upgrade?

Then I also noticed another issue which I think is also related to the simulation changes you have made. A few months ago I made and tested a code that attaches a suspended payload to a single UAV or a beam payload to 2 UAVs, but now this code gives issues. In short, I have xacro files for my loads (point mass with cable or beam with 2 cables) and I rely on your link_attacher_node. In between the load xacro launch and the rosservice call /link_attacher_node/attach_typed I (un)pause the physics via rosservice call gazebo/(un)pause_physics.
I noticed now that if I have 2 UAVs in the air and I attach only a load to a single UAV, the other drone emergency lands. The error in the gazebo tab can be reproduced by just pausing and unpausing gazebo for the time required to launch and call the service (e.g., 1-2s) and then one or both drones will eland. Before updating the code to the enwest version, I could pause gazebo very long without issues. However, with the new code I noticed that attaching one beam to 2 UAVs in a single command (pauze, launch, service, unpauze) still works, but not in separate commands as this takes longer between pause/unpause. Also, attaching in a single command the suspended load to a single UAV, will trigger eland for the other one. So the simulation does not handle the pause like before. Any idea how to solve this? Note: I also tried to without the pause and unpause, but then my load already drops a lot due to gravity directly after I launched it and before it gets attached at the correct place. Thanks for the help!

[spurnvoj]

I was not expecting that somebody would be cloning it separately, so I have kept the default branch the same. Thanks for pointing this out. It is changed already.

With the latest version of your code, do you think the firmware of the v1.11.2 should work or do you advice to upgrade?

Unfortunately, the old version of the simulation is not compatible with the new firmware, and the latest version of the simulation is also not compatible with the old firmware. If you need to use our system as it is and you already have something that worked, do not update to the new version and just stay on the previous one. We will create tags for the old version to let people know which versions work together.

As I mentioned in the comment above, we moved from xacro (URDF) to jinja2 (SDF) model description. There are some differences. In general, the SDF specification is more strict and requires to fill more parameters. So it is possible that your code will not work. You can try to fix this or just stay on the previous version when it worked.