Coordinate frames do not move when using ArduCopter with ROS

bn2021 commented 3 years ago

Bug report

AirSim Version/#commit: 1.4 and #b9c26181abfd473a5dc2f6a7bd1c1cd0149740f0
UE/Unity version: N/A
autopilot version: N/A
OS Version: Ubuntu 18.04 LTS

What's the issue you encountered?

I could not find anything about it, so I am not sure if this is a kind of intended behavior or a bug.

Using AirSim together with ROS works perfectly fine for me if SimpleFlight is set as VehicleType in the settings.json (Multirotor SimMode): Coordinate frames move as expected in rviz when flying around and sensor and image data is published on topics.

However, frames do not move as I would expect if ArduCopter as VehicleType is used. Then most of the frames, including the odom_local_ned frame, are located within the world frame (0, 0, 0) or in the location that was defined in the settings.json. Only some of the camera frames move.

Note: The AirSim ROS node was built from source, for the simulation itself one of the binaries is used.

Settings

Minimal settings:

{
  "SettingsVersion": 1.2,
  "SimMode": "Multirotor",
  "Vehicles": {
    "copter": {
      "VehicleType": "ArduCopter",
      "UdpPort": 9003,
      "ControlPort": 9002
    }
  }
}

How can the issue be reproduced?

Start AirSim
Run the AirSim-ROS-Node
For visualization run rviz: roslaunch airsim_ros_pkgs rviz.launch
Move vehicle (e.g. simple takeoff), using rosservice for SimpleFlight and ardupilot for ArduCopter
If SimpleFlight is used, the odom_local_ned frame moves. For ArduCopter it does not move.

Thank you for your great work! Maybe you can help or have an idea here. Thank you!

rajat2004 commented 3 years ago

I would say its a bit of intended behaviour. The AirSim-ArduPilot integration doesn't have state info flowing from AP to Airsim, which is supposed to be used for the movement APIs. It would be possible to add code so that the sensor data being sent by Airsim is also used for the state info APIs used by AirSim, however the data should be what the flight controller/firmware thinks the values are, which can be different from the simulated data. Therefore, the AP integration just returns NaN for most of the APIs, see ArduCopterApi.hpp

Instead, for controlling the vehicle and gathering such information, you can use pymavlink or Mavros for connecting to ArduPilot itself rather than through AirSim. Another intention of going about it this way was that these methods will be applicable for real vehicles as well, rather than the AirSim APIs which won't be. For some docs on using ROS with AP, see https://ardupilot.org/dev/docs/ros.html

Hope this helps!

bn2021 commented 3 years ago

Thank you @rajat2004!

Is it also intended behavior that some camera frames are moving using AirSim ROS with ArduCopter while other frames do not move? Are these camera poses reliable given your described case that a flight controller/ firmware may assume different data?

Thank you again and best regards!

rajat2004 commented 3 years ago

Hi, sorry for the late reply. The camera poses are present since the current ArduCopter (or other vehicle wrappers also) don't modify the image capture part, that is handled separately in the UE4 and Unity plugin part rather than in AirLib. Therefore, the info in these isn't removed which is probably what's causing some of those to move while others don't. As mentioned earlier, some of this info could be added in the APIs also (which currently return NaN), however it could differ from the firmware's estimation.

I myself haven't tested this, so I feel it would be wrong to arrive at a conclusion without some testing. For checking the divergence between the estimated and Airsim's position data, the GPS sensor API could be used. If you want, I could add some code to implement the data gathering APIs if it makes things simpler for testing.

microsoft / AirSim