ArduCopter SITL + MAVROS: Instability while moving towards goal

[BurakHocaoglu]

Hello,

I have been using ArduCopter SITL connected to AirSim and controlled over MAVROS with correct UDP ports for some basic experimentation. There are not any particular problems with arming/disarming or mode change; however, when I set a goal (sending takeoff with /mavros/cmd/takeoff service, publishing setpoint with /mavros/setpoint_position/local topic at 10 Hz and 20 Hz), I observed some sort of indecisiveness. At the goal, in both simulations, the overshoot or the effort to stay at the goal is similar. However, in Gazebo, when I set a goal, copter would not lose time and get there quickly, but in AirSim, it seemed like my setpoints (or the goals that are internally generated for stable flight, unknown to the user, if applicable) are taken by copter with a delay; hence, leading the copter to do the overshoots in the middle of the flight towards the goal I set for it. It reaches its goal eventually, but takes time to do that.

• Is it something to be expected because AirSim is quite large in resource use compared to Gazebo, but it gets help from GPU, I guess?

• OR is there any threshold for setpoint publish rate that I can adjust so that the so-called indecisiveness would decrease?

Experimental Setup

Software

• Ubuntu 16.04 LTS
• Unreal Engine 4.18
• AirSim >= 1.2.0 (built last Thursday)
• Python 2.7.12
• Gazebo 7.14 (I used SwiftGust for MAVROS and ArduCopter SITL connection)

Hardware (don't know if it matters)

• Intel Core i7 - 5820K, 3.3 GHz with 6 cores & 12 Threads
• NVIDIA GeForce GTX 970, 4 GB
• 32 GB RAM

Kind regards,

Burak

[rajat2004]

@BurakHocaoglu Sorry for the late reply and thanks for the detailed report! I'll try to look into it as soon as possible

If possible, could you open a similar issue on the ArduPilot repository, since this is specific to ArduPilot and the devs there would be able to try and figure out what's happening in a better way.

AirSim runs at a lower physics rate, but since lock-stepping is present in the SITL-AirSim connection, (hopefully) it shouldn't be the cause. It could be some inconsistencies in the GPS data.
I don't think this would be the case, but does something similar happen with the normal SITL in Ardupilot?

Logs with the Mavros and AirSim simulation would be really great since that'll help in figuring out any problems

Hope this helps!

[BurakHocaoglu]

@rajat2004 No problem, but I have another point that you may have an idea about, which I think might be the problem with my case. In the original issue I said the correct UDP ports; however, I said so because of a trial-by-error experimentation with trying to figure out how to control the quadrotor in AirSim with MAVROS. I was running the following:

roslaunch mavros apm.launch fcu_url:=udp://:14550@127.0.0.1:9003

The thing is UDP port 9003 is the sensor binding port of ArduCopter SITL. When I run sim_vehicle.py, I see that there are a couple UDP ports to examine: 5501, 14550, 14551. When I examined the source code, 5501 was put there as SITL port; so, if I change 9003 to 5501, MAVROS still works (but that might be that the remote host part after @ sign may not be properly processed because everything runs internally). I think I might be using the wrong UDP ports and end up with a congestion in resources (Gazebo still works fine, but it does not make use of the ports of 9002 and 9003) or somehow I incorrectly connected the processes and my issue happens. What do you think?

[xlong0513]

@BurakHocaoglu Hi, i wonder how did u set mavros to communicate with airsim and QGC? Is there any lessons? Cause i didn't find the way. Appreciate it.

[BurakHocaoglu]

@xlong0513 Hi, I might be wrong, but I will try to state my experience so far with the port connections between MAVROS, AirSim and QGC.

To be able to use QGC properly you need to start SITL with sim_vehicle.py, because it also runs an instance of MAVProxy GCS which opens 2 UDP output ports (14550 and 14551, if you use -IX, where X is the instance number, then ports will be 14550 + 10X and 14551 + 10X), one of which will be used by QGC (default 14550) and the other would be by MAVROS. If you do not, then you will get Address already in use errors when launching MAVROS.

However, if you start SITL from the binary located in ardupilot/build/sitl/bin/, then you won't get a UDP port multiplexing like this and you won't be able to run MAVROS and QGC simultaneously since both, by default, expects the UDP port 14550 to be free and while one is running the other can't be used properly (QGC would start, but will wait indefinitely for a vehicle to connect).

Regards,

Burak

[xlong0513]

@BurakHocaoglu Hi, thanks a a lot. The problem is solved with PX4(v1.8.2). I ficed my problem with the setting in GAAS.
But AirSim craushed everytime i quit? Do u know what the problem is?

[BurakHocaoglu]

You need to close AirSim before SITL(s), because of AirSim's packet listening will still go on and AirSim will hang up, if you try to close SITL(s) in the first place.

[xlong0513]

@BurakHocaoglu i think it's a setting problem, cause it crushed sitll if i run AirSim only.

[BurakHocaoglu]

Hi there,

It seems ArduCopter SITL works different than PX4 SITL, where a user needs to send setpoint commands with a rate of 2 Hz at minimum. I observed that ArduCopter SITL can work with publishing to MAVROS topics or requesting it's services once. When I was running my node with setpoint publishes at 20 Hz, I think I caused a congestion in the general motion mechanism upon a command retrieval by constantly saying go, go, go. I realized this when I killed the publisher ROS node and the robot flew to the target pretty smoothly.

However, the altitude control at the target (hovering) is not very good, as I witnessed (+-) 2-3 meters of error on z-axis sometimes (xy-plane seems fine). Maybe its a phenomenon of realism displayed by SITL in AirSim.

Thanks,

Burak