Articles for February 2016

Emlid Reach for placing GCP

We have been using the L1 only Reach GPS from EMLID for about 2 months. We were first attracted to the fact that it claimed that it was going to be integrated to Pixhawk and would then, via a system of magic, give us centimeter accurate geotagged images, eliminating the need for ground control forever.

While we wait for that to become a reality, we have tried out the Reach as a replacement to our normal survey grade Leica GPS1200. We wanted to see just how accurate and robust the Reach is and whether it could be consider a tool for the budget aerial mapper to make more meaningful and accurate models. Despite our office being skeptical of L1 only GPS to give less than decimeter results, we were surprised at the robustness of post processed L1 data.

Our first major project using the Reach was in Zanibar, Tanzania early February 2016. The Reach was used to create a high accuracy GPS tracklog onboard a boat, to be coupled with sonar data, creating a medium accuracy bathymetric survey. Despite the antenna flopping over during the survey, some usable results were obtained. The full story can be read here: 3DroneMapping report

More recently, we attempted to create a workflow and benchmark test to adopt the Reach as our main surveying tool to place GCP. Having a Leica GPS1200 survey grade GPS has been great for all our projects, but lugging 30kg of additional hardware especially in remote places in Africa, as well the worry of transporting $60 000 worth of gear is a headache. As our workforce continues to grow, it is getting harder to afford such devices for all the teams to use. Placing GCP to a few centimeters is actually a simple process when you remove the RTK element and the Reach seems to do this just fine for us as well as having some other features baked into it for future use like IMU and Pixhawk integration.

The site chosen for the comparison is an active construction site near to Durban, South Africa. Points were surveyed by our office 3 months ago via a Leica GPS1200. The points have been semi permanently marked with road marking paint on tar, plastic bags arranged in “X” formation and other ways, making all points visible from the air for photogrammetric uses. The points were initially measured in RTK and then confirmed with a local NTRIP VRS server. The survey is based on the VRS coordinate system, Hartebeesthoek94 / Lo31 (EPSG:2054).

We wanted to test the Reach in 2 ways. The first being via RTK ways and then by post processing. A total of 3 Reach devices were used. It was decided to not use the Reach with an attached RFD900 radio. Previous tests have shown that the radio range, even at maximum power output, is not really useful for terrestrial work. We suspect that the polarization of the antennas is best suited for ground to air communications. It as then decided to send RTCM data via a TCP server, connected to an ADSL line(via a WIFI router)

The first Reach was installed at our office, 3km away from the site. This Reach, “BASE1” was to act as a reference base. The Reach was connected to the office WIFI and assigned a static IP. The antenna was installed on the roof of the office with a 300mm x300mm metal plate acting as a ground plane. The Reach was connected to our VRS and a coordinate was determined within 20 seconds. The point was averaged for over 30 seconds. This point occupation would form the basis of our control system making it easier to compare to the true system.

“BASE1” now had a coordinate, and was set to “Base” mode. The coordinate entered in the respective fields, the output set to “TCPServer”, GPS and GLONASS data was sent at 1HZ. Before leaving the office, we tested that the data stream was accessible from outside of our local network via the Android app “Lefebure NTRIP Client

On the site, “BASE2” was installed. This consisted of an antenna being installed on a 300mm x300mm metal plate acting as a ground plane, in an open area, elevated on a wooden fence post. The Reach was connected to a portable WIFI router, in turn connected to a public 3G service. The portable WIFI router was used as an access point to use Reachview as well as the internet. A Androind cellphone was also connected to the mobile WIFI network and Reachview accessed via Chrome browser. “BASE2” was initialized with the default Reach settings and configured to use “BASE1” via TCP client. After a 15 seconds, a solution was derived and stored. Reach was then placed in the default “Single” mode with GPS/GLONASS satellites being used at 1hz. The data being stored onboard.

