UAV Setup Guides (Autopilot)
To perform the most of the back-end setup and ROS integration, the QUTAS Lab 450 is used. The main component is launched with the following command:
roslaunch qutas_lab_450 environment.launchProvided that the VICON server is running, and that objects are loaded into the VICON Tracker, the tracking information should automatically be added into ROS.
Some initial steps are required before continuing with the rest of this guide. It is recommended that you take the time to understand the flight controller and how to configure it.
Information on flashing Naze32 flight controllers with the robin firmware. Further documentation on configuration and calibration can be found here.
Information on configuring PX4 autopilots can be found here.
It is assumed that you have configured your autopilot, installed ROS, and set up a catkin workspace (located at ~/catkin_ws).
Interfacing the autopilot with ROS is the next big step. To do this, the MAVROS software is highly recommended.
Only follow these steps if MAVROS is not already installed and configured on your device (or you are getting errors regarding "geographiclib datasets").
Installation Steps
On Ubuntu, MAVROS is supported and available through the official ROS repositories. There are 2 main packages, "mavros" and "mavros-extras". It is recommended that both are installed. As a reference, the follow instructions are taken from the Binary Installation, run:
ROS Melodic
sudo apt ros-melodic-mavros ros-melodic-mavros-extras
ROS Kinetic
sudo apt ros-kinetic-mavros ros-kinetic-mavros-extras
To finish the installation, a set of geographic datasets must be installed (otherwise MAVROS will not start).
cd /tmp
wget https://raw.githubusercontent.com/mavlink/mavros/master/mavros/scripts/install_geographiclib_datasets.sh
chmod +x ./install_geographiclib_datasets.sh
sudo ./install_geographiclib_datasets.shBefore continuing, it is recommended that you look at the MAVROS page on the ROS Wiki to learn about each of the different plugins that are available.
To get MAVROS up and running, we first establish a connecting between the flight controller the computer running MAVROS:
- If using wireless telemetry, simply plug the telemetry devices into the flight controller and GCS (assuming that they are configured with the correct baud rate).
- If using doing a pass-through using an on-board computer:
- If using a Naze32 flight controller, ensure that the telemetry port used is set to a high-baud rate (e.g. 921600).
- If using a PX4-based autopiliot, you must enable the companion computer interface on your autopilot.
Now, with the telemetry connection established, and find out the device name on the computer that it is plugged into (it will most likely be something like: /dev/ttyUSB0).
MAVROS comes with a selection of launch files that you can use to connect straight to the UAV. It is recommended you copy these to a local directory so you can edit them freely without having to worry about your setup getting erased when you perform an update. The following commands will create an area to keep your personal launch files, and copy in the template MAVROS ones.
mkdir -p ~/catkin_ws/launch
cd ~/catkin_ws/launch
roscp mavros px4.launch ./
roscp mavros px4_pluginlists.yaml ./
roscp mavros px4_config.yaml ./The three files that have been copied into your launch directory do the following:
- px4.launch: is the generic launch file
- px4_pluginlists.yaml: a whitelist or blacklist of plugins for MAVROS to load (check here for a good whitelist for most systems)
- px4_config.yaml: a configuration file for all plugins
You will need to change a few things before you can actually launch MAVROS. First off, you have to tell the launch file where to look to find the pluginlists and config files. Open the launch file, and look for the lines:
<arg name="pluginlists_yaml" value="$(find mavros)/launch/px4_pluginlists.yaml" />
<arg name="config_yaml" value="$(find mavros)/launch/px4_config.yaml" />These must be changed to the directory where your local copies are. For example:
<arg name="pluginlists_yaml" value="/home/USERNAME/catkin_ws/launch/px4_pluginlists.yaml" />
<arg name="config_yaml" value="/home/USERNAME/catkin_ws/launch/px4_config.yaml" />Secondly, you will need to tell MAVROS what port and baud rate to use. Look for the line:
<arg name="fcu_url" default="/dev/ttyACM0:57600" />And change it to match your setup. For example:
<arg name="fcu_url" default="/dev/ttyUSB0:115200" />Or:
<arg name="fcu_url" default="/dev/ttyUSB0:921600" />With the launch files configured, you can run MAVROS with the following command:
roslaunch ~/catkin_ws/launch/px4.launchAs MAVROS starts, it will spit out a lot of messages. The last message that will be displayed before the autopilot is connected will say something along the lines of:
MAVROS started. MY ID 1.240, TARGET ID 1.1
If you get more messages after that, then your configuration worked! If not, the you may have got your serial port or baud rate incorrect.
Teleoperation is a means of testing the autonomous control of your UAV by transmitting attitude commands via the GCS to the autopilot, typically by using a joystick. This is not required (and can be somewhat tricky to perform), but is an option to verify the control inputs in the case that full autonomous control is not operating correctly.
Configuring and Performing Teleoperation
Before we continue, it is assumed that you are using a flight controller running a firmware that is compatible with the SET_ATTITUDE_TARGET MAVLINK message (such as the PX4 Firmware or robin). It is also assumed that you have MAVROS up and running on, with a stable connection to the flight controller, you have enabled the setpoint_raw MAVROS plugin, and that you have a catkin workspace configured and ready to use.
Firstly, download and compile the teleop_offboard_attitude package:
cd ~/catkin_ws/src
git clone https://github.com/qutas/teleop_offboard_attitude
cd ~/catkin_ws
catkin_make
source ~/catkin_ws/devel/setup.bashBefore we attempt a flight, it is a good idea to ensure that the joystick is operating in the right frame of reference, and is rotating as expected.
Copy the launch file to a local directory, and configure it:
cd ~/catkin_ws/launch
roscp teleop_offboard_attitude teleop.launch ./
nano teleop.launchFor most flight controllers with a compass, the frame of reference for controlling the UAV must be the world frame, so change the frame_id parameter to match. You can use the axis/roll, etc., parameters to set the joystick axis to match the expected function of the joystick. By default, this launch file should be almost perfect for most low-cost joysticks (such as the "Logitech Extreme 3D Pro"). You should also configure joy package parameters to select the correct joystick as well.
Note: If using a px4-based firmware, as of time of writing, they currently do not support mixed control of angular and rate setpoints. Be aware that yaw control may not work. i.e even if your joystick supports yaw, yaw rate commands will not work with angular commands for roll and pitch mode. Expect the UAV to orient with North on takeoff.
To test the configuration of the joystick, run the node, open rviz, and view the output pose of the teleop node: In terminal 1:
roslaunch ~/catkin_ws/launch/teleop.launchIn terminal 2:
rvizAdd in a pose plugin, and set the topic to (by default /teleop/goal/attitude). Moving the joystick should show a representation of the joystick responding accordingly. This will not display rate commands. It is recommended that you check the attitude setpoint topic (by default /mavros/setpoint_raw/attitude) to ensure that moving other axes of the joystick (e.g. throttle, yaw) respond accordingly. Remember that all inputs in this mode are in the ENU frame.
Note: The teleop_offboard_attitude node will not output any commands until the joystick is first moved. Additionally, it will set all axis to their center point (i.e. thrust will be set to 0.5 when you first bump the remote). This is due to the way joysticks interface in Linux and is unavoidable. For this reason, it is highly recommended that when you first start the node, you move the throttle axis, and reset it to 0 before continuing.
Next, prepare the UAV for flight and launch MAVROS. As your environment will most likely quite unique, this part won't have a guide.
Once you have your environment up and running, launch the telop node (if it isn't running already), disarm the safety on the UAV, and run the following commands to arm the UAV:
Note: the flight controller may safety mechanisms inbuilt to ensure that a UAV is not left armed. Usually a flight controller will expect some kind of throttle input within 5 seconds of arming, otherwise it will disarm itself automatically. It is recommended that if you need a little time before take-off, but after arming the UAV, you should bump the throttle slightly then set it to 0 to ensure the UAV does not automatically disarm.
PX4 Only
With the PX4 firmware, we first must request off-board mode before continuing:
rosrun mavros mavsys mode -c OFFBOARD
Robin Only
The default control mode for robin is off-board mode. Ensure that the attitude setpoints have been accepted by the flight controller before continuing. The following message (or something similar should be in the MAVROS logs):
[FCU] Off-board control connected!
All
It is recommended that you prepare another terminal with the disarm command ready, in case of emergency:
rosrun mavros mavsafety disarmArm the UAV, then you should be in full control:
rosrun mavros mavsafety armRemember to disarm the UAV after the flight is completed.
Due to the intricacies of using GPS enabled autopilots indoors, better results may be achieved using a ROS-based control stack to perform indoor position control of an autopilot. This provides the additional benefit being able to use a cheap flight controller rather than a complete autopilot.
There are a few major downsides however:
- Depending on your ideal autopilot choice, it may be some work to switch to/from the QUTAS Flight Stack
- Due to the need to run flight-critical software off-board the flight controller, the on-board computer must be powerful, or a low-latency, highly reliable communication link must exist to the ground station.
The most common integration of the QUTAS Flight stack is as follows:
- [Ignore this line]
- [Ignore this line]
- UAV State Feedback (mavros_msgs/State)
- Tracking Reference (nav_msgs/Path, geometry_msgs/PoseStamped)
- Attitude/Thrust Vector (mavros_msgs/AttitudeTarget)
- USB-Serial Converter (115200 Baud)
- Wireless Telemetry (900MHz)
- Serial Connection (115200 Baud)
- Assorted Hardware Interfaces (PWM, Analog)
- UAV Dynamics / VICON Cameras (Flight)
- Odometry Reading (geometry_msgs/PoseStamped, nav_msgs/Odometry)
- [Ignore this line]
As an example that may represent a typical indoor flying area, you will at least need to following:
- A position measurement (or a bridge from a motion capture system. e.g. vicon_bridge)
- An odometry estimation (using _pose_odom_node from the mavel package)
- Some form of navigation software (a simple waypoint script for example)
- A position controller (using mavel)
- An autopilot bridge (mavel was developed with mavros in mind, but anything that accepts an attitude command could work)
To use the mavel package, you must give it a stable steam of odometry messages, as well as some form of navigation goals. The navigation references can be either a position setpoint, a predefined path, or points to be interpolated into a spline. The control is performed in the frame the odometry message is given in (e.g. map frame), so ensure that the references are also in this frame. Once an o odometry stream is established, a navigation reference has been provided, and the state feedback states that the UAV is armed, mavel will begin transmission of attitude and thrust reference.
An example of the launch file is provided in the qutas_lab_450 package. To get the example running:
mkdir -p ~/catkin_ws/launch
roscp qutas_lab_450 example_flight_control.launch ~/catkin_ws/launch/control.launch
roscp mavel mavel_params.yaml ~/catkin_ws/launch/mavel_params.yamlFrom here, you will need to edit the newly created control.launch file to specify your UAV:
nano ~/catkin_ws/launch/control.launchThen change the following lines to the appropriate values for "uav_name" and the home file directory ("uavusrgX"):
<arg name="uav_name" default="uav" />
<rosparam command="load" file="/home/uavusrgX/catkin_ws/launch/mavel_params.yaml"/>You may also want to edit ~/catkin_ws/launch/mavel_params further down the line to better tune the position tracking performance of the UAV.
To launch the system, run:
roslaunch ~/catkin_ws/launch/control.launchIf you are setting up Mavel for a new flight environment (i.e. you cannot use the above example), or would like to know more about the steps undertaken.
Mavel from Scratch
Similar to the process used to obtain the launch files for mavel to the one used for mavros:
mkdir -p ~/catkin_ws/launch
cd ~/catkin_ws/launch
roscp mavel mavel.launch ./
roscp mavel mavel_params.yaml ./The mavel launch file will also have to be altered to tell it to use the local parameter file. Change the following line from:
<rosparam command="load" file="$(find mavel)/launch/mavel_params.yaml"/>To (remember to put in your username):
<rosparam command="load" file="/home/USERNAME/catkin_ws/launch/mavel_params.yaml"/>Your setup of mavel should now be ready to launch:
roslaunch ~/catkin_ws/launch/mavel.launchAs a final step, any high-level navigation interfaces will have to be remapped to use the /mavel/reference/contrail interfaces.
When perfoming positional/rotational control of a UAV, it is critical that the flight controller is aware of the local frame of reference, and, at the very least, it's current orientation to this frame. If flying indoors using a motion capture system, you cannot rely on your compass bearing to match the orientation of the flight area.
For this reason, it is required to send information from your motion capture system to the autopilot so it can extract an heading reading (such that it knows which way is forward). If you are using MAVROS, you should be able to send the pose as measured by the motion capture system to the mocap\_pose\_estimate plugin, and it will handle the rest. There may also be some configuring of the autopilot to ensure it accepts this estimate, so make sure you refer to the autopilot documents for more information on this. Depending on the autopilot you decide to use, you may need to configure it to be on the same frame of reference as what mavel is operation on (i.e. the same frame as the motion capture system, usually "map").
If using a VICON system (and the vicon_bridge node), you will need to add in a remapping to your mavros launch file to redirect the vicon information to the UAV. If you followed the guide above, add in one the following line near the top of px4.launch, replacing DRONENAME with the appropriate name set by the vicon_bridge.
If you are using high-speed connection (e.g. baud rate of 921600), you should be fine to simply connect the vicon_bridge interface directly to mavros by remapping:
<remap from="/mavros/mocap/pose" to="/vicon/DRONENAME/pose" />If you are using low-speed telemetry (e.g. baud rate of 115200), it is necessary to throttle the messages that are sent (in this case, we drop 9 out of 10 messages, reducing the throughput by 90%):
<node pkg="topic_tools" type="drop" name="mocap_drop" clear_params="true" output="screen"
args="/vicon/DRONENAME/pose 9 10 /mavros/mocap/pose"/>It is recommended that before attempting the first flight, you detach the propellers and manually move the UAV around the flight area to ensure the navigation and position control is operating as expected. It may be useful to view the feedback data from mavel/contrail in rviz to ensure the UAV is being guided to the correct location, then move the UAV to that location and ensure that the waypoint, etc., is registered as being reached by contrail.
Note: Before continuing, the takeoff test waypoints in the qutas_lab_450 are OK for your flight area:
- Takeoff: a single waypoint at location
[0.0,0.0,1.0]with heading[0.0]. - Landing: a single waypoint at location
[0.0,0.0,-0.2]with heading[0.0](the negative Z value is to ensure a nice landing).
To get the environment running, in separate terminals, run the following commands:
roslaunch qutas_lab_450 environment.launchroslaunch ~/catkin_ws/launch/px4.launchroslaunch ~/catkin_ws/launch/control.launchroslaunch qutas_lab_450 takeoff_test.launchHere is a rough checklist to ensure the system is running as expected:
- The backend (
qutas_lab_450 environment.launch) displays that vicon_bridge has located and is tracking the UAV. - MAVROS (
~/catkin_ws/launch/px4.launch) has successfully connected to the UAV, and it is ready to be controlled. - The flight plan (
qutas_lab_450 takeoff_test.launch) loads in and runs a basic takeoff/landing waypoint flight. - Mavel (
~/catkin_ws/launch/control.launch) displays that it has received a path and is only waiting for the UAV to be armed. - RVIZ and RQT are running as expected, and any data displayed looks correct
Once you have verified that the system is running as expected, use the MAVROS GUI in rqt to do the arming procedure:
- Set the flight mode to "OFFBOARD" (and ensure that the autopilot accepts the mode change in the MAVROS terminal).
- Send the "ARM" command.
You UAV should now perform a takeoff, and with any luck, will fly up and hover at the 1-metre waypoint, then land. You will have to manually disarm the UAV once it has landed.
Once you have performed a successful take-off test, the system should be ready to perform some autonomous navigation.
Preparing a Custom Flight Path
The first step is to copy across the launch file for that will perform your guidance:
cd ~/catkin_ws/launch
roscp qutas_lab_450 takeoff_test.launch ./guidance.launchThis will give you a new launch file in your catkin workspace launch directory that you can use to run missions. Running the following command will repeat the take-off test above:
roslaunch ~/catkin_ws/launch/guidance.launchTo load a different path plan, change the line:
<rosparam command="load" file="$(find qutas_lab_450)/config/takeoff_test.yaml"/>
To:
<rosparam command="load" file="/PATH/TO/PLAN.yaml"/>
When using mavel to perform position control...TODO!
Please find an example node for PWM overrides here.
TODO
- External Position Estimation
- MAVROS Mocap Pose Plugin
- Offboard Control
- MAVROS Offboard Example
- QUTAS Sample Code for MAVROS Offboard
By default, the PX4 Firmware failsafes are set to "Return to Launch" in the case of most emergencies. With the default parameters, this also means that the UAV will attempt to fly up to 30m, and navigate back to [0,0,30] before attempting a landing procedure.
The ideal is to have the failsafe in any condition to land immediately. Failsafe Settings
If you are performing any type of navigation, you should be able to use the custom mode "AUTO.LAND" to request an immediate landing.
Note: Due to the constantly changing firmware, you should ensure you have some sort of plan in case of an emergency (i.e. manual override). There are many different parameters that control "AUTO" modes, so ensure you have set any that may relate to the modes you are trying to work with.