Blogs

Hi,

I - Intro:

We have seen recent press announcements of big names investing lots of effort and money in package delivery using drones: Amazon, Google, Nasa (Flirtey), DHL, etc... These organizations are spending huge sums of money, as a non-public private research, to carry drone deliveries, and this for a few years. In the meantime, our modest diydrones community, that means you, have got all the means to build a drone delivery system. It is impressive how since a couple of years that I am active in this community so much has been produced and gathered in competence, skills, developments of open source hardware & open source software.

Especially, a big thanks to diydrones community developers, 3DR for promoting it and also ETH Zurich/3DR who have produced a very reliable Pixhawk autopilot, building up competences and skills to levels that even Amazon and/or Google would dream of internalizing. That's the magic of open source: you get better team work and results with free willing motivated volunteers in comparison with typical corporate organizations.

This blog synthesizes hardware, software configuration information in an attempt to explain how to make a drone delivery, fully autonomous, mission.

II - Delivery mission’s preparation:

II.1 - Safety message:

This video does not intend to promote an illegal nor reckless use of drones. So first thing is ensuring you are in legal order to execute such a delivery mission in accordance to your local regulatory authorities. The mission is here executed fully above privately owned properties with agreement of their owners, in a rural non populated area, keeping permanent line of sight, either from the departure or arrival location (two operators are prepositioned at departure and arrival sites for precaution and take manual control over in case of emergency.

II.2 - Analysis of the delivery mission’s path:

A careful analysis is required of the delivery path the drone will follow in order to: avoid obstacles as we do not have any technologies to detect them yet real time in flight (such as electrical lines for ex), fly around any populated areas to avoid them, take into account the terrain’s topology along the way to avoid hitting hills, mountains, trees,...

To take into account the topography, you have two options in current’s mission planner:

• you can plan you waypoints at different altitudes, taking into account the relative altitude differences between waypoints (manual altitude offset management – that is the method that was chosen for this mission as described further);

• you could plan your waypoints as usual in mission planner and check the “verify height” checkbox in mission planner’s flight plan window. In this case, the google map ground altitude for each waypoint is added to your waypoint desired altitude. This is theoretically a safer way to go than first method; however we noticed in our tests a few issues: mission planner’s ground altitudes are not the same as google earth altitudes (strange discrepancy) with differences of a few meters (enough to crash!) and google altitudes are incorrect (sometimes also by a few meters);  

A future third method will be the best of all, once ready for use: in a next release(s) of APM:Copter, terrain following will be made possible (already available in APM:Plane 3.x). That consists in storing, on Pixhawk’s autopilot microSD card, a terrain database which gives the terrain height in meters above sea level for a grid of geographic locations. Terrain following is different than the current “very height” method as the autopilot will permanently check the topology’s height variations to correct the drone’s altitude (versus the verify height method that only checks the altitude at waypoints, but not between them).

For this current delivery mission, the following manual topology analysis has been done, preferring to calculate and plot the terrain’s height variations manually. The following picture and graph shows the altitude (in meters) of the delivery mission’s path, with departure location (“Home” point) on the left and the arrival location on the right (“delivery target”). The intended delivery mission paths, roundtrip, is a little bit more than 1,5km long (or about 1 mile long for non-MKSA countries):

The picture shows a visual Google Earth representation of the full delivery mission and the ground’s altitude topology along its way.

From such a graph, we now know that:

• Home altitude is 265 meters
• Target altitude is 298 meters

By difference, an offset of 33 meters must be added to the destination’s waypoints altitudes; further add a safety margin of a few extra meters in order to take into account of :

• Pixhawk’s barometer drift issue (that we have discussed already a few times on diydrones) when flying more than a few minutes.
• the Google Earth altitude precision errors
• your own eventual calculation precision errors!
• Total ground travel distance is 765 meters, one way. Be aware that, when flying, your drone will also spend some “travel distances” vertically between waypoints to reach desired altitudes (that has an impact on your batteries/autonomy calculations!)
• In this example, there are no higher obstacles above 298 meters. There could be towers, electrical lines, etc…DO NOT FORGET to add a safety margin on your waypoints altitudes to mitigate these eventual obstacles! The only good way to do this is a ground survey at destination. Do NOT RELY solely on Google satellite images as they may date from few years (and in the meantime some pylons, towers and trees may have grown J).

Thus make a thorough terrain reconnaissance, not only at departure and arrival points. Check google map data and complete its imprecisions with a field survey.

III - Hardware & Software configuration:

III.1 – UAV ship hardware selection

For such a delivery mission a reliable ship must be used. It must at least comply with the following requirements:

• its lift capacity must exceed with a margin the all-up-weight including payload;
• must have an autonomy that exceeds with a margin the total flight’s duration;
• must have longest range as possible telemetry for command & control capabilities (+RC transmitter as a backup);
• must have redundancy on all critical components for a safe auto mission: redundant motors, two GPS, external compass, etc…

These minimum requirements de facto exclude the use of drone toys or quadcopters. Do not use a drone that is designed for video/pictures applications (such as an IRIS, a Solo, a DJI phantom) to deliver packages: they will not have the required level of safety, nor the capacity to do it.

Being a custom drone builder, AirbotServices chose its X8 model as briefly described in pictures below:

III.2 - Package lock/drop mechanism:

The transported package must be securely fixed to the drone and a release mechanism must be triggered automatically by the autopilot. A good way to do this, limited to packages lighter than one kg, is using Nicadrone’s electro permanent magnet (EPM). A newer EPM version is said to carry heavier payloads but I can’t confirm it. The principle of EPM is a magnet that can be activated and deactivated dynamically by a commanding signal.

The EPM has four mounting screws to be fixed to the drone. A standard PWM servo cable is plugged on one side on the PWM EPM input, and on the other side on one of Pixhawk’s AUX1 (RC9) to AUX4 (RC12) outputs. Actually, for a reason explained further in the trigger mechanism, only RC9 to RC11 can be used with current stable APM:Copter 3.2.1 firmware.

A metal plate such as this,

is fixed to the package. This iron plate matches the magnetized square surface of the EPM device. Although EPM holding strength has been tested by others to maximum 1 Kg of payload, I recommend to mechanically block any “yaw” movement of the metal plate against the EPM magnetized surface; indeed the strength of such magnet is in the vertical Z direction, not in the X or Y directions, where the payload can slip very easily. In this particular case, four little aluminum blockers were glued parallel and against the four metal plate edges. In a way such that any yaw movement of the payload versus the EPM base is avoided.

Furthermore, as a lesson learned the hard way during testing sessions, be careful not to fix the metal plate directly on a metallic package: indeed the magnetization flux is dispersed outside the fixing plate and the overall resulting locking strength is weakened doing so!

Attachment point and vibrations considerations:

A package adds a large surface area to your drone that will as a consequence catch more wind than usual. Furthermore, vibrations of your transport ship will be affected by the added mass and the way it is fixed (how rigid it is) to it.

APM:Copter is sensitive to vibrations and to keep vibrations low is critical for a safe flight as it impacts the compasses, among other things. Without a working compass, a flyaway is guaranteed…In future 3.3 version, vibrations management has been improved but for now, keep them low. It is thus a good idea to dampen and isolate the transported package from the part of your ship’s frame carrying the Pixhawk autopilot. It is even better if you can fix the package to a vibration free zone of your ship you use usually for your cameras.

During testing sessions, it was found that a “hard screw” fixing was the least reliable solution to secure the package and mitigate vibrations; with package losses due to forces exceeding the 1kg holding force of EPM. Reliable results were found with rubber bobbins (secured enough in tensile strength but still offering some elasticity between the payload and the ship’s structure).

On the side of the package fixing point, where the metal plate is fixed, various methods were tried from simple scotch tape to hot glue, etc.. Best method was simply…Velcro. Velcro does not melt under the sun (as would hot glue during a summer delivery mission) and offers some elasticity and vibration isolation.

III.3 – EPM lock/drop control configuration:

The EPM gripper works by sending three different PWM values to its servo input:

• a neutral value of 1500 us when the EPM gripper is at rest. This rest state does not consume any power so it is best to leave EPM’s state at neutral when it is not in the action of locking or dropping the payload;
• a low value below 1100 us to drop the payload;
• a high value above 1800 us to lock the payload.

So the functioning sequence becomes:

• to lock the payload : set the PWM signal high for a duration of about one second (the EPM secures best when it is able to cycle a few times its magnet. This takes a bit of time. One second is typically good). Then set the PWM value to neutral.
• to drop the payload : set the PWM signal to low for a duration of one second. Then set the PWM signal back to neutral.

According to APM:Copter online documentation EPM PWM signal may bet set via a consecutive pair of  DO_SET_SERVO commands. However this did not work in practice as these commands do not allow to maintain the commanded PWM values for a predefined duration (ideally one second). Apparently the default duration of these commands is too short to reliably command the EPM gripper.

Instead, the DO_DIGICAM_CONTROL command is used. This command offers the advantage that it works reliably, reduces the number of commands from two to one and allows to define precisely the PWM signal duration (by tenths of a second). This is how to configure it:

1. Connect a servo cable between EPM and one of the AUX1 (RC9) to AUX3 (RC11) ports of Pixhawk (AUX4 can’t be used as it is not displayed in mission planner camera trigger dop down list). Lets’ assume RC11 for this example.
2. Open and connect mission planner to Pixhawk. Go to the initial setup / optional hardware/Camera gimbal menu. Set the shutter option to RC11, set the shutter pushed value to 1900 when you want to lock the payload to EPM; or set it to 1100 when the payload is already fixed to EPM and you’re ready for the drop mission. As shown in pictures below:

Picture above : RC11 configured as the Pixhawk AUX EPM commanding port. Shutter pushed value set to 1900 to lock the payload.

Picture above : Shutter configured to 1100 value (unlock or drop value)

• Open then the config/tuning “Extended tuning” window to set the Ch7 option to “Camera trigger”, as shown in image below:

To test the setup is functional,

• To test payload lock: follow the steps above by setting the RC11 “pushed” value to 1900; then go in the main flight data screen; hold the payload against EPM; right click on the map to have thr drop down action list displayed and select “Trigger camera now”. You should hear a few clicks from the EPM indicating that the payload is secured.
• To test payload drop: same steps as above except the “Pushed” value must be set to 1100. A right click on “Trigger camera now” should release your payload.

IV – Essential APM:Copter parameters to setup:

All parameters are describe in details in various APM:Copter documentation pages. We provide below a list of the critical ones for a delivery mission.

IV.1 – Failsafe parameters:

In a delivery mission it is most probable you’ll loose intermittently or permanently your manual RC control link and your GCS telemetry link. There are different setup choices of failsafe actions in these conditions but the obvious way to go is: “failsafe action and continue with Auto mission”.

In such a delivery mission you probably do not want the ship to land in the middle of the woods once batteries are exhausted. So the first obvious action is to double check your batteries are functioning properly and are fully charged. To verify your batteries are functioning properly and that all LiPo cells look good, we strongly advise to use a battery resistance meter (this check function is integrated in good battery chargers). The measured resistance of all battery cells should be around a few milliOhms and about the same value for all cells. If some cells have a significant higher resistance, do not use these batteries for such delivery missions! (use these batteries for bench tests or less hazardous uses). If a battery is puffed, do not use it!

About the battery failsafe action, you can choose ether for land or return to launch. It is a matter of opinion but I would advise in the context of such a delivery mission to use the return to launch action; it is indeed better to permanently damage your batteries than having your expensive ship landing in the middle of a forested area.

IV.2 – Geofencing:

Do setup the maximum allowed range (i.e. the radius of a circle whose center is the arming location) and altitude in accordance to the delivery mission’s profile. Doing so, check the RTL altitude to make sure it is higher than any obstacle on the mission’s path so that your ship will not return to home through trees…

During test sessions, try a geofence breach to verify it is working as expected. Geofence parameters and breach actions are setup in mission planner / config-tuning tab / Geofence menu.

V – Ground control resources and initial checks before launching the auto mission:

According to the topology of the terrain, the mission length, it might be required to organize more than one ground control team. At least a ground control station must be installed at departure’s location (“Home”). Its job will be to setup, verify and control parameters, ensure the ship is flying correctly in GPS mode before launching the auto mission. It will also ensure the returning ship lands properly.

A second team is organized at target’s destination. This second team will be given means to take over an eventual required manual control of the ship in case of emergency. This manual control can be direct or indirect via the home point’s team.

In this delivery mission, the remote team (at destination) keeps permanent GSM voice contact with the control team @home. Furthermore a video downlink is organized in such a way that both teams keep permanent video monitoring from onboard camera(s).

The ground control team is also responsible to check that the environmental conditions allow for a safe UAV flight. The following site : www.uavforecast.com is an excellent resource for doing so. It provides, per location, information about:

-wind speeds at the altitudes the drone will be flying. For AirbotServices X8 model, a maximum wind speed of 40km/h is fine.

-Kp satellite indicator, giving an indication of the GPS signals quality. It should be under 3.

-Visible sats : higher the better. 8 is a strict minimum. With a M8N, such as the one used on AirbotServices’s X8 model, a fix with more > 12 sats is the norm. It provides an HDOP around 1 ! (2 is the maximum for HDOP for flying an auto mission)

-Temps

-Cloud cover & eventual rain. You should not fly under rain and heavy cloud cover as this may produce important GPS glitches (and eventual material damages on your electronics if not at least IP67 compliant or above).

VI - Pre-flight/initial flight checks considerations:

The RC transmitter is used to launch the mission, by first taking-off in stabilize mode. This is indeed the only way to verify and “feel” that the ship behaves as it should. If during the short stabilize mode checkup, an unusual behavior and/or parameter(s) are noticed, mission should be aborted until problem is identified and fixed. If the stabilize phase passes successfully, the pilot switch for a short moment to “PosHold” mode. The objective is to verify that the GPS and compasses are working fine. If PosHold is not behaving perfectly, abort the mission. And again identify and solve the issues before launching the auto mission.

If Poshold phase has passed successfully, then the pilot may switch the ship to Auto mode, where the delivery mission really begins with the first waypoint, etc.

VII – Mission execution and results:

As shown in the attached youtube video above in this post, the mission was very successful, especially in a surprising target drop location’s precision, under a meter. This might be due to simple luck but certainly partly due to the use of a high precision GPS based on a M8N Drotek model which has an extra-large shield of 8cm x 8cm which is totally compliant to Ublox’s M8 GPS chip ideal antenna configuration.

VIII - Lessons learned/improvements to consider:

• It has already been pleaded by me and others: a better altitude measurement solution than a single barometer chip on Pixhawk. We do not know what the answer could be but maybe using a LIDAR, maybe using some yet undeveloped technology. But something must be improved on that domain as it becomes a very limiting safety and reliability factor for professional uses.
• A fix to the DO-SET-SERVO command which did not work in our case and we wish for a functional evolution for this command to be able to set a duration of the produced PWM signal (similarly to DO_DIGICAM_CONTROL)
• The possibility in APM:Copter and Mission planner to program flight plans where land commands could be used in the middle of a mission; not only as the a final’s mission command
• A mission planner integrated AUX outputs test application able to simulate camera trigger configs, EPM configs and any other aux devices configs. At the moment testing is quite awkward and requires creativity to simulate effective behavior in flight.
• -…

There you have it, a package delivery auto mission !

Cheers,

Hugues