Various points were then surveyed about the site. The 3rd Reach was setup on a 2m pole. The antenna placed on a 200mmx200mm sheet metal plate, and a plumbing bubble installed on the pole to ensure it was held vertically over every point. The point was located and then the pole/antenna positioned over the previously surveyed mark. The Reach was placed in the default RTK mode but “Static” was the operation of choice as the antenna would not be moving during the observation window. RTCM data was being received from “BASE1”, all raw observations were being stored as well as the solution. The measurement windows lasted for 60 seconds per point, at 1hz. Most points had open clear view of the sky about them, but 2 locations had high tension power lines overhead, which made for some interesting results. The starting points were measured at the end of the survey again to ensure that the base had not moved and to test the integrity of the data.

After each point was measured, the base was retrieved and the data downloaded. Rinex files were determined for “BASE2” and for each of the measurements. The solutions calculated in the field were collected and tabulated ofr each point. The TCP measured data collected from BASE1 was also tested via RTKLIB v2.4.3 b8. The exact same result was created on a PC via post processing from BASE1 to what was determined in the field.

Post processing from BASE2 yielded much better results. These were tabulated and compared to the original values from the Leica GPS. The configuration used to calculate the positions was the default RTKLIB settings, using Static modes and a single solution derived.

In the table, the X,Y,Z,dX,dY,dZ columns are in meters, the coordinate system being Hartebeesthoek94 / Lo31 (EPSG:2054). These were calculated from the raw processed WGS84 coordinates in ArcGIS and the South Africa geoid model applied to obtain orthometric heights. The “Original” columns are the the Leica GPS1200 surveyed and adopted results as true sub 30mm accuracy.

As can be seen, there are a lot of inconsistencies with the TCP data stream corrected solutions from “BASE1”. However, when compared to the PP solutions of “BASE2”, the results really do appear favorable and perfectly suitable for placement of GCP.

This is a really accurate result from such affordable and simple hardware. Using proper survey techniques and understanding what is going on with processed GPS data helps a lot in getting the best from these devices.

We conclude that:
– Post processing is really robust and works well to getting good results, especially regarding heighting

– There are a few latency issues with using a TCP server. We think that in our case, having the data being streamed at 5hz from BASE1 > Router > ADSL > Internet > 3G > Mobile WIFI > Reach is a bit long winded causing data delays / loss.

– 1hz is perfectly fine for static observations. For post processing, good measurements come from long observation windows and not the amount of raw data used to process with.

– Having a good ground plane helps a lot to reduce multipath as well as having obstruction free view of the sky.

– L1 only is not that robust and the control point areas need to be carefully considered to reduce multipath and long baselines

– It would be really great if coming versions of Reach could also allow for raw observations to be recorded while in “Base” mode. These could be used as a back up if the communication goes down between units as well as offering a more more robust solution possibility.

– The RTKLIB method is a bit painful when it comes to multiple points as there is no way of assigning a name to an observation. One needs to alternatively log the time and name / details for compiling a coordinate list. Each point needs to be individually processed, taking time.

– A set of Emlid Reach GPS units (at less than $600 for a pair!) is perfectly fine to place sub 50mm accuracy control points for UAV photogrammetry.

Device Setup is as follows:
Reach running Reach image V1.1, Reachview V0.1.0
Powered via 5v DF13 at 2ah
Tallysman TW-4721 placed on 300mmx300mm sheet metal, unobstructed
Conected via WIFI/4mbps internet ADSL connection
Static IP TCP Server
Broadcasting RTCM data at 5hz

Reach running Reach image V1.2, Reachview V0.1.0
Powered via 5v USB at 2ah
Tallysman TW-2410 placed on 300mmx300mm sheet metal, unobstructed
No internet / WIFI connection
Recording raw data at 1hz

Reach running Reach image V1.2, Reachview V0.1.0
Powered via 5v USB at 2ah
Tallysman TW-4421 placed on 200mmx200mm sheet metal on 2m plumbing pole
Mobile WIFI connection via 3G for Reachview / TCP client
Recording raw data at 1hz

Powered by WPeMatico

ArduCopter 3.2.1 and AntennaTracker 0.7.2 on MEGAPIRATE!

It’s a solution that you can build and upload the last APM 3.2.1 code for MEGAPIRATE BOARDS and AVR atmega2560 GENERICS BOARD with I2C bus communication.

