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.
I think we should replace my page http://dev.ardupilot.com/wiki/using-rosgazebo-simulator-with-sitl/ on it. Because this variant is more powerful.
HCUAV never actually flew (as of now), so I couldn't tell you if the simulation was accurate. I just encoded the number the aerodynamics team provided me.
Indeed, I was struggling a lot with APM-SITL communication and ground friction and contact specifics with which you and Gazebo seem to cope much better.
On the other hand, I prefer (and as you said have managed) to create mathematical models which make the simulation more realistic.
It would be nice if we somehow could cooperate to some degree; there is only one obstacle that I can think of, aside from the ever-present coordination issue of remote partners:
So far, I have been developing last_letter for fun. I like tackling new programming problems and find ways to implement them. Such was the case of the environment node, where I used a separate environment simulator to run alongside the vehicle and provide it with wind, temperature and pressure data.
In the case of cooperative projects, I image that the software structure would be much more rigid and may inhibit such innovation.
What do you think?
Looking forward to those new docs - probably enhance or replace http://dev.ardupilot.com/wiki/using-rosgazebo-simulator-with-sitl/ ?
If you need help getting setup with wiki accesses, I'm the right person to talk to.
Thank you very much for your support :-)
Indeed the parachute will now allow easier checks of the well-behavior of the EKF when the copter is disarmed but still in mid-air.
Although every parachute releases in the video were commanded manually from the ground station, it is possible to check the auto-release (when the autopilot is unable to get the attitude it wants for X seconds). We saw the case when the UAV hit houses or hills, after a few seconds of struggling against it, the autopilot would release the parachute.
The tutorial linked was actually written for a Gazebo setup on a virtual machine on Windows. There is a pdf/LibreOffice text, and 5 installation scripts to cover each step of the process:
However it is a bit outdated, for it installs Alex's ROS version (his bitbucket project, ...). We will update and clean it up.
And yes we will see with Hamish to update the wiki.
I have heard of last_letter but have not tried it yet. Yesterday I looked a bit at your code, and it is impressive! You did an enormous work! I really liked your detailed equations for electric motor propulsion, your implementation of a wind turbulence model, and your lift/drag shape curves. It seems to be even more accurate than JSBSim!
Have you been able to compare your flight results with a test flight of a real HCUAV ?
In our case the aerodynamic code used is a fork from the Lift/Drag plugin implemented in Gazebo, with a few modifications. Coefficients of lift, drag, moment, are evaluated from simple bi-segments linear approximations: 1 segment for small angles of attack, and 2nd with a different slope for the stall part. Maxime modified/tuned them with the parameters from a real Cessna. The propeller of the plane also makes use of the lift/drag plugin on each blade, while quadcopter rotors rely on the rotor_simulators plugin from PX4 team (they use the model rotor_thrust = kt*omega^2).
Surely dynamics are not as accurate as last_letter, however our choice with Gazebo was for a simulation more oriented toward functional tests, especially for proximity sensors, like range finders for obstacle avoidance, and such.
I think your equations, and wind model, could greatly benefit this simulator. Indeed there is currently no wind at all.
rotor_simulators has an implementation of wind system, but it is a bit too simplist to really challenge the autopilot: a mere constant force applied on the UAV.
(Ultimately it would also be nice to have a small GUI to modify wind/simulation parameters in real time.)
We are working on documentation with some schematics (sim_vehicle, folders architecture, etc). We will push it to the wiki around Christmas.
The whole setup process is described in "Tutorial to setup SITL Gazebo on Windows - v0.8.pdf" (September 9...).
On our "https://github.com/AurelienRoy/ardupilot_sitl_ros_tutorial" you will see all steps to install ROS, Gazebo and ArduPilot. This version is outdated but contain all the basics to install Linux and a first working model with Gazebo. We agree we did not yet update the scripts (referring our git instead of first contributors). Soon. But you can install it right now and switch the folders. If you have issues do not hesitate to mail me.
Heli could be possible yes, as we worked with plugins like liftDrag (Airplane, propeller) or rotors_sim (multirotor). You will not have to code the dynamics. Instead, you need to create a new Gazebo model (joint, links, .dae) and most of the work will be on the Heli plugin in ROS/Gazebo (not implemented yet).
@Oliver, John Dennings and Victor Mayoral :
Thanks for your enthusiasm ! We did not count hours and sleepless nights, hopefully this will help devs and owners to mastery Ardu UAVs.
You mentioned a tutorial. I took a quick glance at the github repo but didn't find anything relevant.
Are there launching instructions or a gitter channel?
This is great. Well done!
A huge milestone for APM I'd say. Many roboticists will now get attracted by this.
This is great! I was looking at Gazebo the last few weeks to make the next step of last_letter (my simulator) but it looks you beat me to it.
I hope it will be possible to merge some work here. Cheers!