Preplanned trajectory is a simple AERPAW sample application that reads a mission from a plan file and executes it. The mission plan consists of a series of waypoints (the first one located vertically above the take-off location) that are traversed in order. Upon reaching the end of the plan file, the vehicle return to the launch location, lands at the same location it took off from, and allows the vehicle to disarm. Only the Safety Pilot and the Operator can arm the vehicle.
There are two distinct ways to use the Preplanned Trajectory script:
The script is found in $VEHICLE_CONTROL/aerpawlib/examples/preplanned_trajectory.py
Sample missions are found under the subdirectory PreplannedTrajectory/Missions.
The easiest way to call the script is by using the provided startPreplannedTrajectory.sh in the ./ProfileScripts/Vehicle/ directory. See the running sample applications page for details.
To select preplanned trajectory as the vehicle application, please do the following:
$ cd /root/Profiles/ProfileScripts/Vehicle
$ cp Samples/startPreplannedTrajectory.sh startVehicle.sh
If you want to change some parameters in the sample vehicle experiment, please edit this file: /root/Profiles/ProfileScripts/Helper/preplannedTrajectoryHelper.sh
In that helper script you can change or add the following parameters:
--output: [default specified in GPSLogger] specific output file to use
--samplerate: [default 1Hz] sample rate in Hz (samples / sec)
--defaultspeed: [default 5m/s for UAVs and 1m/s for UGVs] unless a specific speed is specified in the .plan file for each waypoint, this speed will be used to navigate to waypoints; specified in m/s.
--look-at-heading: if set (in degrees of azimuth) the UAV will maintain the specified heading throughout the flight
The script is written in python3 and uses the AERPAW vehicle control library aerpawlib.
The connection string <connection str> specifies where to connect in the MAVLink tree (allowing the issued commands to reach the autopilot and the status messages to reach from autopilot to the script). At this time the script connects to the MAVLink filter. All commands issued this script are subject to filtering by the MAVLink filter. Currently the correct connection string for AERPAW (both testbed and development modes) is 192.168.32.26:14550 where the IP address corresponds to the E-VM IP address and the port is where the MAVLink filter expects to find the vehicle control script. Any other connect string will not work.
The <mission plan file> specifies the mission plan to be executed. For creating and editing mission plan files, check out this page.
The default mission plan file is available for download here.
The vehicle type is at this time either "drone" or "rover". The rover will ignore some of the instructions only applicable to drones (e.g., takeoff, and land commands), as well as having a different set of safety rules in the MAVLink filter.
The optional --output and --sample parameters control the output file of the GPS logging, as well as the sampling rate of the positions, same as in the GPS logger. The format of the resulting log in the csv file is also identical to the GPS logger.
The AERPAW team tried (hard) to provide checks on the mission plan (see the checkPlan.sh script, as well as instructions on using the GeoFence ). However, the Experimenter has full control in the E-VM and, at times, may not check a plan, or modify a plan after it was checked. If an invalid plan is being supplied to the PreplannedTrajectory sample application, the sample application will start the mission, but will stop in its tracks when the UAV reaches the failed leg of the plan. When that happens, the drone will freeze in place, waiting for the operator or the safety pilot to tell it what should do next (at that point the instructions coming from the Experimenter's code should not be trusted anymore). In development mode, the Experimenter also plays the role of the Operator and Safety Pilot, so it should save the poor drone from its predicament. The Experimenter can do this in several ways:
by resetting the whole experiment (run reset.sh from any of the E-VMs). Of course, this resets the entire development environment.
by commanding the drone to "Return to Launch" (RTL). This can be done:
Either in QGroundControl - there is an RTL button next to the drone, or
Through the mavproxy shell in the OEO Console, by typing: <n> set_mode rtl where <n> is the node number you want to return back to launch.
Most commonly used autopilots allow a user to create and use a mission plan file to file a preplanned trajectory mission by uploading the mission plan file directly to the autopilot. The AERPAW platform does not support this mode of operation. Instead, in the AERPAW platform, the plan file is used as an input file for the preplanned trajectory sample application, which in turn runs on the companion computer (part of the portable node). The perceived end result is the same: a user creates a mission plan file, and the vehicle eventually follows when executed on the testbed, but the way the implementation is vastly different. AERPAW chose to use a python script to traverse the mission plan file (and issue the commands one after the other) for several reasons, including flexibility, extensibility, and safety.