As you know, megapirate team stop building APM and the last code was 3.1.5 version, we are desired work and port the last AVR APM 3.2.1 to this board, megapirate and AVR boards with atmega 2560 and I2C bus communication.


   – ArduCopter 3.2.1
   – AntennaTracker 0.7.2



These tools you need to download first.

1.1 Arduino 1.0.3 with gcc-4.8.2 version download from this link:

1.2 Git tool, download from this link:


2.1 Download and Decompress Arduino from section 1.1 to c:arduino. You will see this order path c:arduinohardwaretoolsavrbin

2.2 Download and install GIT tool from section 1.2 to default path. NOTE.- in the steps windows install choose the option:

“Run Git from the Windows command Prompt”

2.3 Open Explorer and navigate to ‘c:’ drive, right click and select “Git bash here”, it’s open a windows command prompt.

2.4 In prompt command line type the next command to clone ArduCopter-3.2.1_I2C branch as follow:

$ git clone ardupilot
$ cd ardupilot
$ git checkout ArduCopter-3.2.1_I2C

2.5 Open Arduino, go to File, Preferences, in “sketchbook location” click on Browse and choose the path where are the ardupilot folder you checkout with GIT,
in this case c:ardupilot, ok and close.

2.6 Now load Arducopter sketch, compile and upload to the MEGAPIRATE board.





These tools you need to download first.

1.1 Arduino 1.6.6 version, download from this link:

1.2 Git tool, download from this link:

1.3 fix_includes_arduino166 program, With this tool you can change all include headers files to work with arduino 1.6.6 in windows.
You need compile the code, it’s included on repo branch master-AVR Tools/ArdupilotMega_ON_Generic_Board/

1.4 Notepad++, download from this link:


2.1 Download and Install Arduino from section 1.1 to default path.

2.2 Download and install GIT tool from section 1.2 to default path. NOTE.- in the steps windows install choose the option:

“Run Git from the Windows command Prompt”

2.3 Download and install Notepad++ from section 1.4 to default path.

2.4 Open Explorer and navigate to ‘c:’ drive, right click and select “Git bash here”, it’s open a windows command prompt.

2.5 In prompt command line type the next command to clone Ardupilot master-AVR branch as follow:

$ git clone
$ git checkout master-AVR
$ echo “ARDUINO=/c/arduino” > /c/ardupilot/

2.6 Compile ToolsArdupilotMega_ON_Generic_Boardfix_includes_arduino166 with VS2013 or SharpDevelop (with this one was compiled).
Then you use as follow:

fix_includes_arduino166 -P <PATH_TO_FOLDER>

Example: Supose that you cloned Ardupilot in c:ardupilot then you will have c:ardupilotlibraries and you want make AntennaTracker c:ardupilotAntennaTracker then,

fix_includes_arduino166 -P c:ardupilotlibraries
fix_includes_arduino166 -P c:ardupilotAntennaTracker

This tool make changes to the files in all librarie path and this tool doesn’t make a backup of your files. You must be sure.

2.7 Open Arduino, go to File, Preferences, in “sketchbook location” click on Browse and choose the path where are the ardupilot folder you checkout with GIT,
in this case c:ardupilot

2.8 Open the next file with notepad++, c:ardupilotlibrariesAP_HALAP_HAL_Boards.h and replace this line #define AVR_ARDUINO_ENVIRONMENTS with //#define AVR_ARDUINO_ENVIRONMENTS. Save and close.
NOTE: If you uncomment this line, you are telling to Arduino make code for AVR Generic Board, but if you comment with this line with ‘//’ you are telling to Arduino make code for APM2 Board.

2.9 Open AntennTracker in Arduino and compile.


If you are looking for detailed and description file libraries modification follow the oficial PR on the oficial Ardupilot repo at:

Chat discussions at

Forum Discussions and supports at

Powered by WPeMatico

Remote piloting predicted to drive employment growth…

A report released last Friday by the Australian Government’s Commonwealth Scientific and Industrial Research Organisation (CSIRO) contains some pretty interesting reading, particularly for those of us involved in the RC community.

