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

Hi,

If you ever wondered what professional drone designers/makers are doing behind the scenes, well we're not only building UAVs for customers but we also have to train them from A to Z (and often we have to train ourselves too:).

To show you how this is made, enjoy this little video of this morning's training session (for agronomy usage).

Cheers,

Hugues

Continuing on with our "week-end 3Dprinted goodies", today's menu is :

-A rover anti-vibration FPV camera mount, that also serves to hold the video transmitter.

-A Sony NEX5 camera mount for the XUAV Talon plane

Let's start with a Sony NEX5 camera mount to be installed in a XUAV Talon.

The mount is made to hold the camera on 4 anti-vibration balls, at a given height so the tip of the camera lens, when on,  does not touch the aircraft fuselage.

The print contains three parts : bottom, pillars, top.

Here some pictures of the real thing once printed:

And with the camera in it:

Rover FPV is a blast. However it is subject to vibrations like all of our other "Ardu" vehicles. Therefore the idea of a standard 25x25 mini FPV camera anti-vibration mount:

-It holds the camera with four rubber balls

-It has a vertical video transmitter holder:

The STL files are here:

-NEX5 mount for XUAV Talon:

NEX5XUAV.zip

-Rover FPV camera mount:

RoverFPVmount.zip

Enjoy,

Hugues

Hi,

Let us present AirbotServices' style Ardurovergasmistic week-end gaming - lvl 1. It is mandatory to pump the volume up when watching this video.

This all-terrain monster consists in a Pixhawk controller running latest Ardurover code installed in a 6 AWD chassis.

All six wheels are self-powered with an independent motor and are using a 75:1 gears ratio. Such a high ratio gives it a tremendous amount of power, as you may have observed in the video. Certainly not made for high speed rover sissies :)

In terms of equipment, in this first stage, AirbotServices ' rover remains practically naked, still equipped with:

-a M8N GPS+compass module

-3DR telemetry radio

-3DR power module to keep an eye on current and voltage in real time

-A Sabertooth dual motor driver (credits to our community Ardurover expert, Thomas, for helping me out on the settings !)

-FrSky D4R receiver

-Payload capacity (not counting chassis): 6kg

In a second stage, camera(s) setup with stabilized gimbal and vibration dampening. This will be quite an interesting challenge to get vibration free video on a rover and a level2 video might follow...

Ultimately such a little beast will be given a brain via a companion computer for "ground/underground" agricultural purposes. We were thinking on adding a small quadcopter companion, taking off/landing on top of it, using precision IR beacons of course, that would relay images to the rover companion computer. Or even swarms of micro quads launched by the rover ?

What do you think ?

Hi,

To make center of gravity (COG) 's tuning easier when attaching your battery on its ship, here is a quick and simple 3D printed sliding battery mount system.

Bottom plate is fixed to your plane (copter), battery is placed on the sliding tray. Sliding tray is moved right or left until COG is placed where you want it to be. Then everything is locked in place with velcro straps:

You wanna slide ? hereunder STL and Autodesk123D files,

• portebatterieTalon.123dx
• portebatterie.stl
• Dimensions of sliding tray :58mm x 150mm
• Dimensions all-in : 70mm x 150 mm x 15 mm (height)
• bottomtray.stl
• uppertray.stl

Enjoy,

Hugues

AirbotServices

1h:15min of flight time for Airbotservices'X4 equipped with brushless gimbal & fullHD camera on its 12mm carbon fiber payload rail system.

Attempts have been made reaching more or less 2 hours of flight time on "empty" frames: such crafts carry the absolute bare minimum required to minimize weight, meaning: they do not carry payload(s), and/or do not have extra electronics for autonomous/waypoint capability and/or do not carry optional bi-directional command & monitoring telemetry.

"X4" is an Airbotservices experiment UAV attempting to push the limits of flight autonomy of a "practical" drone : we tried thus something different with a fully equipped drone (BG & full HD camera), in addition having all APM/Arducopter capabilities. It carries the following hardware equipment:

• Airbot's payload rail system composed of two parallel 12 mm carbon fiber masts
• Airbot's 2-axis brushless gimbal (Airbot's world's lightest at 45g only) stabilized using an Alexmos controller
• full HD Mobius Camera
• 3DRobotics' Pixhawk (APM Arducopter)
• 3DR Robotics real-time telemetry (bi-directional TX/RX)
• GPS (M8N) and second external magnetometer (in addition to internal Pixhawk's magnetometer)
• 3DR power module powering Pixhawk and used for current and voltage measurements
• Airbot's LiIon 23100 mah 4S battery
• Power circuit/cabling for the BG

The frame base is built inspired by Forrest Frantz's "CF round tube" constructions techniques (for an extensive discussion and how-to guide on these innovative techniques, read post here). 

Some Observations , lessons learned and potential improvements:

• Weather status: 50% of time without wind, 50% with ~20km/h breezes

• Initial battery state : charged at 4.18V at beginning

• Brief Loiter (un)stability hickups. APM version 3.2.1 was used , loiter mode for 95% of the flight. The weather conditions were relatively calm but still with wind bursts once in a while. Even during "no wind" periods of time, "loiter" was having some unexplained, brief (10 seconds or so) strong twitches (or spasms) as if the quad was fighting very strong (but unexistent) winds. I repeated the same experience on Airbotservices X8, totally different craft, same observations. The three factors that impact loiter's performance (low vibrations, low compass interferences, good GPS performance) were all excellent on X4 & X8:
  • (Vibrations less than +-0,2g;
  • External Compass with very low offsets and far from EMI;
  • More than 8 satellites and HDOP<2). M8N on X4, 3DR LEA on X8 (no GPS HW suspicion)
  • EKF was enabled.

         P Loiter and rate P Loiter were tested with lower values (0,7 and 0,8 and 0,9)  than defaults (=1) with no sensible improvement on loiter's stability. 0,7 value resulted in a bigger unstability versus the default value.

           Any observations on what could be wrong, analyzing the log file posted below, are welcome....

• Pixhawk and/or APM Arducopter's altitude management : should be way better than what it is. I already posted a few times about this, like here, and other people have confirmed my observations. This 1h15 flight really shows how bad altitude management is, with measured altitudes (displayed in MP) that are two or three times higher than real altitude (after a few minutes). Altitutde drifts is a nasty problem for (long) auto missions and I hope developers will now be convinced this should be set in the high priorities in the list of change requests for future releases (further, according to a user who got some feedback from 3DR, it seems 3DR does not consider an altitude drift issue even exists; cf support forum link above). I know Randy has confirmed an altitude EKF improvement about this in 3.3 but I'll let him chime here as I might be wrong. There are two potential different drift sources (or both may also even be concomitant), and I do not know which ones are at play : either an hardware issue due to Pixhawk's electronics (baro chip and/or how it is electronically exploited); either a software issue (different sw were used in this test:  APM /w EKF , Mission planner). To finish, with a detail on altitude problems, APM documentation wiki needs a small correction as it states that altitude is calibrated to zero when plugging the battery when it fact, in version 3.2.1 anyway, it is calibrated (and reset to zero) when arming.

• Mechanical vibrations fatigue. As can be observed in the attached video of this blog, Mobius camera detached itself (pitch mount) due to mechanical vibration fatigue. Mobius cam was simply snapped on with a plastic cap. Similarly to loctite to maintain screws tight against vibrations, adhoc glue should have been used to secure the plastic cap "snap on" mechanism (careful, never to use loctite on plastic parts as it make it brittle).

• A very positive and conclusive result for "screwless" frames. Airbotservices X4 is built screwless, only using glue between parts, including the 12mm carbon fiber rail system that carries the heavy battery. Although this craft has been flown many hours (each time more than one hour at a time), none of the glued parts have budged nor cracked. Use of glue is key to get a light craft and get such performance (after all, Airbus and Boeing evolved too from rivets to glue in order to lighten their planes). I did not do any structural resistance measurements but I would bet that such frame is way stronger than any screws & bolts alternatives (Forrest might chime here as he 's the expert on the subject).

• Final battery status : voltage =3.3V per cell (plugged in, motors stopped) and =3.1V (under charge, motors running). A LiIon cell is fully empty at 2.5V per cell. Stopping at 3.1V, 20% of energy remained in the battery. It is OK to drain a LiIon battery down to 2.75V per cell under charge (=11V for a 4S battery). Extending the flight with a few more minutes was thus possible (better be careful not to damage the battery).

Mission planner's log file is downloadable here.

There you have it, a fun journey in extreme flight duration territory,

Cheers,

Hugues

Hi,

Inspired by Forrest Frantz with his multicopter building techniques using glue only, no screws (see here) , helped by him and Jon on frame and motor aspects of the build, we achieved and built what I believe is a world's record : the lightest 2-axis brushless gimbal carrying a full HD camera.

I will post and share building details in the next few days here.

Cheers,

Hugues

This is a continuation of my previous blog "how-to-write-set-a-pixhawk-parameter-using-the-mavlink-protocol"; where I fixed myself a little technical challenge to create an Excel sheet to set the failsafe parameters of my arducopters (Pixhawk fc).

As explained in the previous blog, on the Excel sheet I'd like to see a list of all of the failsafe parameters of my multirotor AND be able to change their values (by clicking on a write button on this Excel checklist). Indeed none of the available GCS software is practical to do just that : you have to click and navigate through dozens of screens to get to all of these parameters... Therefore I decided to try to build this in a typical DIY way.... It would also be a good Mavlink learning experience.

The first blog was an attempt, not being a developer at all (not even knowing what a python class meant) to understand how mavlink works and its various APIs/Libraries/Modules (Mavproxy, DronApi, PyMavlink, etc...).

This blog shows how the objective was reached succesfully (with a nerdgasm, I must admit).

The solution is an automated flow triggered by the big "Write to Pixhawk" button in the Excel sheet, after you have selected parameters's settings in drop down lists and set values in corresponding cells.

Better than words, a schematic below show what the processing flow does:

In order for this Excel application to work, there are three pre-requisites:

-Install win Python

-Install MavProvy

-Unzip MavExcel.zip  in the directory where you have installed win Python (example : in my case that is : G:\APM\WinPython-64bit-2.7.6.4)

The last thing to do, is to indicate in the Excel file, where are your win python install directories and on which com port your telemetry mavlink is connected. That's it !

Cheers,

Hugues

Hi,

I'm sharing with this community about my project's experiments which has for an objective to write (i.e. set = modify) a parameter (i.e. parameters we can see in the full parameters list in mission planner) using Mavlink.

You're now thinking : what a stupid objective, just use a GCS like mission planner to write your @#{{ parameter!

Well, no, I want to build an excel pre-flight checklist; within this checklist I'd like to see a list of all of the failsafe parameters of my multirotor AND be able to change their values (for example by clicking on a write button on this Excel checklist). Indeed none of the available GCS software is practical to do just that : you have to click and navigate through dozens of screens to get to all of these parameters I want in my checklist. Just unusable. Therefore I decided to try to build this in a typical DIY way.... It would also be a good Mavlink learning experience.

You may think: so what ? just use available libs or APIs and it's done. Yeah right, so I thought too naively in the beginning....

What I found is that Mavlink is the most complex contraption I have rarely met. Not only is  the standard awfully complex, but there is absolutely no material available on the web that would qualify seriously enough as "documentation" (developers tend to think that documentation consists in their comments within the source code, and that is only valid when they write comments in their source code...). The complexity of this standard comes from the fact their inventor(s) wanted something totally generic, for any kind of UAV and for any kind of parameters and any kind of control messages (it even cares for creating your own set of parameters/messages). Another reason for the complexity of Mavlink is the choice they made to partition the information in hundreds of different small compartments/files/scripts. So it makes it very very hard to get an bird's eye view on it and to understand what links what.

About documentation, the only data I found  (I did visit dozens of web pages and various  links about Mavproxy, about drone api, about Mavlink, about pymavlink, etc) were parcellar, very short pieces of information. Impossible to find a synthesized, clear overview of how to program concretely with Mavlink. Not even a single code example to show how to write a parameter via Mavlink from A to Z, not a single example ! However you will find tons of much more complex code examples such as fully functional GCS software. I did do a thorough information collection searching for similar topics on this forum and posting some help requests... without joy.

The least undocumented I found was Mavproxy, on a few web pages written by Tridge. However Mavproxy is a GCS software that is meant to be used with a human-machine prompt interface, on which you type in commands. You can't use it (or I did not find how, which prove how bad documentation is) for programming commands to be executed automatically (without a human typing something on the Mavproxy prompt). That is thus not usable for my project; however I decided to start from MavProxy to see if I could reverse engineer it, decrypt it  (I felt like Champollion and his Roseta stone) and reduce it to the bare minimum needed to just "set a parameter value" via Mavlink.

Not being a developer, not knowing even the python programming language (I had to look up wikipedia to know what a "class" means), I did what an engineer does best : a logical analysis on the Mavproxy source code and all of its dependencies (libs, modules) and lots of trials and errors. This allowed me to identify how the libraries and modules were linked to each other , via which classes and functions and variables to write a parameter to Pixhawk via Mavlink.  Disclaimer : it is probably very much incomplete or even incorrect but I reached my wished result.

The result is the scheme above which attempts to provide a synthesized overview of how the different python libs/modules/functions interact to simply write a parameter to Pixhawk via Mavlink. An immediate conclusion of this is how ridiculously complex Mavproxy & Mavlink are (the base from which I derived a modified MavHugues.py python program that does what I want). It even more so ridiculous when you think that all of this boils down to just writing a few bytes to a COM port ! (I'm afraid that some guy(s) in ETH Zurich university did make things complex to justify their PHD)

My practical test bench was a pixhawk connected via USB on a COM port of my windows laptop. I installed Win python, pymavlink, Mavproxy. For testing the thing, I chose to change the value of the CIRCLE_RADIUS parameter. AND IT WORKED ! Alleluia. (<= this is a joy manifestation of succeeding doing something stupidly simple starting from an insanely complex contraption, i.e. Mavlink/Mavproxy).

I provide my modified Mavproxy.py python script (MavHugues.py) in annex for those who want to join me in the simplification fight for programming Mavlink !

Please, developers, be kind in your eventual reactions...I'm certainly a very bad developer but you're as bad documenters;)

Hope this will also help eventual other DIY'ers playing with Mavlink.

Cheers,

Hugues

File attached : mavhugues.py

Within AirbotServices.com, all of our professionally built drones integrate a live telemetry link, outside of the main transmitter frequency band. We consider it to be a critical safety element that should be enforced in future European regulations for commercial drone activities. It is a must have. Why, you may ask ?

The current relative lack of reliability inherent to complex electronics and software modules composing a drone (although it may integrate redundancy) will sooner or later inevitably translates in "gremlins" during flight (a priori unexplained bugs) and/or eventually flyaways (uncontrolled drones).

Telemetry provides multiple safety functions:

-A safety functionality by monitoring real time critical elements that should be taken into account by the pilot (battery level typically)

-A safety functionality by sending real-time positionning (GPS) data on the ground station which can be used to find your drone that flew away;

-A debugging functionality by providing real-time to the ground the values of internal parameters (and therefore helps finding out why there is an uncontrollable behaviour);

-A logging functionality (Tlogs);

-An out-of-band communication outside the Radio transmitter band (it the 2.4ghz fails, the telemetry link might save you); not only to receive flight parameters on the ground but also to send  commands.

433Mhz is the frequency of choice for telemetry as it provides the best range & penetration capacity through objects and walls versus higher frequencies (i.e. 900 Mhz or higher).

In Europe the maximum power allowed for using 433Mhz band, for other uses than amateur radio (for which an amateur radio license allows you to use hundreds or thousands of watts), is 10 milliwatts. This band is used for house alarm systems, remote controlled devices, etc.

Such a small power allowance makes it critical to optimize antenna designs on our drones, to maximize the range.

On the test bench : 4 different 433Mhz antenna models:

We will compare hereunder various 433Mhz antenna models, some are commercial stock models, others are DIY models based on best practices, among which excellent build advices provided on this diydrones blog:

http://diydrones.com/profiles/blogs/dipole-style-antenna-for-433mhz?id=705844%3ABlogPost%3A1674324

• 3DRobotics model:

The standard 3DR duck telemetry antenna such as shown here

is a 2Db compact sleeved dipole. It is sold with the 3DR telemetry kit.

• Nagoya 144/433 Mhz model :

Nagoya is famous for building excellent antennas. This is their telescope antenna, model NA-773.

• AirbotServices' sleeved dipole model:

This is a 433Mhz model built by AirbotServices, designed by Joe ("Nampilot") as described in the blog link above,

It is made of 100% copper. Contrarily to simple dipoles where the two active elements have the same length and are fed in the middle (wich requires a balun to balance it to 50 ohms), this dipole consists of a longer top copper wire and a shorter copper tube which acts as a balun at the same time. The resulting antenna is not only perfectly tuned for 433Mhz, it is also 50ohms balanced without an additional balun.

A RG316 cable feeds this antenna.

• AirbotServices simple (standard dipole) model:

This is the classical dipole with servo wire and a RG316 feeding coax. We added a ferrite choke as a balun. The center is reinforced with balsa to maintain 90 degree angle between the active elements and the feeding coax.

Test method and results:

We use the RF explorer spectrum analyser as our test equipment. Rather than using its small integrated LCD screen, we used the windows PC client software, connected by USB to the RF explorer.

The test signal was picked purely and simply in the ambiant "433Mhz band" signals. At the moment of the test, a particular peak signal was found at about 424-426Mhz. It is not an issue to measure aside the pure 433Mhz frequency as the telemetry device uses frequency hopping between 414Mhz and 454 Mhz.

So each tested antenna were screwed one after the other on RF explorer and we waited for a stabilization period. After which the signal DB levels were measured as follows:

The 3DR duck style Model:

The 3DR duck style antenna measures a -78Db signal level.

The Nagoya antenna model:

The Nagoya antenna measures a -69Db signal level.

The AirbotServices sleeved dipole model:

The AirbotServices sleeved dipole model measures a -69.5 Db signal level.

The AirbotServices standard dipole model:

The AirbotServices standard dipole model measures a -73.5 Db signal level.

Conclusions:

-The base 3DR duck model provides the least performance as we could expect, fixing an arbitrary base a reference level of -78Db

-Both the Nagoya and AirbotServices sleeved dipole provide the best performance, improving the measured signal by 9Db relatively to the base 3DR model.

-The standard dipole model lays in between with -73.5Db, which  is still 5Db better than the 3DR model. It was also noticed during the measurements that this dipole is quite sensitive to polarization : a difference of 5Db could be measured by rotating the polarization. This sensitivity was not noticed that much with AirbotServices sleeved dipole.

There you have it, our quick telemetry 433Mhz antennas test bench.

Cheers,

Hugues

To optimize videophotography results, vibrations need to be reduced as much as possible. The objective is to disturb as little as possible a brushless gimbal holding a camera. (we all know too well how hard it is to get a brushless gimbal well tuned).

As most people, brushless gimbal tuning is done on the bench using accelerometers & gyros of the brushless gimbal's IMU. And like most, we do not get as good results when flying. Why?: frame & air vibrations. Frame vibrations are created by motors, props and wind. Direct air vibrations (external wind) also impact the brushless gimbal.

This is a blog post showing anti-vibrations objective measurements of different isolation systems, obtained on my Mr. Grey X8 workhorse shown on the introductory picture. All vibrations measurements are made during periods of min 30 sec of hover in stabilize mode. Take-off and landing periods are excluded of measurements.

Configuration of the test craft:

-Pixhawk controlled -Stabilize mode

-T-Motors MT3515-400Kv

-15x5 XOAR props

-6S batteries

-2 axis brushless gimbal - Alexmos

-Sony NEX5 camera

-Weight of the gimbal+camera+fpv+3S 1ah battery : about 1250 g

-AUW : about 6.8Kg

Vibrations measurement setup:

-All tests were made with the craft configured fully ready-to-film : except the gimbal which remained off not to measure its own generated vibrations. The camera was thus simply screwed on the gimbal with no power to the brushless motors.

-X-Cam vibration measurement tester

X-Cam is installed on the different areas of the craft to be tested. Its mesaurements are triggered remotely by a PWM pulse (on/off switch allocated on Taranis). It is powered directly through the PWM servo cable connected on the receiver.

Data are stored on board its flash memory. It is made for vibrations measurements in the 0-200Hz range and can store up to 3 min of continuous measurements.

Through the X-Cam GUI , data is downloaded from the flash memory to produce a time graph (basically useless as it shows the X-Y-Z vibrations measurements along the time axis), and a frequency graph showing X,Y,Z vibrations amplitudes (in number of g) versus frequency (in Hz). Raw data or weighted averaged data can be calculated.

Two anti-vibration systems were measured,

First a silicon ring system as shown below,

Four of these were used in a X configuration between Mr Grey's two plates (see introductory picture). Each plate is made of plywood; square shaped with 20 cm long sides.

Silicon rings come in two stiffnesses: red for softter silicon, black for stiffer silicon. Here, only the red softer ones were tested. Each Secraft system costs about 9 euros each (www.secraft.net) , which is relatively cheap.

Second tested system is a "Bell" shaped  precompressed silicon system. Each "Bell" is made for a 250g payload. Each one of them costs about 39 euros (www.altigator.com) which is quite expensive. It is mostly used in high end professional aerial photography rigs :

Four of those were used, in each corner in between Mr Grey's test plates as shown below:

Reference measurement:

In order to compare results, a reference measurement is made on the frame itself, with the X-Cam placed at the center of Mr Grey's top plate, under its protective "flower pot".

Frequency domain picture shows two frequencies were vibrations are significant : 85Hz and 175Hz; The measurements show about 0,3g of vibrations on all three axis at 85Hz; and 0,4-0,5 g vibrations at 175Hz.

First test result with Silicon rings system:

X-Cam is now placed on the second bottom plywood plate on which the gimbal is fixed,

The results show that frame vibrations are continuing to pass through to the gimbal at the same frequencies (85Hz and 175 Hz) but amplitudes are divided by a factor of 10 at 85 Hz and almost by a factor of 20 at 175Hz, versus non damped frame vibrations.

Second test with the "Bell" system:

X-Cam is placed at the exact same location as for the first test,

The results show that frame vibrations are continuing to pass through to the gimbal at the same frequencies (85Hz and 175 Hz) but amplitudes are divided by a factor of 2 at 85 Hz and by a factor of about 2 at 175Hz, versus non damped frame vibrations.

If we show the silicon ring's system on a graph at the same scale as Bell's system:

The silicon ring anti-vibes system literally erase vibrations in comparison with the "Bell" anti-vibe system....

Comparison of both anti-vibrations systems:

It appears clearly that the "silicon ring system" is much more efficient at reducing vibrations versus the "Bell" system. Further, this silicon ring system is much cheaper than the Bell system.

For once, more expensive, supposedly professionnal parts were not up to the task verus cheaper diy parts.

Cheers,

Hugues

AirbotServices fixed wing is based on the well known XUAV Talon EPO frame. This plane has a standard wingspan of 1720mm . Although its wings are quite wide (total wing surface is 60 dm2 - much wider than most other EPP/EPO frame), when fully loaded with cameras and large batteries, the plane's all-up-weight can reach more than 3 Kg.

As a result, in this standard wingspan configuration, the Talon requires to maintain a quite high airspeed not to stall, and also to use long and large landing spaces.

Therefore we wanted to test and try the optional (should be mandatory) wing extensions. These extensions increase the wingpsan to 2 meters.

Configuration:

-Pixhawk with APM:plane version 3, geofencing enabled (this is a great feature by the way!). See picture showing the geofence and one rally point in the field:

-T-Motor 3510-700Kv, 13x8 Graupner prop (that gives a 1Kg of thrust at 50% throttle which represents at least 30% of the total weight of the plane, as recommended by the specifications)

-Mobius camera in front dome (no gimbal - hard fixed, therefore some jello in the video)

As a result of these wing extensions, we were amazed how slowly we could fly (less than 20km/h without even stalling), maintaining a relatively good maneuverability. But we were even more suprised on how easy it was to land, on very short distances.

We have discovered and played succesfully with a "discovered by chance" landing method, batpized "cork screw" landing, which consists in slowly descending the plane in a spiral (very low throttle) to the ground which provides a way to land in a small surface area (for example if you do not have a runway at your disposal). Contrarily to what you could think, this method, using the wing extensions, is not reserved for experienced pilots; I am myself an utlra noob Arduplane pilot (actually my first flight...).

Has anyone else played with APM/Pixhawk alternative landing methods (like triggering a chute, for example ?) 

Cheers,

Hugues

How-to launch an arduplane (XUAV Talon) ?

Introduction:

A XUAV Talon is a relatively heavy airframe (between 2,5 and 3Kg depending on its configuration) to launch. Other EPP/EPO FPV large airframes come in the same weight category. So, how to launch/take-off with such large/heavy UAV planes ?

There are three ways, that I know of, to take-off :

• Hand launching,

 -requires two people : one keeping both hands on his Tx control sticks; the other one throwing the plane in the air.  A two man operation is not always convenient nor possible on the field.

-it is dangerous : the propeller might shred the launcher's hand...

-launch is not systematically succesful as the plane is not systematically thrown correctly (angles, strength)

• Roling the plane on a runway up to take-off speed, 

-requires a runway, long enough & flat. Not really like that in real fields.

-requires wheels on the front, back (or wings) and a steering system : not available on all planes such as the XUAV Talon.

• A catapult launch system

-requires a cheap, reliable, transportable system

-requires enough catapult launch force to handle +3kg planes

The catapult build published hereunder attempts to be a synthesis of lots of ideas and information found on diydrones, rcgroups forum & rc experts youtube videos.

This catapult system is a built intended and tested to launch a XUAV Talon, i.e. a large 2 m wingspan FPV plane (wing extensions) in the 3kg weight category.

This guide first describes the parts and assembly steps; then a result video of (succesful) field tests is shown at the end.

Catapult's parts list & Assembly steps:

The list of parts is shown herebelow:

Cables/ropes setup:

Two types of ropes are required. An elastic rope (a sandow) will provide the force to catapult the plane. A second non elastic nylon rope (or any other strong enough rope) will pull the plane (via a hook fixed on the plane, see further) and will be used to trigger the elastic sandow.

The sandow is shown herebelow:

On one side of the 10 m sandow is a loop that will be fixed on the ground by a (very strong) tent hook. On the other end, the sandow attaches to the nylon rope.

The nylon rope part is shown below:

On one end the nylon rope is attached to the sandow as shown below:

On the other end the nylon rope ends with a loop that will be fixed on the ground with a (very strong) tent hook. This last extremity will be released to trigger the elastic (see further).

At about 3 meters from the sandow-nylon rope junction, a Y is formed : a one meter nylon rope piece and a piece of about 5 meters. The one meter piece ends with a loop that will be attached on the plane's hook. This is the piece that will pull the plane out of the catapult. The other (5m long) piece will act as the trigger (when released from its ground retaining tent hook).

Catapult structure setup:

The catapult body is assembled with PVC tubing. These PVC tubes must be large enough to support the weight of the plane; therefore a suggested minimum diameter of 35 mm.

The longest tube part is about 150 cm; therefore three 2 meters long tubes are enough for the build.

The tubes are glued together, as show on pictures below. Two types of PVC junctions are used : T's and 90 degree angle,

The length of the front and back "legs" of the catapult are chosen so that the launch angle is not too steep and smaller than 45 degrees. The resulting angle with these given dimensions is about 30 degrees max.

The plane, when pulled by the rope, will glide on the two top PVC tubes. The plane wings would get ripped if gliding on the two 90 degree PVC connectors; they must therefore be trimmed, as shown below:

To adjust easily the width of the two left/right catapult rails, a metal bar (of smaller diameter than the inner PVC tube diameter) is inserted horizontally inside/between the two front legs,

XUAV plane setup on the catapult launch system:

The plane left and right wings sit on top of the catapult PVC left/right PVC rails:

The sandow and rope are fixed like this:

This is where the fishing hand scale is used : the sandow must be streched to provide an elastic force of about 5 times the plane's weight. So for a 3kg XUAV Talon, the sandow must be streched to provide 15Kg of force.

To measure this, the sandow extremity is first fixed to a point in the ground with a tent's hook. The other end of the nylon rope assembly is attached to the scale hook; then pulled until 5x the weight is read on the scale. This gives the position where the nylon rope will be released to trigger the sandow (cf video below for a visualization of this explanation).

The 1m nylon rope section (forming a Y junction), attaches to the plane, on the plane's bottom hook. This one meter section must also be kept in a streched state when launching.

The plane's hook must be strongly secured so as not to be ripped off when releasing the sandow brutal force. This cannot be fixed on foam only; it needs plywood or aluminium reinforcements. On the XUAV Talon, the optional plywood landing gear base is used to securely fix an aluminium hook:

The hook must be placed slightly in front of the CG line of the plane. On the XUAV Talon, the CG line is located at about the servo wires position on the wings (see picture).

If the hook is not located right, the plane will not be pulled right and will eventually flip to the sides or upside down.

The results in video

Cheers,

Hugues

Description of the problem to solve:

When a high enough current switching (transition to/from an on/off state) occurs in an electrical circuit, an electrical arc will form between the two switching contact surfaces, in order to oppose (resist to) this circuit change in current. 

The more inductance and/or capacitance in the circuit, the bigger the electric spark will be. Capacitors can be viewed as current storage devices (with a full or empty status, like water reservoirs) : when connecting a battery on an emtpy capacitor (e.g. an ESC), the maximum amperage the battery can deliver will flow into the circuit in a very short time to fill the capacitors (until the capacitors are full), producing a spark in the meantime.

This phenomenon is thus more severe when there is more total capacitance in the circuit. This is an issue with multicopters that have lots of capacitors in their power circuit : minimum 4 ESCs (for quads) and up to 8 ESCs (for octocopters), each ESC having multiple big capacitors.

The phenomenon is also more severe when the battery has a higher voltage (4S-> 5S-> 6S), simply because a higher voltage makes it easier to ionise a thin layer of air between the two switching contacts, as required to produce a spark.

Why should we avoid sparks ? to avoid damage to UAV's battery connectors (gold plated contact areas are damaged by repeated sparks, the plastic of the connectors will be burned, etc). Some sensitive electrical circuits do not like short bursts of high currents. For example, from experience, an attopilot (voltage and current sensor) circuit has been damaged by repeated sparks using a 6S battery....

Solution to the problem:

The solution is theoritically simple : capacitors have to be charged slowly (e.g. with a small current) before connecting the full amperage power of a battery to the ESCs circuits.

Many previous blog posts on diydrones & rcgroups have mentioned various solutions. The one described below synthesizes how to use an interesting circuit : a BTS555 integrated circuit,

As described in its datasheet, its applications are:

The two last bullet points, in particular, are the ones that interest us the most.

This BTS555 IC summary is given in the following datasheet extract:

We see from this datasheet table that a BTS555 will support a current load of 165 amps ! This is more than enough for a large multicopter. It operates up to 34V which is fine for up to 8S batteries.

From the datasheet we get the following pinout description:

In our application, only Pins 1, 2 and 5 will be used.

Pin 3 will not be used as it is replaced by the IC tab (for high current uses).

Pin 4 will not be used as we do not need to measure the current in our application (rather, a 3DR power module or an Attopilot would be used for that purpose)

How does this work ?

This BTS555 IC is connected between the battery leads and the power distribution board's leads. A small mechanical switch (for example a sliding switch. This switch interrupts a very small current, so no spark issue there) must be used to activate ON or OFF this circuit.

Here is the step by step process to power your multicopter using this circuit (assuming everything has been wired up as described below):

-Connect the BTS555 circuit to the power input leads of your power distibution board

-Ensure the activation switch is on its OFF position

-Connect the battery leads to the BTS555 circuit

-Activate the BTS555 circuit by flipping its switch to the ON position. Your mutlicopter receives now full power from the battery and the spark is avoided.

-If you use a double battery power feed on your drone, follow this same procedure when connecting a first battery. Then connect simply the second battery (no spark will be produced because all capacitors were loaded when the first battery was connected). You can then, optionally, remove the BTS555 circuit from the drone (to remove weight and to not depend on its reliability during flight. Simpler is better and more reliable)

How to wire everything up ?

As reliability is critical in flying multicopters, therefore to not depend on only one BTS555 circuit, the wiring scheme below uses two parallel BTS555 ICs...

The input and outputs of the overall circuit are XT90 connectors (safer than XT60 connectors for bigger multicopters). The elements (ICs, connectors) are soldered on a piece of PCB protoboard. XT90 connectors are soldered directly on each side of this PCB (more compact, no extra wires).

The wiring scheme is the following (for clarity, one side of the protoboard is used as a shared ground plane; the other side is the positive side divided in two zones: the top side where the IC tabs are soldered together and to the battery +Vin. Then the bottom side where pins 1,2 and 5 are soledred together and to the positive PDB output connector, but not to the TAB zone !) :

Concrete realisation :

This circuit has been tested succesfully on octocopters (8 ESCs) , 6S batteries with APM, Pixhawk, Attopilot module.

Cheers,

Hugues

Hi,

Integrating troubleshooting results from quite a few people describing power problems with Pixhawk or Pixhawk getting out of control (linked to ESCs' signal wires connected without a ground reference) I thought the current wiki information should be completed/updated with a synthesized diagram that says it all clearly and explicitly.

This diagram represents optional components that you may have or not but the wiring logic remain the same.

The basic fact to know to start with is that the power port ground is NOT (connected to) the ground of the main output ports on the Pixhawk board, contrarily to what we were used to on the APM board (where the ground was the same on all ports, inputs or outputs).

Acronyms on the diagram: PDB on the diagram means Power Distribution Board. PM block means the power port of Pixhawk. PM/Atto means an optional power module from 3DR or the Attopilot alternative for higher than 4S battery voltages.

Any comments to add eventual useful tips that would be missing are welcome. I'm not the best at drawing stuff, so if Jethro (known for his excellent illustrations) or some other guy here on the forum has graphic design talents, this diagram could be made more sexy.

Hope this will help some folks to do a safe wiring.

cheers,

Hugues

Hi,

After my Talon build part 1 & 2 (here), you'll find herefater my first experiments with the installation of Pixhawk and other components in a fixed wing UAV. What's great with this Xuav Talon model is its huge internal bay. So I started to draw on paper the location of all of the components of my setup, as shown in top picture.

I imposed to myself some rules/principles:

-to keep different antennas and receiver as far apart as possible.

-not to use of the wings to install any components. This is a compromise to keep transport/assembly/unassembly easy (wings can be removed with two screws).

-contrarily to certain builds, keep the gps with a clear sky view (eventhough it would probably still work buried in foam)

-have backup power on pixhawk: 3DR power module + SBEC on RC rail (+ required to power servos)

-to plan wiring before installing components; to draw a wiring scheme as shown above. This to avoid bad/wrong connections and ground loops. On the latter principle, Pixhawk has a weak point : if you power , as a backup, via a SBEC the output rail, not only do you have to mess with the installation of a 5.6V zener diode to protect the board, but you are forced to connect the ground wire too (creating a ground loop with the ground coming from the power module). This should be adressed in a next card's version : integrate the zener diode in the PCB and make it right like APM was: a common shared ground for all circuits of the FC.

Let's see what was done,

1. Customized electronics platform to host Pixhawk:

I don't know what these foamy airplane manufacturers think about when they design their model : they always forget to plan for a leveled horizontal surface, inside the bay, to host the flight controller board (maybe they are old school and never use a FC ?).

As a consequence comes a first question: where to place the pixhawk board so that it is firmly held in place (with room to use an anti-vibe platfrom underneath) , at the center of gravity and perfectly horizontal when the plane is horizontal ?

My answer is to add a diy custom plywood plate held horizontally in between the two existing plywood pieces that are used to reinforce the wing attachment points on the fuselage:

Side view of the added black painted plate:

As can be seen on this last picture, Pixhawk sits on the custom platform. It leaves a big gap underneath which is useful to pass cables and/or position other components on the bottom below the platform. It gives also the advantage to move pixhawk far away enough from possible electromagnetic interferences of cables/electronic components that would be positionned underneath, on the bottom of the bay.

2. RC receiver and antenna's positionning:

I decided to start with a FrSky 2.4Ghz rc control (a long range opensource Hawkeye DTF UHF alternative is ready and tested but will wait for now).

I use a X8R FrSky receiver with the PCB antennas. It is supposed to give a 20% range increase versus the simple coax wire antenna's. To be efficient they have to be placed perpendicular to each other (to cover horizontal and vertical polarisation. Especially useful when the plane banks, in order to not loose the signal).

Question : where to place the receiver, pcb antennas and how to have them perpendicular ?

Answer : eat a popsicle; then insert and glue the popsicle stick in the fuselage on the back of the bay. This location is far away from the motor/ESC, far from the telemetry antenna and FPV antenna. One pcb antenna is then velcro'ed vertically on it.

Using a solder iron, I melted a hole through the fuselage to pass the antenna wires. The receiver is velcro'ed on the side of the fuselage as seen on picture.

The second antenna is place perpendicular to the first one on the fuselage body.

3. 3DR GPS and compass module installation:

I wanted an external GPS installation. I did not want it on the wing, nor drill a hole in the top foam cover.

Furthermore it needed to be close enough to Pixhawk because of these damned DF13 cables that are delivered way too short in the 3DR kit... (=> request for 3DR, in your next FC version, replace these cables by longer ones and use connectors that DIYers can modify easily)

The GPS + compass module is installed on the back of the bay where the air inlet (cooling the motor) is located. It provides a small horizontal surface that is perfect for the GPS to sit on. However a "cable pass-through" hole has to be melted through the foam, to reach to Pixhawk (again a fined tip solder iron makes the job).

4. Telemetry module installation

Current 3DR telemetry modules are delivered in a plastic casing that makes it easy to velcro to a supporting surface.

I decided to locate the module in the front of the bay where this telemetry casing fits perfectly on the internal side of the fuselage.

An iron solder was again needed to melt an antenna hole.

5. Airspeed sensor (Pitot tube) installation:

The airspeed sensor consists in a pitot tube that ideally should be installed on the front (nose) of the plane. However that will be reserved for the installation of the FPV equipment. Also, the sensor's silicon tubes and I2C wires are too short to go all the way from the nose to pixhawk.

So i chose an alternative installation on the side of the fuselage,

I found an easy way to attach the pitot tube to the fuselage so it is maintained fixed and horizontally about 1,5 inch away from the fuselage. A zip tie is used around the metallic tube. The "plastic tail" of the zip tie is glued with CA on a CF rod. Hot glue is used to reinforce and fix the rod perpendicular to the tube.

The cf rod is pushed through the foam on the side and hot glue on both sides seal the rod firmly.

When travelling, the metallic tube of the sensor can be slided out of the zip tie.

6. Side note on servo control horn and control rod installation:

It is said by xuav talon experts on rcgroups forum that the maximum deflection of control surfaces should not exceed 20 degrees. Indeed only very small surface movements are required to fly the Talon (and people tend to move their sticks too much).

So I decided to mechanically limit the surface's deflections by positionning the control rod attachment point outward on the control horn. That way surface's movements are limited to about 20 degrees.

The consequence of this is I do not get perfect 90 degrees angles between horns and the control rod. I hope this will not create more adverse effects than not limiting the amplitude of the surface's deflection...

This ends part 3 of the XUAV Talon build.

Soon to follow : FPV components installation.

Cheers,

Hugues

I found this article which is quite a demonstration by the absurd of how when a technology (micro UAVs in this case) is beneficial to the industrial-military industry, it will get through any FAA or any other regulations. Another sign we're really under large corporations' governance.

So, in other words : develop a potentially very dangerous (privacy, invasive, weaponized, etc) application of UAV tech, and you will get a green light to do whatever you want with it even in the middle of the US; However you'd like to fly your harmless quad that carries a gopro  : that's a no no - you can't fly it - forbidden - bad bad bad - too dangerous.

This would laughable if it wasn't so absurd: try to make citizens believe your IRIS or AR drone is dangerous for the sake of privacy protection (and all other arguments we hear from FAA against UAVs civilian uses), but then it's ok to spy on your citizens - everyone being a potential terrorist - do not forget that,  (and on other countries of course, preferably US allies).

Hereunder the text accompanying this YouTube video: (I do not support necessarily views & opinions expressed in this relayed text. Everyone is free to think for himself and should think for himself with a critical mind!)

Air Force Bugbots Nano Drone video gives a peak inside what nano-drone technology the Federal Government is currently implementing within the united states more than a scary thought or sci-fi movie, they have arrived.

The deadly, insect-sized drones of the future - Unobtrusive, Invasive, and Lethal are here as depicted in this old video

The Air Force is reportedly developing winged drones that can sneak up on a suspected enemy as stealthily as a mosquito

This is the video missing from this article:
http://theweek.com/article/index/2402...

A law signed by President Barack Obama in February 2012 directs the Federal Aviation Administration (FAA) to throw American airspace wide open to drones by September 30, 2015.

Nano sized Drones Combined With DNA Hacking Could Create A Very Scary Future for the United States in light of a law president Obama signed last year implementing a fleet of at least 30,000 spy drones to spy on small town USA no later than 2015 to spy on Americans.

Unfortunately this is a true story and as long as we continue to let politicians like President Barack Obama and other democrats pick apart and fundamentally change our constitution instead of protecting it, we move closer to an extreme communist state in our country.

In case you didn't know it - and you probably didn't - Congress, with little fanfare, passed an FAA re-authorization bill that President Obama signed into law that will put 30,000 flying drones spying on Americans across U.S. cities by government.

People are already nervous about the prospect of being watched by law enforcement (and possibly the military or DHS), but our leaders employ these tools nevertheless and "we the people" are letting them.

Even the liberal news huffington post has a video news story about this although they try to legitimize the reasons for needing this to save lives.
http://www.huffingtonpost.com/2012/09...

The president has ordered 30,000 spy drones to be used within the United States to spy on Americans to be implemented by 2015
We are already seeing evidence of spy drones being used within the United States and NOT for border patrol

Government Spy Drone Crashes in Maryland but what about preserving our constitutional rights and freedoms?
http://baltimore.cbslocal.com/2012/06...

MORE SOURCES AND RELATED STORIES:
The Future of Drone Surveillance: Swarms of Cyborg Insect Drones -
http://www.networkworld.com/community...

Tiny robot mosquito drones being researched by the US government -
http://2tfu.com/2012/06/16/tiny-robot...

National Geographic Story:
http://ngm.nationalgeographic.com/201...

Government Working On Mosquito-Sized Drones - http://www.ijreview.com/2012/06/8545-...

Micro-Drones Combined With DNA Hacking Could Create A Very Scary Future - Business Insider - http://www.businessinsider.com/govern...

USA Today Story: http://usatoday30.usatoday.com/news/w...

Studying butterfly flight to help build bug-size flying robots -
http://phys.org/news/2012-02-butterfl...

US military developing insect surveillance drones - http://www.presstv.ir/detail/2012/07/...

Video of squadron of nano quad rotor aerial drones -
https://www.youtube.com/watch?v=YQIMGV...
http://www.huffingtonpost.com/2012/02...
http://www.theblaze.com/stories/2012/...

British Army Using Tiny Drones:
https://www.youtube.com/watch?v=d5TdbM...

Drones In U.S.: More Unmanned Aircraft Will Be Flying In Domestic Airspace By 2015 (VIDEO) - http://www.huffingtonpost.com/2012/09...

Washington Times Story over Domesticly Used Drones: http://www.washingtontimes.com/news/2...

Snopes reports nano drones true but then brushes it off - http://www.snopes.com/photos/technolo...

UPDATE 1 of the build below

Hello,

I wanted to share my first Talon build (and my first fixed wing):

(also posted on rcgroups here:http://www.rcgroups.com/forums/showthread.php?t=1977612&page=75)

Once it will be built (might still take a while), I intend to use Pixhawk as I am now deep into it my multicopter side of the force.

 it will be useful to get comments and maybe help others building their own fixed wing. This build thread will consists of more than one posts but these posts will come in sequence when there is progress to show in the build process (especially when some parts are still being ordered and being shipped).

Here we go for this first post,

I ordered the Talon kit , in white, @ www.fpvmodel.com. Unfortunately I saw two weeks later the extension kit for the wings + landing gear + new dome which is oriented toward the ground. So I ordered this extension kit which is still currently blocked at customs...

I have never previously built a fixed wing UAV, this is my first. So bare with me.

First question I wondered was by which step to start : can I glue parts in any order ? Do I risk to be blocked later by assembling the fuselage before organising the electronics and cables inside ?, etc

As there is no step by step guide out there I decided based on intuitive logic in which order to proceed.

I first followed the mounting PDF guide that is the generic mounting guide coming with the XUAV Talon. I followed the guide up to the "gluing the wood pieces" stage. I then left the two halfs of the fuse unglued at this stage.
For gluing I decided to use UHU POR. It is said that CA is too rigid and breaks apart, that hot glue when too hot melt the foam, that the EPO material of the Talon has built-in an unmolding substance that makes it hard to adhere to.
 

When I received the fpvmodel box, it had been slightly crushed and had one of the two EPO dome pieces broken.
I managed to repair the dome piece and glue everything together nicely with UHU POR

The next step that was clear to me was to understand, before gluing anything definitively, how to mount servos, control rods, control horns.

How to mount servos, control rods and control horns ?

This is the most difficult part as I had read in this thread, even from senior builders like chanyote and blueprint, that they had lost control horns in flight (bad fixing)!

I tried manually to move a servo , just holding by the fingers a control horn : indeed there is a huge force playing on them, especially at the end positions of the servo: it was immediately obvious that just gluing a control horm would not work (I would not trust it in flight).

My approach to this issue : reinforcements of the control horn fixing on the moving surface,

To do so I gathered some fiber glass fabric that I had left from my multicopters builds, Titebond wood glue (the very best of wood glues) and a paintbrush 


The idea is to apply on both sides of the control surfaces, around the spot where the control horm has to be fixed, a piece of fiber glass fabric glued with wood glue (applied with paintbrush to smooth and even the surface). This results in a quite hard composite that adheres extremely well to EPO foam.

It remains also very smooth, flat and thin (would not have been the case with UHU POR for ex). As a result, the two sides of the control surfaces, that will receive the control horns, are armed with fiber glass. Not only armed EPO offers more resistance to ripping forces, it also reinforces the foam against the squeazing pressure of the screwed control horns.

I decided to use Titebond wood glue versus foam CA because of a small test I did before : I coated a test piece of fiberglass with foam CA ->apparently CA destroys the fiber glass resistance somehow and the pieces could easily be broken apart. Then I coated another test piece with of fiber glass with wood glue->excellent mechanical property and more rigidity.

I do not have the screwed type control horms yet, they are being delivered. I expect them next week.

Another reinforcement decision was about the control rods. I had also read on this thread that the rods that came with the kit are flexing too much. So what I did was to double the main wing rods (the longer ones; the rods of the V tail are short enough to be left alone as they came in the kit). I cut in piano wire the same length of wire. I then used heat shrink tube pieces to fix the two rods together, as show in picture 8. 


Then came the question of the servos :

What servos to use ?

I had read in this thread that the servos for the ailerons need to be stronger than the servos for the v-tail. There is a mention somewhere that the V tail servos should be 9g and the servos for the ailerons should be 17g.
I got mistaken from a kit on fpvmodel that provides four 12g servos for the XUAV Talon. So I got 4 of them, model EMAX ES08MD (digital, metal gear, 1.6/2.0 Kg.cm).
Unfortunately when I tried them on the plane, they only are a good fit for the V tail, and they are way too small for the ailerons.
So I got 2 Hitec HS-82MG (Digital, metal gear, 19g, 2.8/3.4 Kg.cm) for the ailerons.

One of the hardest thing for a beginner like me in fixed wings, is how to mount the servo arm, in which position, etc.
After a bit of reading, I had to place the servo in neutral position and than mount it with the servo horn perpendicular to the control rod when the control surface is in neutral position too. It seems easy to sayd (read), but it is much harder to implement.
Especially I am still waiting for the transmitter/receiver (a Hawkeye DTF UHF 433Mhz) that will be used, so I had no way to define the neutral position. I got thus a servo tester for this. It is very cheap and practical; it allowed me to test all servos before installation. To test not only that servo worked ok, but also to test the extreme positions of the control surfaces.


 I still have an issue with the movements of the surfaces because they move too much : I have +- 45 degrees. According to what I read in this thread, I should limit the movement to +-20 degrees.
How can I achieve that movement reduction mechanically ? (or is it ok to use servo limits in the transmitter without loosing servo resolution ?)



That's where I am at for the moment. If there is some interest I will continue posting progress on this build.

UPDATE1:

Finalized servo and servo horns on the control surfaces

I have finally found some time to finalize the servo and servo horns attachments on the surfaces. I found this step to be the most difficult of the build so far as the stock control horns are too weak and are not of the screw type (so in practice this would mean a high risk to loose a control horn during flight if it is just glued...not good).

What has been done:

-the default control horns were replaced by screw types control horns

-but in order to fix screws on foam, you first need to reinforce the zone where the screws will put pressure on the foam

-it was also necessary to fill in the factory precut holes for the stock control horns. They were filled flush to the control surface with balsa and foam CA.

-the new control horns were positioned on the same spots where the factory precut holes were. Then the screw holes were marked and drilled.

-the new control horns were then both glued and screwed on the control surfaces:

To attach servos:

-The servos were positionned at neutral with the servo tester

-The servo horns were screwed on to form a 90 degree angle (or as close as possible to it) with the surface of the wings. Due to the finite number of possible positions on the servo gear, it was sometimes an angle of 80 degrees instead of 90. I hope this will not have any negative effects on flight control.

-the control rods of the ailerons were doubled to reinforce them (otherwise they will flex in flight under the air pressure , they are too thin). The double control rods were fixed to each other with heatshrink:

-On the control horn side, the control rod is fixed with a screw type fixing system that comes with the XUAV Talon kit.

-Little bit of blue loctite and hot glue was used on all screws so that vibrations will not loosen them during flight

Fixing system for the XUAV Talon motor :

The XUAV Talon comes standard in the kit with a plywood piece on which you are supposed to screw the motor. However the defaut manual is so badly done that you risk to glue it in the plane fuselage, as prescribedn and then realize it is too late to fix your motor : because you will not have any access to this plywood piece to screw bolts and/or screws of your motor attachment system.

So BEFORE gluing anything, mark the position of the screw holes of your motor fixing plate (it is usually an aluminium cross shaped piece with pre drilled holes for both motor screws and fixation screws on the frame) and drill them.

Then, saw another piece of about 5mm thick plywood a bit smaller than the original kit piece like so:

It will be later glued against the kit piece (as shown in picture above). But first this extra plywood piece will be prepared:

-Screw holes are drilled

-Blind nuts are hammered and glued into these drilled holes. (i used 3mm diameter blind nuts for standard 3mm screws we usually use in our UAVs)

-Finally an opening is carved out to pass the motor wires through:

Then this part is glued on the original motor kit piece (with Titebond wood glue for ex) and fixed on it duriong a whole night to let it dry fully:

And the final result:

This will allow me to screw my RC tiger motors on it, even after the two parts of the fuselage will be glued on. It makes it possible to change your motors easily afterwards (which is absolutely necessary to try out different motor/prop combinations).

More updates to come as the build progresses,

Cheers,
Hugues

If you're old enough, do you remember in the late 80's how we surpassed our own parents when first personal computers, commodore 64 and other Atari computers came out ? Well I feel the same way now with our kids and UAV's.

Along gradual building of various UAVs , I accumulated so many spare parts that were just laying around that I decided to build a trainer quadcopter for my son and proposed him to try out, together, FPV for the first time! The attached youtube video shows our first noobs FPV journey...

 The trainer quad is made of:

-Assembled from various frame parts from : 3DR arms, home made plates, VulcanUAV landing legs, some other frames pieces from HK stuff, etc...

-a Pixhawk autopilot with 3.1.2 fw version

-3DR 880kv motors with 10x4,7 props + quadro ESCs

-powered by a 10.000 mah 4S battery

-5.8Ghz FPV setup with a RMRC 600Tvl camera

-Mobius for HD footage

My son can crash and abuse it, it is easily fixed. However I notice how I never had even to replace a prop (not like when I fly) because he is very prudent and he flies intuitively these things, even in non-FPV flights. He's gonna quickly be able to teach his father how to be a good pilot (for which there is still lots of training to do)!

I bet 3DRobotics could never produce those! That's what I'd call perfect gimbal stabilization technology : no soldering required, no battery and it flies.