Backward incompatibility: rework of simulation UAV spawning mechanism, Noetic update

[klaxalk]

• the spawning is now managed by a dedicated "spawner" program [link]
• the "spawner" is launched within the simulation.launch, if you don't use our simulation.launch, then run it manually (todo link to spawner launch)
• spawning is now done via a ROS service call, [new documentation page here]
• use one call for spawning multiple UAVs at once
• the parameters to the spawn command stay the same, they are now just passed via a ROS service
• adding brand new sensors and components no longer requires direct edits in the spawning script. All available parameters are defined in spawner_params.yaml in the format param_name: [default_value, help_description, [list_of_compatible_vehicles]]. The components have to be added into the .xacro model definition as before. All optional parameters are now passed to the .xacro as a pythonic dictionary optionals['param_name']
• the example sessions have been updated [link]
• pulling the simulation repository might need additional actions. The px4 repository will probably have the following uncommitted changes:

$: git status
HEAD detached at d37d20f
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)

        modified:   src/drivers/uavcan/libuavcan (untracked content)

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        cmake/configs/
        msg/tools/gencpp/
        msg/tools/genmsg/
        src/lib/DriverFramework/

no changes added to commit (use "git add" and/or "git commit -a")

the easiest solution is to delete the px4 completely and let it download again, using the following commands:

cd ~/git/simulation/.gitman/
rm -rf px4_firmware
cd ..
gitman install

[MvdB123]

Hi guys,

Michiel here. I participated in the summer school of 2019 and am trying to get the seminar task running again (very beginner with ROS, tmux, linux, but experienced with Python on Windows). I therefore first go through the https://github.com/ctu-mrs/example_ros_packages as to have a reference.

I changed the session.yml with the following line:

waitForSimulation; rosservice call /mrs_drone_spawner/spawn "1 --enable-ground-truth --enable-rangefinder --enable-mobius-camera-front --pos 10 -15 0.3 0.7"

I get the following error in the spawn window of tmux: transport error completing service call: unable to receive data from sender, check sender's logs for details. Any pointers on how to solve/get a running reference of the uav system?

Many thanks.

[klaxalk]

Hey, sorry, I forgot to update the tmux session in the examples. It should be up to date now (changes). Also, I have patched the 2019 and 2020 summer school repositories (changes, changes), with the latest updates, so they should hopefully work now as well. Let me know if you encounter more problems. Sincerely, Tomas

[MvdB123]

Thanks a lot Tomas. I got a bit further but have some other errors. Potentially unrelated to this one potentially not.

I made some changes to run from python3. (if you'd like to know; i've documented some). Things improved. But I finished with some warning messages when running the summerschool's tmux session. In the control panel the odometry posted something like: callbackGarmin(): No odom_pixhawk. ControlManager posted: not recieving Mavrosstat message. In the Automatic_start panel AutomatStart posted: missing data on topic /ready_to_takeoff.

I went to this issue and saw the comments about px4. I performed the suggested commands. Then wanted to catkin clean & catkin build the mrs_workspace. I get the following. Any suggestion on what I did wrong?

[klaxalk]

Hey, this looks like px4 is not compiling properly. Try the following:

1. do git pull in the simulation repository, this should not output any error, if it does, let me know. Alternatively, you can call gitman install --force in the simulation repository, to force update the submodules.
2. verify that the commit of simulation/ros_packages/px4_firmware by calling git log within its folder. It should outptut the following as the first line.

commit cbdd1b798bf6f7238aefb8f429bfddae32fd9576 (HEAD, tag: v1.11.2, origin/1.11.2)

3. if the compilation error persists, compile it with --verbose, it should tell us more.

[MvdB123]

pull master and checking the commit indeed solves the compilation of this package. Then some others failed. I pulled the uav_core as well. Some other compiles were now failing due to my changes. I pulled those master branches as well (mavros, mrs_rviz_plugins).

Some errors still remain for mrs_uav_odometry, mrs_uav_controllers and mrs_uav_managers. I pulled the respective master branches, but without effect. Should I checkout a specific commit instead?

[klaxalk]

Definitely don't pull the respective master branches. In some cases it is fine, but we are not on master everywhere. For example in the case of Mavros. As a normal user, use gitman to checkout a specific stable combination of commits (gitman install, it is called automatically when you do git pull). There is an option to "update" everything to the newest version (which might be actually unstable and not working) by calling gitman update, but you don't want to do that. More on that topic here: https://ctu-mrs.github.io/docs/software/gitman.html.

So to put everything into "normal state", just do git pull in the uav_core and simulation. You can enforce the checkout of the stable commits by gitman install --force if gitman objects (this can happen if you have local changes in the submodules or if your .gitman.yaml file has changed, e.g., due to gitman update).

[MvdB123]

