Gazebo is a real time physics simulator with many promising features for the simulation of the next generation of UAVs, self-aware of their environment.
As presented on previous posts, especially from the ASL team from ETH Zurich who interfaced PX4 with Gazebo, from Alexandr Buyval who posted the first interface for ArduCopter, or from Patrick Nolan, Gazebo offers the simulation of a variety of sensors. It includes models of ultrasound range finders, cameras, lidars, stereo cameras, etc. These combinations make Gazebo well suited to simulate indoor flights or close to obstacles.
Gazebo runs along ROS (Robot Operating System) which is a software framework containing libraries for message-passing, package management, visualizers, device drivers, etc.
This update fully restructures in "C++ the Ardupilot – ROS/Gazebo” plugin interface in order to bring out:
- an improved simulation stability and deterministic UAV response (step lock mechanism) ;
- a simplified ROS/Gazebo simulation launch, fully configurable through arguments to the well-used SITL launch script, sim_vehicle.sh ;
- integration of the GPS sensor provided by Hector's plugin ;
- the simulation of ArduPlane, with a Cessna model provided as an example for custom fixed-wing designs ;
- a georeferenced overlay map image on MavProxy, to better assess the UAV position relative to its simulated environment ;
- a new custom mode, Wall Follow, for precise distance control to vertical surfaces, as an example of new sensor use on Gazebo ;
- a safeguard parachute, releasable by the autopilot
With this update we hope the Ardupilot ROS/Gazebo SITL will have achieved a high enough stability and ease-of-use to become a common simulator for all phases of the engineering V-model:
- prototype new designs for specific applications, and virtually test various combinations of sensor payloads and flight modes before moving to real hardware ;
- debug in real-time Ardupilot, and even the communication between Ground Stations and the autopilot ;
- ultimately validate functions are well-behaved.
Besides conception usefulness, the ROS/Gazebo SITL simulator is also very helpful for new pilots to train on RC piloting, or for veterans to hone their skills in parameter tuning.
Next step would be to interface DroneAPI's code with ROS/Gazebo topic messages, as well as the simulation launch mechanism, to be able to run custom DroneAPI image processing codes over Gazebo camera frames. By achieving this, the SITL would close the loop of UAV system simulation.
In conclusion it is a great test bench for all the cool new functions and flight modes of the community!
All source codes are available on our Github:
https://github.com/AurelienRoy/ardupilot/tree/wall_follow branch wall_follow
https://github.com/AurelienRoy/mavlink-gbp-release/tree/wall_follow branch wall_follow
https://github.com/AurelienRoy/MAVProxy/tree/map_overlay branch map_overlay
The step lock mechanism enforces a pause of the Gazebo simulation until it receives the next motor command from Ardupilot. It then steps forward the simulation by 2.5 ms (for the 400 Hz update rate on Pixhawk hardware) and sends back new sensor measurements to Ardupilot. Unlike many controller simulations on Gazebo, Ardupilot is the master of the simulation clock.
This solution prevents Ardupilot from missing time steps when running on slow computers, thus improving the overall stability. Among other benefits, the debugging of Ardupilot is much easier: when its execution stops at a breakpoint, the simulation automatically stays on a standstill.
Among discomforts, in simulations with ground stations maps, you cannot properly assess the UAV position relative to its surroundings. This issue is now solved, at least for MavProxy, with the possibility to overlay a georeferenced map image. The image file path is specified as argument to MavProxy, by the SITL launch script, with the simulation start location defining the image's center geolocation.
Unfortunately the Gazebo orthographic projection camera, which would be much useful to create maps from screenshots, only arrives in Gazebo 6.0, with the Kinetic Kane ROS version (may 2016).
Parachute release :
In order to stress test safety mechanisms of Ardupilot, a parachute has been modeled and appears when the autopilot activates the release servo. This development leads the way for dynamic model insertion, which can be useful for special actions like saving a lost hiker with an accurate water bottle drop (UAV Outback Challenge 2014).
Wall-Follow Mode :
It is a new mode we conceived for our project's special needs.
It is an aiding system for pilots making close shots along a structure's surface. All commands are relative to a virtual wall plane, which is similar to the Simple mode. It combines a Loiter controller for the lateral axis (= parallel to the wall), and a distance controller on the forward axis (= toward the wall).
The pilot can freely control lateral movement (roll command), and height (throttle). The wall plane orientation is fixed as perpendicular to the UAV's yaw angle upon entering the mode, and the target distance is a parameter.
To maintain a good behavior even when facing surfaces with holes, or high granularity, the controller includes with a special filtering of frontal range measures, fully configurable through parameters. This way the UAV maintains a straight trajectory, despite gaps.
An equivalent wall-follow waypoint control is underway, for wall planes parallel to waypoint legs.
The development of this feature had to be rushed for the needs of the video. It has not yet been thoroughly tested, and any test on a real UAV should be performed with caution.
This is fantastic.
In this plugin we did not use kbteleop, in all scenes with manual control the joystick was plugged in MissionPlanner on a 2nd laptop.
So in teleop.launch we commented the joystick node line.
I have not tried kpteleop. But for keyboard control, you can also use MavProxy, by typing RC commands
like "rc 3 1500". See MavProxy documentation
Fantastic work! I'm maintaining the official Dronecode Gazebo plugin. We're currently working hard to bring more coordination and rigor to our simulation ecosystem and it would be great to discuss how we can re-integrate your work into upstream Dronecode. I've filed an issue to discuss this: https://github.com/AurelienRoy/ardupilot_sitl_gazebo_plugin/issues/2
I don't have a joystick so I am trying to use the kbteleop (mavros_extras/launch/kbteleop.launch) instead of teleop.launch but this fails.
I was wondering if somebody tried it before. I am a ROS beginner, I would appreciate any pointers.
Thanks for your work on this and everybody involved!
Thanks @AurelienRoy. I've set myself a reminder here https://github.com/diydrones/ardupilot-wiki-issue-tracker/issues/251 - and you can ping me on github there too when you need logins to wiki
Hi @Hamish Willee
Thanks for your interest, yes we will update the Gazebo page that Alex did. Maxime and I are a bit in a rush these days, that is why we answer a bit slowly to messages.
We will certainly need help for wiki accesses, but before we will maybe push our code back to the main Ardupilot project, and draw some useful documentation schematics we had in mind. Feel free to send us a message if you do not have any news from us for too long.
Thank you ! We would not have managed it without your original posts on Gazebo in August.
Thanks ! Indeed Gazebo - APM HIL is next step. I saw in your posts in DIY you have made some progress about it.
I wish you good luck, these things ain't easy ;-)
Okay, I see now how you intend to approach your project. I hope we'll be in touch again soon.
Gazebo uses the physic engine ODE (and now also Bullet, Dart), which is perfect for computing collisions and joints between 2 parts (hinge, slider, etc., with friction or not, ...). Although joints are not very useful in the case of multicopters, they have their use for the airplane control surfaces.
However Gazebo does not natively include the equations for the torque of an electric engine, or a gas engine, and the aerodynamic part works well but is a bit crude for more complex tests/cases (no wind, ...).
On Gazebo's roadmap, I see they have many more things planned before the wind (expected in 2018 ;-) ).
I will look more in details at your code structure, and maybe you can do the same for ours, so that we can discuss structure ideas and on what we can benefit from each other's simulation.
The aerodynamics natively handled by Gazebo is actually bundled in a LiftDrag plugin (similar to a ROS node) with topics and a callback on each simulation step. (which Maxime forked to get a custom LiftDrag plugin.)
So distinct additional things, like the wind, can still keep in Gazebo a node structure as you used in last_letter. And we are flexible on the code/program structure.
An alternative is to add evolutions directly in the Gazebo project instead of just in this interface. But they will need to be accepted by Gazebo's dev team, and general enough to be useful to anyone.
We initially developped the first brick of this simulation with a professional project in mind, however I think we will mainly continue its development as a hobby on our leisure time. So I may not be able to dedicate it a lot of time,
I will see.
@AlexBuyval It probably does make sense to replace your page. It will be a good starting point for them :-)
@Aurelien ROY and @Maxx_UAV
Great work! I can't wait to give it a try, it looks really powerful. If I have any time, I may want to look into doing some of the same things with a HIL setup instead of the SW executable. But for now, this looks like a great package. Thanks again for all the great work!