The report, ‘Tomorrows Digitally Enabled Workforce’, looks at changes to the workforce and society being driven by technology. These changes are likely to bring with them significant disruptions to segments of the workforce, and reports such as this are being used by government to help understand future workforce needs and manage the career transitions that many will be forced to make.

One of the encouraging messages that I took from the report, was that many more jobs are likely to be created through technological change than destroyed. Based on a combination of short term forecasting of current job requirements and longer term forecasting based on trends and scenarios, the report speculates about six new ‘jobs of the future’. One of these six new job types is remote controlled vehicle operators.

The rise in un-crewed vehicles is giving rise to a new workforce of pilots, drivers and ship captains along with those with the skills to maintain the hardware and develop the software – not to mention those involved in training this new workforce. The Australian Civil Aviation Safety Authority (CASA) has already noted more than 650 applications for remotely piloted aircraft alone, categorising the applications as ‘mostly dull, dirty, dangerous and demanding and best done remotely given the risk to human safety’. The report predicts continual growth in the number and diversity of jobs for RC vehicle operators over the next 20 years, as automation plays a greater role in improving safety and efficiency.

With autopilot developers, aerial camera operators, communications engineers and RC retailers making up the regular weekend crowd at the field where I fly, the shift is already apparent to me (the programmers just need to make sure they don’t inadvertently manage to program themselves out of a job).

If nothing else, the report gives me licence to further indulge my nine year old’s passion for RC aircraft on the basis that it could be much more than just weekend fun.

Powered by WPeMatico

University of Wyoming will host a drone aircraft symposium

Drone aircraft symposium to be hosted to the University of Wyoming. The event will focus in part on how they can be put to use in the state’s wide-open spaces and will cover technological developments as well.

Powered by WPeMatico

ArduSub, the final frontier of ArduPilot, now live

Good news from Blue Robotics: they’ve crossed the final frontier and ArduPilot is now underwater. Welcome ArduSub! (In historic progression since the founding of the project it was Plane, Copter, Rover, Boat and now Sub) 

All details are here, but this is the summary:

Firmware for Remote-Operated and Autonomous Capabilities in Underwater Vehicles

The ArduSub project is a fully-featured, open-source controller for remotely operated underwater vehicles (ROVs) and autonomous underwater vehicles (AUVs). Based on the popular ArduCopter code, the ArduSub code has extensive capabilities out of the box including feedback stability control, depth and heading hold, and autonomous position control if provided with position feedback.

ArduSub is designed to be safe, feature-rich, open-ended, and easy to use even for novice users.

System Components

  • A PixHawk or other DroneCode-compatible autopilot loaded with the latest version of the ArduSub firmware.
  • QGroundControl software for setup, configuration, and operation of the vehicle.
  • suitable ROV or AUV for use with the software
  • Many other useful additions: depth sensors, tether communications, cameras, and other sensors and actuators



  • ArduSub currently supports two frame configurations:

    • BlueROV 6DOF Frame: Maneuvers with unique 6 degree-of-freedom control
    • Vectored w/ Side-by-Side Vertical Thrusters: Provides excellent smooth control and stability
    • Vectored w/ Corner Vertical Thrusters: Provides excellent smooth control, stability, and 6-DOF control
  • In the future, other frame types will be supported, such as:

    • 3 and 4 thrusters arranged with two thrusters for forward/turn and one or two for vertical

Powered by WPeMatico

At DIAGO 2016

Each year, the Association of Technical Diagnostics of the Czech Republic organizes the DIAGO2016 conference, which took place this year in the spa town of Luhačovice in the HARMONIE I hotel.

We participated in the conference, as we do each year, and presented FLIR thermal cameras and our latest thermal imaging system for drones, which were give the final name of Workswell WIRIS. 

Our presentation included, in addition the traditional exhibition in the form of an exhibition kiosk, flying with drones for the conference participants. Our partner at the conference was the Vertical Images company, who presented two drones, the largest of which had installed our older Workswell Thermal Vision Pro (with white cover) thermal imaging system.

Powered by WPeMatico

New Raspberry Pi 3 with 64-bit cores and built-in Wi-Fi and BLE