[EDIT]: Now building the mrs_workspace using the set_mrs_workspace.sh does work when i revert my local changes. (simple change of not using if dict.has_key(key_name) but if key_name in dict. When applying my changes and doing the set_mrs_workspace.sh twice it does pass without errors. Running mtsp_state_machine/tmux/test/start.sh is back to the errors described in #32 (comment). Something doesn't work when spawning uav 2. I'll let you know if I what's going wrong.--> pos of uav2 was outside gps area, changed it to: uav2: id: 2 x: 35
I'll continue and update this comment when I progress.
Current warnings are:





Current status is now like below.

[OLD]
I tried your solution, but it kept failing. I then removed the simulation and uav_core repostirories from my git folder, cloned them, installed them and build them. Still the same errors. This morning I tried resetting fully: delete the mrs_workspace, delete the git folder, delete the repos in the workspace folder. Furthermore I deleted what-ever I could find in my home folder that was related to the uav system.

Then I tried to freshly install the uav system. But I still get these errors. Should I go for an even more rigorous clean up?

I also have a lot (231) warnings in my console output. Things like these:

[klaxalk]

Hi, so there are obviously multiple problems with your setup. You had the right idea with removing everything and installing it again, but we have to probably go even further.

1. It looks like you have a broken dependency chain in apt. This needs to be fixed before any automatic installation script can get to work. The "gazebo9 is not going to be installed" message means, you can not simulate, because the simulator is not going to be installed. The easiest solution is to remove everything which has to do with "gazebo9" and install it freshly.

sudo apt remove "gazebo9*"
sudo apt remove "libgazebo9*"
sudo apt remove "ros-melodic-gazebo*"

I also recommend calling sudo apt upgrade just to make sure everything is fine and up to date. If this fails, then fix missing packaged, etc.
Fresh installation of Gazebo is done by the install.sh script in simulation/installation.

2. When you did the fresh compilation of mrs_workspace, you got the "c++ killed signal terminated program c11plus" error. This usually means that you do not have enough RAM to compile all the stuff in parallel (vaguely speaking, you need approx. 2 GB ram for each CPU thread). Fixing this is easy, just compile with, e.g., two threads: catkin build -j2. This is usually necessary only during the first compilation where all the packages are clean. It also helps to just rerun the compilation again.

3. after you fix the installation, start with something simple, rather than the MTSP task. I recommend running the simulation/example_tmux_scripts/one_drone_gps sessions. That is the "minimal example". If the UAV takes off then the system is fine. Any more problems will be probably with the MTSP task repository.

It is often easier to just run the install.sh in the mrs_uav_system repository. The installation should stop whenever there is a problem. If it stops and says something like ... command failed with exit code ..., then copy the surrounding text and post it here. Don't try to run the simulation (it won't work with unfinished installation) and don't try to fix it manually. However, in your case, we need to do some manual fixing, e.g., due to the broken dependencies.

[lidiaxp]

I tried run the example on tmux, just_flying.sh. The UAV scenario and UAV appear but don't takeoff. The second terminal (Gazebo with command 'Gazebo' "waitForRos; roslaunch mrs_simulation simulation.launch world_name:=grass_plane gui:=true) return this error:

process[uav1/sitl_uav1-3]: started with pid [72168]
INFO  [px4] PX4 daemon already running for instance 1 (Success)
[uav1/sitl_uav1-3] process has died [pid 72168, exit code 255, cmd /home/lidiaxp/mrs_workspace/devel/lib/px4/px4 /home/lidiaxp/mrs_workspace/src/simulation/ros_packages/mrs_simulation/ROMFS/px4fmu_common -s etc/init.d-posix/rcS -i 1 -w sitl_uav1 -d __name:=sitl_uav1 __log:=/home/lidiaxp/.ros/log/9931fb48-89a2-11eb-b7d5-a7829f5bef3d/uav1-sitl_uav1-3.log].
log file: /home/lidiaxp/.ros/log/9931fb48-89a2-11eb-b7d5-a7829f5bef3d/uav1-sitl_uav1-3*.log
all processes on machine have died, roslaunch will exit
[INFO] [1616261829.566427, 6.284000]: [DroneSpawner]: Firmware for uav1 started!
[INFO] [1616261829.623215, 6.284000]: Spawn status: SpawnModel: Successfully spawned entity

And others terminal still waiting for odometry and control.

[klaxalk]

Hey, since you are running the example session (not your own script) and this issue is regarding backward incompatibility for personal custom tmux script, I suggest moving this into the discussions. But this can happen for many reasons. Is our system up-to-date and does the mrs_workspace compile fully without errors?

[lidiaxp]

Yes, I installed MRS system last week and catkin build don't returned errors. However, this error just occurs the second time that I run bash just_flying.sh. I am closing the simulation with tmux kill-server. Is there a better way to do this?

[spurnvoj]

Hi, this error tells you that the pixhawk instance is already running. So call killall px4 in terminal to kill it manually or use this key sequence https://ctu-mrs.github.io/docs/FAQ.html#how-to-stop-the-simulation for the clear shutdown of everything in the tmux session

[lidiaxp]

Thanks, it worked