How to release control from gazebo-sitl

[gzhang8]

Hi,

I want to use this sitl with Dronekit to run simulations. This plugin compiles and run. Dronekit can connect to MavProxy. But the vehicle inside sitl is always fixed at the transparent sphere (target). Is there a way to disable this feature, so that I can get full control using mavlink massages?

Thank you in advance.

[gzhang8]

Even after delete

<!-- Gzsitl Target -->
    <model name="gzsitl_perm_targ_ctrl">
      <include>
        <uri>model://gzsitl_perm_targ_ctrl</uri>
      </include>
      <static>true</static>
      <pose>0 0 1.5 0 0 0</pose>
    </model>

In the .world file, it keeps hovering at 2.5 meter, but does not reponse to control signal

[rchiossi]

How are you sending the control signal and which control signal are you sending? Are you changing the flight mode?

[gzhang8]

@rchiossi Thanks for your reply. I run https://github.com/dronekit/dronekit-python/blob/master/examples/simple_goto/simple_goto.py on the same MavProxy. It is guided mode

[rchiossi]

After our drone is airborne, if there is no target in the map it will just hang in there and accept any command it receives. The only thing that the plugin does is to check if a new target was added. There is probably something else going on on that script you linked. Does it get to the point where simple_goto is called at all?

[rchiossi]

Here is what I just tested:

• Opened a clean instance of gazebo
• Added a gzsitl_quadcoper
• Opened ardupilot
• Opened mavproxy
• Waited until takeoff was done
• Send mavproxy commands via mavproxy prompt.

It worked without any issues. If you can isolate the mavproxy command that is not working in your case it will be easier to debug.

[gzhang8]

@rchiossi I test again. It works if I first issue a command to land first. But I am still wondering. Is it possible to not control the vehicle at all from this plugin, because I alway want to test my code from taking off to landing. I think this is a common use case for others as well. Thanks

[rchiossi]

Originally this project was designed as a companion to our collision avoidance library and so far it made sense to have the control tied to the quadcopter, but I agree that moving into a more generic approach, it is better to have it separated. The first alternative that comes to my mind is to move the control logic to gzsitl_perm_target_ctrl and leave gzsitl_quadcopter just waiting for commands. This way, if you don't add a target to your world, the quadcopter would respond to any mavlink command sent to it. It may be a bit tricky to keep a single mainloop for both, but should be doable. @mbelluzzo any thoughts on this?

[gzhang8]

@rchiossi Yes, using a target to enable control logic is a good idea. And it is very natural. Removing Gzsitl Target is the first thing out of my mind when I want it to release control.

[mbelluzzo]

"I want to use this sitl with Dronekit to run simulations."

I think that the correct approach would be to use the gazebo support from the autopilot itself for this. Nowadays both PX4 and Ardupilot support sitl with gazebo integration. You can check this for reference.

As @rchiossi said, this plugin was originally written when this support didn't exist. So we wrote to run our coav simulations. The plugin had two purposes: make the bridge between gazebo and autopilot-sitl and setup a mission to the target and start it. It doesn't keeps controlling the drone, but it does this initial setup that we need for test automation.

IMO, if we were to remove this part the plugin, the plugin itself becomes obsolete due to gazebo support on the autopilots that we have now. So the feature that keeps this plugin relevant is actually this mission setup (the plugin name wont make sense anymore, I agree. But that is life).

So think that there is more chance that we end-up moving this plugin towards this single functionality of setup a mission than the bridge between gazebo and the autopilot.

[rchiossi]

@mbelluzzo I agree, but I don't think that just moving a functionality we have around the objects that we already have would change anything in the current project's perspective, yet it opens up for other use cases.