Gazebo crash on /delete_model service calls

[Arpafaucon]

Context

I was investigating the use of service gazebo/delete_model to clean up gazebo simulation without having to restart the server every time.
In current setup, re-spawning cf1, cf2, etc. fails as there are already existing models with that name. The objective was to ask gazebo to remove them before adding them back.

My scripts are however causing a runtime_error what()=timeout in gazebo server, that terminates.

Script

#!/bin/bash
rosservice call --wait /gazebo/delete_model "model_name: 'cf1'" && # ok
rosservice call --wait /gazebo/delete_model "model_name: 'cf2'" && # ok
rosservice call --wait /gazebo/delete_model "model_name: 'handler1'" && # crashes
echo "killed all gazebo models. Killing ./cf2 instances"
killall cf2

output:

arpad@APD-X3:~/dev/sp/migws/src/sp/sp_mate$ rosrun sp_mate clean_cf2.sh
success: True
status_message: "DeleteModel: successfully deleted model"
success: True
status_message: "DeleteModel: successfully deleted model"
ERROR: transport error completing service call: unable to receive data from sender, check sender's logs for details

Questions:

• is it a bug ?
• is there another way to close the handler ? This is probably related to the fact that I'm not sure I get what the handler's job is.

[wuwushrek]

This is definitely not handled. Spawning a new model to a handler could possibly work depending if you haven't reached the maximum cf per handler. But removing a cf model was not supposed to be done, Moreover Removing a handler is definitely not allowed. But fair enough that can be a useful feature !
I will propose a solution tonight. It may change the design of the handler Plugin.

[Arpafaucon]

Otherwise, would it be easier to implement a kind of 'reset' mechanism?
when called it would reset the internal state of the drone and its link position in gazebo server

[wuwushrek]

It's trickier than I thought because I need to do changes on the crazyflie-firmware part. Let me handle it this we and update you