MavProxy not connecting after installing Gazebo plugin

I was following the SITL instructions on the main docs site (Setting up SITL on Linux — Dev documentation); i am on Ubuntu 20.04. I got the SITL with MavProxy working just like in the instructions; the command --console --map launching everything as the last step.

I then moved on to get it to work with Gazebo following Using Gazebo Simulator with SITL — Dev documentation, I installed Gazebo9, the dev dependencies, the khancyr gazebo plugin.

Launching Gazebo with gazebo --verbose worlds/ and then the SITL with

cd ~/ardupilot/ArduPlane
…/Tools/autotest/ -f gazebo-zephyr --console --map

I get an error

SIM_VEHICLE: “” “–map” “–console” “–out” “” “–out” “” “–master” “tcp:” “–sitl” “”
RiTW: Starting ArduPlane : /home/hermamr1/ardupilot/build/sitl/bin/arduplane -S --model gazebo-zephyr --speedup 1 --slave 0 --defaults /home/hermamr1/ardupilot/Tools/autotest/default_params/gazebo-zephyr.parm -I0
Connect tcp: source_system=255
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
[Errno 111] Connection refused sleeping
Failed to connect to tcp: : [Errno 111] Connection refused
SIM_VEHICLE: Killing tasks

It seems that MavProxy isn’t connecting with the SITL anymore? But I am not sure why that would be. And now when I try to run without Gazebo using the steps at the top of my post I get the same error; so it seems not related to Gazebo, but happened after trying to use Gazebo for the first time?

Why would I get this error, I am really new to ArduPilot and ArduPlane so maybe it’s something real obvious I am missing but stepping through everything I did I can’t figure it out.

1 Like

After some debugging, I determined the problem. The startup script /Tools/autotest/ starts mavproxy and then mavproxy will attempt to connect for a short time before failing, closing and then causing to end. The issue is if Arduplane hasn’t completely started to the point of waiting for connections then mavproxy has nothing to connect to causing the above failure and premature shutdown. In most cases I doubt this happens to most people, Arduplane starts up quick; however, I was observing that on an SSH connection with a higher latency than one sees on a local network that Arduplane does take an extra amount of time to fully start and causes failure. I sleep() in sim_vehicle before starting mavproxy solved my issue; however, that is not ideal. An issue was created, could start mavproxy before ArduPlane has started and is waiting for connection causing premature exit · Issue #19314 · ArduPilot/ardupilot · GitHub.

I am not sure it just about the time arduplane starts. I have the same issue after installing gazebo my sim_vehicle doesn’t work anymore. And this is for any kind of vehicle, with or without the --no-mavproxy flag.

The build is successfull but mavproxy won’t connect to the vehicle. Do you have any ideas ? Did you find a solution ?

@A.Larribau, which version of Gazebo are you using? The current version (Gazebo Garden) is supported with an updated plugin in the ArduPilot/ardupilot_gazebo GitHub area. The wiki docs have been updated to refer to this version (Using SITL with Gazebo — Dev documentation).

Gazebo9 is now EOL (Gazebo-classic 9 officially end-of-life - General - Gazebo Community), If you are using this version it may be time to upgrade as you will have better support using a more recent version.

1 Like

yeah this is the version I am using. So should I use the version 11 ? Do you have a more recent tutorial I can follow somewhere to make SITL work with gazebo ?

If you can, use Gazebo Garden (see link in reply above). It’s not difficult to migrate existing models to the newer version. It may be more involved if you are using ROS and the ros_control libraries.

The link to the wiki (also above) contains instructions for getting SITL and Gazebo working. There are two examples in the plugin repo - a copter and delta wing. Additional examples for rovers, legged robots, quadplanes etc. can be found in the ArduPilot/SITL_Models repo.

Okay, I switched to gazebo garden and once again it makes my not working again. It looks like it changes the ip adress of the vehicle or something because mavproxy is not able to connect. I tried with the --no-mavproxy flag and launching mavproxy with an other cmd later and it didn’t work eather. Do you have ideas on what I am doing wrong ? Or what could I do to find the problem

Can you provide some more information.

  1. System: OS and version
  2. ardupilot / SITL version: (master or something different)
  3. terminal environment: (i.e. printenv)
  4. logs from gazebo: gz sim -v4 -r iris_runway.sdf
  5. logs from
  6. logs from SITL (the additional terminal that launches)

Paste logs as text and include the command line. Most likely explanation is the plugin is not loading because of a missing environment variable, but need the logs to verify.

1 Like

Well, I ended up deleting my entire wsl, re-installing ardupilot, gazebo garden, ardupilot setup for gazebo and this time it’s working. I would just add the following line after downloading the gazebo garden “sudo strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/”. In your message you talked about quadplane and it looks interesting. Which one would you advise me to start ? Anyway thank you very much for your time !

Great! Any of the examples should be good to go - the Alti Transition could be a good start.

I am sorry one last question, what frame do you set to build the alti ? where can I find a list of all plane frames available ? Thanks again

If you click on the image of a vehicle in ArduPilot/ardupilot_gazebo it take you to the help page in the model repo ArduPilot/SITL_Models.

The definitive reference is the ArduPilot wiki (all vehicle types plus the developer guides).

you probably have SITL still running somewhere that is why it refuse connexion.
Gazebo isn’t linked to mavproxy

On the terminal where you launch sitl, if something goes wrong you should have some message stating what the issue , could you provide a screenshot ?