New Raspberry Pi 3 is about to be announced, it will bring 64-bit 1.2Ghz cores and Wi-Fi connectivity. It is surely an exciting update for Navio2 and we can’t wait to get it into the air.



It is expected that the new processor will be similar to the previous BCM2835 with upgraded cores (probably Cortex A53), just like it was with the previous upgrade from single-core ARMv6 to quad-core ARMv7. That means that the peripheral blocks should stay the same and will have a high level of compatibility while bringing more performance. Cortex A53 is 30-40% faster the Cortex A7 according to data from ARM.


Build-in WiFi and BLE should simplify the configuration of the board eliminating the need in USB adapters.

As soon as we get our hands on the board we will make sure that it is supported by APM and will work with Navio2 autopilot HATs. As Raspberry Pi foundation maintains 40-pin connector compatibility it should be a seamless upgrade. We are yet to see how different the software will be for the new processor.

Thanks to CNX-Software for bringing the news. You can read more about Navio2 autopiot at .


Powered by WPeMatico

A new chapter in ArduPilot development

The ArduPilot core development team is starting on a new phase in the project’s development. We’ve been having a lot of discussions lately about how to become better organised and better meet the needs of both our great user community and the increasing number of organisations using ArduPilot professionally. The dev team is passionate about making the best autopilot software we can and we are putting the structures in place to make that happen.

Those of you who have been following the developments over the years know that ArduPilot has enjoyed a very close relationship with 3DRobotics for a long time, including a lot of direct funding of ArduPilot developers by 3DR. As 3DR changes its focus that relationship has changed, and the relationship now is not one of financial support for developers but instead 3DR will be one of many companies contributing to open source development both in ArduPilot and the wider DroneCode community. The reduction in direct funding by 3DR is not really too surprising as the level of financial support in the past was quite unusual by open source project standards.

Meanwhile the number of other individuals and companies directly supporting ArduPilot development has been increasing a lot recently, with over 130 separate people contributing to the code in the last year alone, and the range of companies making autopilot hardware and airframes aimed at ArduPilot users has also grown enormously.

We’re really delighted with how the developer community is working together, and we’re very confident that ArduPilot has a very bright future

Creation of ArduPilot non-profit

The ArduPilot dev team is creating a non-profit entity to act as a focal point for ArduPilot development. It will take a while to get this setup, but the aim is to have a governance body that aims to guide the direction the project takes and ensure the project meets the needs of the very diverse user community. Once the organisation is in place we will make another announcement, but you can expect it to be modelled on the many successful open source non-profits that exist across the free software community.

The non-profit organisation will oversee the management of the documentation, the auto-build and test servers and will help set priorities for future development.

We’re working with 3DR now to organise the transfer of the domain to the development team leads, and will transfer it to the non-profit once that is established. The dev team has always led the administration of that site, so this is mostly a formality, but we are also planning on a re-work of the documentation to create an improved experience for the community and to make it easier to maintain.

Expansion of ArduPilot consulting businesses

In addition to the non-profit, we think there is a need for more consulting services around ArduPilot and DroneCode. We’ve recognised this need for a while as the developers have often received requests for commercial support and consulting services. That is why we created this commercial support list on the website last year:

It is time to take that to the next level by promoting a wider range of consulting services for ArduPilot. As part of that a group of the ArduPilot developers are in the process of creating a company that will provide a broad range of consulting services around ArduPilot. You will see some more announcements about this soon and we think this will really help ArduPIlot expand into places that are hard to get to now. We are delighted at this development, and hope these  companies listed on the website will provide a vibrant commercial support ecosystem for the benefit of the entire ArduPilot community.

Best of both worlds

We think that having a non-profit to steer the project while having consulting businesses to support those who need commercial support provides the best of both worlds. The non-profit ArduPilot project and the consulting businesses will be separate entities, but the close personal and professional relationships that have built up in the family of ArduPilot developers will help both to support each other.

Note that ArduPilot is committed to open source and free software principles, and there will be no reduction in features or attempt to limit the open source project. ArduPilot is free and always will be. We care just as much about the hobbyist users as we do about supporting commercial use. We just want to make a great autopilot while providing good service to all users, whether commercial or hobbyist.

