osrf-migration
commented
7 years ago Open osrf-migration opened 7 years ago
osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago osrf-migration
commented
7 years ago Original comment by pierre kancir (Bitbucket: pkancir).
Hello ! Nice idea!
I work on the ardupilot side from time to time. The main issue I see is the frame conversion that are missing in gazebo. If we take gazebo GPS output for example, it is in NWU frame with no way to change it, and ardupilot (and I assume PX4 ) want NED frame input. (90° offset hack isn't nice for newcomer )
osrf-migration
commented
7 years ago Original comment by James Goppert (Bitbucket: jgoppert).
Right, we handle the frame conversion in the gazebo mavlink currently. I'm currently leaning towards the mavlink approach. Mavlink is a stable protocol and it will maintain backwards compatibility with new updates. If I compile px4 against a specific gazebo version it won't be as flexible. I would also like the ability to specify the autopilot binary in the sdf and have gazebo handle everything. My question there is how to give the user terminal access to the shell easily and make it cross platform. Boost seems to have a process library
Original report (archived issue) by James Goppert (Bitbucket: jgoppert).
I am trying to integrate the PX4 and rotors gazebo plugins back into Gazebo upstream. I took a look at the ArduCopter plugin, but it seems this sends a limited set of data over a socket (position, velocity, accelerate, angular velocity), some of this is passed form the imu to get noise, but it doesn't meet the fidelity of our current gazebo plugins.
Sensor Level SITL Requirements
For PX4/rotors sitl we are using the native gazebo sensor models instead of reconstructing the data on the other side, we would need the following sensor packets:
Current Transport Approach (gazebo plugin) <-> mavlink <-> (px4 sitl)
We are currently using MAVLink as the transport protocol over a socket instead of just a custom struct. The advantage is that we can use the predefined sensor packet types in MAVLink. The disadvantage is adding a dependency for MAVLink to gazebo.
Alternate Approach: Use Gazebo Transport API (gazebo) <-> (gazebo pub/sub) <-> (px4 sitl)
Another approach would be to use the gazebo transport api on the px4 SITL side and subscribe to the corresponding topics for each vehicle. I think the question is which approach (gazebo transpose or MAVLink) would be the most robust and require the least software maintenance.
Optical Flow Plugin
The optical flow plugin depends on opencv. I investigated and, due to the avplugin, this is already an implicit dependency of gazebo. Instead of just faking the optical flow data, we actually compute optical flow given the camera image. Granted this takes a little bit of cpu, but it makes testing how texture, rotation rates, and the flow algorithm impact the performance. I think there should probably be a model that does this, and then another model that just calculates the values given the true velocities and adds a noise model to try to represent some of these effects.