Thank you!

We’d also like to say a huge thank you to all the ArduPilot users and developers that have allowed ArduPilot to develop so much in recent years. We’ve come a very long way and we’re really proud of what we have built.

Finally we’d also like to thank all the hardware makers that support ArduPilot. The huge range of hardware available to our users from so many companies is fantastic, and we want to make it easier for our users to find the right hardware for their needs. We will continue working to improve the documentation to make that easier.

Happy flying!

The ArduPilot Dev Team

Powered by WPeMatico

Building, flying and crashing a large QuadPlane

Not all of the adventures that CanberraUAV have with experimental aircraft go as well as we might hope. This is the story of our recent build of a large QuadPlane and how the flight ended in a crash.

As part of our efforts in developing aircraft for the Outback Challenge 2016 competition CanberraUAV has been building both large helicopters and large QuadPlanes. The competition calls for a fast, long range VTOL aircraft, and those two airframe types are the obvious contenders.

This particular QuadPlane was the first that we’ve built that is of the size and endurance that we thought it would easily handle the OBC mission. We based it on the aircraft we used to win the OBC’2014 competition, a 2.7m wingspan VQ Porter with a 35cc DLE35 petrol engine. This is the type of aircraft you commonly see at RC flying clubs for people who want to fly larger scale civilian aircraft. It flies well and the fuselage and is easy to work on with plenty of room for additional payloads.

VQ Porter QuadPlane Build

The base airframe has a typical takeoff weight of a bit over 7kg. In the configuration we used in the 2014 competition it weighed over 11kg as we had a lot of extra equipment onboard like long range radios, the bottle drop system and onboard computers, plus lots of fuel. When rebuilt as a QuadPlane it weighed around 15kg, which is really stretching the base airframe to close to its limits.

To convert the porter to a QuadPlane we started by glueing 300×100 1mm thick carbon fibre sheets to the under-surface of the wings, and added 800x20x20 square section carbon fibre tubes as motor arms. This basic design was inspired by what Sander did for his QuadRanger build.

in the above image you can see the CF sheet and the CF tubes being glued to the wing. We used silicon sealant between the sheet and the wing, and epoxy for gluing the two 800mm tubes together and attaching them to the wing. This worked really well and we will be using it again.

For the batteries of the quad part of the plane we initially thought we’d put them in the fuselage as that is the easiest way to do the build, but after some further thought we ended up putting them out on the wings:

They are held on using velcro and cup-hooks epoxied to the CF sheet and spars, with rubber bands for securing them. That works really well and we will also be using it again.

The reason for the change to wing mounted batteries is twofold. The first is concerns of induction on the long wires needed in such a big plane leading to the ESCs being damaged (see for example The second is that we think the weight being out on the wings will reduce the stress on the wing root when doing turns in fixed wing mode.

We used 4S 5Ah 65C batteries in a 2S 2P arrangement, giving us 10Ah of 8S in total to the ESCs. We didn’t cross-couple the batteries between left and right side, although we may do so in future builds.

For quad motors we used NTM Prop Drive 50-60 motors at 380kV. That is overkill really, but we wanted this plane to stay steady while hovering 25 knot winds, and for that you need a pretty high power to weight ratio to overcome the wind on the big wings. It certainly worked, flying this 15kg QuadPlane did not feel cumbersome at all. The plane responded very quickly to the sticks despite its size.

We wired it with 10AWG wire, which helped keep the voltage drop down, and tried to keep the battery cables short. Soldering lots of 10AWG connectors is a pain, but worth it. We mostly used 4mm bullets, with some HXT-4mm for the battery connectors. The Y connections needed to split the 8S across two ESCs was done with direct spliced solder connections.

For the ESCs we used RotorStar 120A HV. It seemed a good choice as it had plenty of headroom over the expected 30A hover current per motor, and 75A full throttle current. This ESC was our only major regret in the build, for reasons which will become clear later.

For props we used APC 18×5.5 propellers, largely because they are quite cheap and are big enough to be efficient, while not being too unwieldy in the build.

For fixed wing flight we didn’t change anything over the setup we used for OBC’2014, apart from losing the ability to use the flaps due to the position of the quad arms. A VTOL aircraft doesn’t really need flaps though, so it was no big loss. We expected the 35cc petrol engine would pull the plane along fine with our usual 20×10 prop.

We did reduce the maximum bank angle allowed in fixed wing flight, down from 55 degrees to 45 degrees. The aim was to keep the wing loading in reasonable limits in turns given we were pushing the airframe well beyond the normal flying weight. This worked out really well, with no signs of stress during fixed wing flight.

Test flights

The first test flight went fine. It was just a short hover test, with a nervous pilot (me!) at the sticks. I hadn’t flown such a big quadcopter before (it is 15kg takeoff weight) and I muffed up the landing when I realised I should try and land off the runway to keep out of the way of other aircraft using the strip. I tried to reposition a few feet while landing and it landed heavier than it should have. No damage to anything except my pride.

The logs showed it was flying perfectly. Our initial guess of 0.5 for roll and pitch gains worked great, with the desired and achieved attitude matching far better than I ever expected to see in an aircraft of this type. The feel on the sticks was great too – it really responded well. That is what comes from having 10kW of power in an aircraft.

The build was meant to have a sustained hover time of around 4 minutes (using ecalc), and the battery we actually used for the flight showed we were doing a fair bit better than we predicted. A QuadPlane doesn’t need much hover time.  For a one hour mission for OBC’2016 we reckon we need less than 2 minutes of VTOL flight, so 4 minutes is lots of safety margin.

Unfortunately the second test flight didn’t go so well. It started off perfectly, with a great vertical takeoff, and a perfect transition to forward flight as the petrol engine engaged.

The plane was then flown for a bit in FBWA mode, and it responded beautifully. After that we switched to full auto and it flew the mission without any problems. It did run the throttle on the petrol engine at almost full throttle the entire time, as we were aiming for 28m/s and it was struggling a bit with the drag of the quad motors and the extra weight, but the tuning was great and we were already celebrating as we started the landing run.

The transition back to hover mode also went really well, with none of the issues we thought we might have had. Then during the descent for landing the rear left motor stopped, and we once again proved that a quadcopter doesn’t fly well on 3 motors.

Unfortunately there wasn’t time to switch back to fixed wing flight and the plane came down hard nose first. Rather a sad moment for the CanberraUAV team as this was the aircraft that had won the OBC for us in 2014. It was hard to see it in so many pieces.

We looked at the logs to try to see what had happened and Peter immediately noticed the tell tale sign of motor failure (one PWM channel going to maximum and staying there). We then looked carefully at the motors and ESCs, and after initially suspecting a cabling issue we found the cause was a burnt out ESC:

The middle FET is dead and shows burn marks. Tests later showed the FETs on either side in the same row were also dead. This was a surprise to us as the ESC was so over spec for our setup. We did discover one possible contributing cause:

that red quality control sticker is placed over the FET on the other side of the board from the dead one, and the design of the ESC is such that the heat from the dead FET has to travel via that covered FET to the heatsink. The sticker was between the FET and the heatsink, preventing heat from getting out.

All we can say for certain is the ESC failed though, so of course we started to think about motor redundancy. We’re building two more large QuadPlanes now, one of them based on an OctaQuad design, in an X8 configuration with the same base airframe (a spare VQ Porter 2.7m that we had built for OBC’2014). The ArduPilot QuadPlane code already supports octa configs (along with hexa and several others). For this build we’re using T-Motor MT3520-11 400kV motors, and will probably use t-motor ESCs. We will also still use the 18×5.5 props, just more of them!

Strangely enough, the better power to weight ratio of the t-motor motors means the new octa X8 build will be a bit lighter than the quad build. We’re hoping it will come in at around 13.7kg, which will help reduce the load on the forward motor for fixed wing flight.

Many thanks to everyone involved in building this plane, and especially to Grant Morphett for all his building work and Jack Pittar for lots of good advice.

Building and flying a large QuadPlane has been a lot of fun, and we’ve learnt a lot. I hope to do a blog post of a more successful flight of our next QuadPlane creation soon!

Powered by WPeMatico