Blogs

Inspired!

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 ?

Greetings!
We have some great news for those of you about to purchase autopilots. 
In cooperation with Robotshop.com (and Robotshop.com/eu/) you can now acquire autopilots bundled together with UgCS.
If you are about to get a Pixhawk or an APM autopilot with GPS, you can get the UgCS ONE license on top of that for just a few dollars.

In addition to that you can also get AR.Drone bundled together with UgCS in a similar manner.
For more information please visit www.robotshop.com and www.ugcs.com 

Safe flights,
UgCS Team

A collaborative research project between the University of Adelaide's Unmanned Research Aircraft Facility and South Australia's Department of Environment Water and Natural Resources, and with support from ForestrySA. Aerial images collected by a 3DR Iris+ multirotor carrying a Canon S110 compact camera. Data processed using Pix4DMapper to generate point cloud and orthomosaic.

From the South China Morning Post, Hong Kong's biggest newspaper:

One recent weekend, I was lounging in a Hung Hom hotel's rooftop pool with friends from out of town when we noticed a silent visitor: hovering about three metres above us, its rotors whirring, a matt-black creature was slowly manoeuvring to keep the camera attached to its undercarriage trained on our group below.

My friends, on holiday from the US, were taken aback - "Whoa. Look. A drone!" - but I was unfazed. Although not a daily occurrence, a drone darting in and out of the Hong Kong skyline is fairly common sight. FlyCamHK, a specialist drones retailer, estimates that there are now more than 5,000 drone users in the city.

As the popularity of drones continues to grow among hobbyists and businesses, Hong Kong is often being described as a wild frontier for the radio-controlled aerial devices.

The extreme contrasts between the city's tower blocks, rural greenery and rugged coastline, along with its compact size and accessibility, make it an ideal place for flying drones and recording breathtaking aerial videos. Further fuelling the drone explosion are the relaxed regulatory climate and low entry barrier (cheap quadcopters can cost as little HK$250, although more sophisticated models for the ambitious hobbyist easily run to about HK$10,000).

However, some industry insiders and critics worry about the potential for injuries from out-of-control quadcopters, invasion of privacy from snooping cameras and the devices getting in the way of planes in the current freewheeling environment.

Civil Aviation Department regulations classify drones - and model aircraft - weighing less than 7kg as unmanned aircraft systems (UAS) and do not require users to have any special licence to fly them.

Much stricter rules apply to bigger models, but the technology has advanced so quickly that all but the very largest personal drones come under that 7kg limit. Acknowledging "the significantly different level of sophistication of systems available in the market", the department site urges operators planning to use the devices for non-recreational work to submit details of their plans to the department well before the intended date.

This call to submit plans is not a legal requirement, and only one company, SCP Aerials, has ever flown drones with official permission.

Advertising filmmaker Edwin Lee, who uses them in his work, says he once applied for approval, but the process was so slow he eventually went ahead without an official green light. "It's not like they have anybody watching the skies," he says.

Blogging about his visit to Hong Kong, an American videographer, whose aerial film of the city has become a favourite of local drone pilots, writes: "Coming from the US, people often look at drones with mistrust, or even fear, but in Hong Kong, people seemed genuinely curious and interested, which I found refreshing. Even the police officers would come by to take a closer look, and provided me with tips on good places to fly."

Still, some worry that the city's love affair with drones may reveal a darker side. Fears about privacy and the potential for injury are common. Drones are speedy devices - a top-range model from DJI can reach 80km/h - and their spinning rotors can cause serious injury if they hit a person.

Perhaps the most publicised injury involved an American photojournalist who lost the tip of her nose when a drone became tangled in her hair during a restaurant publicity event.

In another close call, a drone filming the Occupy protests in Mong Kok last year crashed into a building and tumbled into the crowd. Luckily, no one was hurt.

Hong Kong is the biggest drone hub. More than 90 per cent of the world's drones are shipped out through the city

Supporters are quick to point out there have not been any reports of serious injury or drone-related privacy complaints even though Hong Kong is one of the world's most densely populated cities.

Most drones have built-in safety systems: if the communications link to the pilot is lost or the battery runs out, they are programmed to descend slowly to the ground or use their global positioning system to return to the operator.

A bigger concern involves the devices getting in the way of commercial aircraft. Many drones have a function called No Fly Zones, which prevents them flying near airports.

Nonetheless, many pilots tell stories of drones crashing or behaving erratically, and critics believe it is only a matter of time before someone is hurt.

Aficionados such as Raphael Pirker, CEO of consultancy Team Black Sheep Avionics, reject depictions of the city as the "Wild West" for drones.

"Not at all," Pirker says. "Hong Kong is the biggest drone hub in the world; more than 90 per cent of the world's drones are manufactured in Shenzhen and shipped out through Hong Kong. Every large drone manufacturer has an office in Hong Kong. The industry is well established, and there are sensible regulations in place and people adhere to them."

The biggest drone maker is DJI. Set up in 2006 by University of Science and Technology alumnus Frank Wang, it now accounts for between 50 and 70 per cent of the market.

DJI public relations manager Michael Perry says some concerns are overblown. The biggest growth sector in the personal drone market, he says, is not in crowded urban centres or among photographers but in service roles well outside towns.

"Drones can get to places that were previously inaccessible, too costly, or too dangerous to survey," Perry says.

"So inspection is a big market for drone technology: electrical wire inspection, inspecting pipelines, solar panel fields, or radio tours. In what's called precision agriculture, drones can be used to more accurately map the land or use infrared sensors to monitor crop health more closely, showing you exactly where you need to irrigate, or spray pesticides. Archaeologists can now use 3D mapping software with a drone to precisely measure and accurately map sites."

Much of the inspection and maintenance work was previously conducted using helicopters or fixed-wing planes. Heliservices, the sole local helicopter service provider, aims to respond to this competition by rolling out its own drone programme. The company will be relying on its deeper pockets, years of aviation experience and familiarity with the regulatory framework to see off a slew of amateur challengers.

The company does concede, however, that safety worries stemming from lax controls on drone usage is an issue.

"There is a worldwide concern in aviation about the growing number of unregulated UAVs being operated illegally in airspace used by planes and helicopters, and Hong Kong is no exception," says Heliservice director of sales and marketing, Graham Hamilton.

"UAVs are supposed to be operated at a very low level, below the normal levels of commercial aircraft, and are supposed to be operated well clear from airports and heliports. But there have been numerous occasions when our pilots have encountered UAVs being operated in the areas that we operate in, in proximity to our aircraft ... We are seeing more and more encroachment on our airspace."

Hamilton says the potential danger of unregulated drone use is widely underestimated, suggesting that "sooner or later there is going to be a collision, perhaps where an aircraft engine ingests a drone and it results in a catastrophic crash with potential loss of life".

Even so, the number of hobbyists is likely to grow apace with commercial users. Amateur aerial videos of the skyline, harbour and country parks are racking up the hits on YouTube.

FlyHK, the city's first drone aerial photography and racing competition held last month, is another indicator of their popularity as a leisure pursuit, although organisers concede the sight of whizzing quadcopters is rousing unease. Writing on Facebook, one critic described clips from the contest showing a drone flying low over people, houses and power lines, raising "the potential for catastrophe".

That's why drone industry executives such as Perry say the time has come to introduce some considered controls.

"I think the lack of regulation could potentially lead to overregulation," he says. "If you have no rules and something bad happens, the knee-jerk reaction is to say 'ban them all'. We want to see sensible rules that keep the skies open."

Patrick Kosiol, co-founder of video streaming system Sky Drone, concurs.

"Drones, especially in the commercial field, can revolutionise how we live," he says. "All of a sudden, physical distance is not that much of an issue. Let's imagine there are drones that can fly autonomously from point A to point B and perform a certain task there: drop off a parcel, deliver medical supplies, drop a navigation beacon, then charge up its own battery, and so on. The possibilities are endless and exciting.

"At the same time, there absolutely are risks, dangers and concerns about drone flying which need to be addressed. This is a field where regulators need to sit down with the industry to determine the best way to regulate the market.

"Hong Kong does have some regulation in terms of drones, but it needs to step up its game to get the commercial use of drones regulated quickly."

 

Hi all,

following my last post on positional accuracy, the discussion about ground planes and shielding as well as the general debate about the M8N, I started a series of tests comparing different M8N modules. This is the first part where I focus on comparing the modules in a bench test to compare positional accuracy.

The setup

I tested the following boards with settings optimized for Ardupilot:

• CSG Shop EMI / M8N / CGGBP.35.6.A.02 / 8cm ground plane
• CSG Shop XL / M8N / CGGP.35.3.A.02. 
• DroTek / M8N / T0027
• Virtual Robotix / M8N / GCCP.25.4.A.04
• 3D Robotics / 6H / GP1575.25.4.A.02

Additionally, I tested the DroTek / M8N / T0027 with an "external" 9cm ground plane.

Since all modules produce low HDOP/PDOP values - around 0.7 and 1.3 respectively - the comparison focusses on positional accuracy/stability. Therefore, all GPS boards were plugged in for 10min before recording. Then I recorded their positions for 10-15min using u-center. Scatter plots of the position errors are used to compare the boards.
As a reference I recorded the GSG EMI in parallel when testing the others.
The image above shows the setup on the roof and the image below a closeup of test rig.

DroTek with the additional ground plane:

XY scatter:

Results

• It is obvious that the CSG EMI and the DroTek with external ground plane outperform all other boards. 
• The DroTek and the VR show comparable accuracy.
• The CSG XL shows better performance compared to the DroTek and the VR but is not as good as the CSG EMI and the DroTek with external ground.
• The 3DR 6H shows a much more scattered distribution.

Discussion

• The board design (electronics) does not seem to have any influence.
• Larger patch antennas result in higher accuracies.
• A larger ground plane results in higher accuracies.
• The ground plane seems to have a higher influence compared to the antenna.

u-blox provides a diagram (page 19) showing the effect of the size of the ground plane for patch antennas. Unfortunately, the ublox document only lists 18mm and 25mm antennas. For 25mm antennas 7cm for the ground plane seem to be sufficient. For the 35mm it should be larger. 

Remark
The results presented are only from one test. So there is for sure uncertainty. However, I made similar test the past days with comparable results. The 3DR 6H performed better in previous tests but not as good as the M8Ns, which performed not as good as in the results presented above (except the CSG EMI which showed similar results - I have not tested the DroTek with additional plane in previous test).

The next step is to compare the CSG EMI, the DroTek with and without the additional ground plane and the 3DR on a copter to compare the influence of the ground plane as well as of the shielding.

Cheers,
Thorsten

This post will describe how to control a GoPro camera (usually mounted on a gimbal), via a Raspberry Pi with a USB WiFi dongle. 

The ideal Raspberry PI for this setup is the A+ model because it is small and has the needed single USB port for the WiFi dongle. 

Parts List:

1 GoPro Camera 

1 Raspberry PI (suggest A+ model, but any PI will work)

1 USB WiFi dongle (PI approved) Suggest this one: AirLink N150

2 Jumper wires or 1 servo header that can plug into 1/10th center pins (with center power pin removed)

1 APM or PixHawk board

Of course, all of this is mounted on your Quad or Plane or whatever. On my hexicopter, the PI is powered by one of the ESCs UBEC outputs, where I cut a micro-usb cable and soldered the 'red' and 'black' wires to the power output of the UBEC of the same color. The other two USB wires are not used.

Setup:

Step 1: Enable the GoPro WiFi access:

The first step in making all of this work is to configure your GoPro camera to accept a WiFi connection. The camera is actually a WiFI access point. 

The details on how to setup your camera is here. If you can connect the GoPro App to the camera, then you can connect the Raspberry PI. You should verify that the GoPro WiFi is working with the GoPro App BEFORE proceeding to connect the PI. You can pick a unique access point name for your camera and use the same name in the Raspberry PI configuration when connecting to the camera with the PI.

Step 2: Connect the Raspberry PI to the GoPro Camera's WiFi:

Once you have established the camera's access point and assigned a name and password, you can make an entry in your PI's network configuration file to configure the connection.

From a shell prompt type the command:  sudo nano /etc/network/interfaces

Add some lines to the file as follows:

allow-hotplug wlan0

iface wlan0 inet dhcp
wpa-ssid "mygopro"
wpa-psk "mypassword"

Reboot the PI and it should automatically connect to the GoPro.

Step 3: Communicate with the GoPro

The GoPro camera should have the standard IP address of 10.5.5.9. If you can ping this address, you have successfully connected to the GoPro so now you are ready to send it commands.

The list of commands are here.  The camera is controlled by sending HTTP request commands in the form of a header string. 

for example, this string turns the camera on:

http://10.5.5.9/bacpac/PW?t="wifipassword"&p=%01"

Where 'wifipassword' is the password you set when configuring your GoPro.

You can experiment with sending commands with a web browser to get familiar with how to control the camera with web requests or write your own scripts.

Step 4: Use a Python Script to Control the Camera

Attached is a sample python script that will listen for a signal on GPIO pin 5 on the PI header, and send a request to the camera to take a picture when triggered.

gopro.py

To use the code, start the python script after connecting to the camera with the following command:

sudo python3 gopro.py -photoMode

This will start the script with the camera set to take pictures. If you want it to trigger a video instead, leave out the '-photoMode' option.

Step 5: Configuring APM or Pixhawk to send the signal to the PI

To use this setup with the APM or PixHawk control board, you need to connect the output of the 'relay' pin (A9 on the APM), to the GPIO pin 5 on the PI (or the pin of your choice).  The script is configured to use GPIO pin 5.

Here is a picture of the APM board from This link

The PI pinout is here

Connect Pin 29 (GPIO 5) on the PI to A9 (S) on the APM, and GND pin 30 on the PI, to GND A9 (-) on the APM.  Check the link on the APM website for the PixHawk settings for the relay output pins as I have not used PixHawk (yet).

Step 6: Configure your Radio to Trigger the Camera

In Mission Planner, you will need to select which channel on your radio to assign to trigger the camera input. 

This link describes how to configure the shutter.

Select "Relay" for the Shutter output (not RC10 as shown in the above image example).

Then set the Ch7 option to "Camera" as shown here:

This can also be set on the "Advanced Parameters" setup area.

Step 7: Start Script on Boot:

To make all of this automatic, you can configure your PI to always connect to the GoPro and start the script when the PI boots. Or you can do it manually when you want to fly. 

To make it automatic, you can modify your '/etc/rc.local' file to make the script start on boot. Here is a sample rc.local file:

rc.local

Once you have completed all of these steps, you should be able to trigger the camera to take a picture with a switch assigned to Ch7 on your radio. 

If you want to GeoTag your images, you can follow the instructions at the ArduCopter GeoTagging page.

Happy flying.

Developing a new product starts with a pretty clear idea of what you expect the finished thing to do. Mathematically, you can can work out the expected performance and logically you can understand how this performance translates into useful applications. But I'm always fascinated by the qualitative feel of a product, that intangible experience that makes you think "Wow, that is so cool!"

I'd like to share a few experiences that I had during the testing of our new SF30 laser range finder. We decided to make a laser sensor that could measure so fast that even narrow obstacles like overhead power cables could be detected reliably, even from a moving UAV. Additionally, we wanted the SF30 to produce high density point clouds when used in a scanning system. We felt that without this high level of performance, reliable obstacle detection and collision avoidance would be impossible.

Quantitatively, we knew that the SF30 could measure 36633 times per second. What we didn't know was how that "felt" in practice. The yellow 'scope trace above shows the data output from the serial port of the SF30. The baud rate is 921600 and on the blue trace you can see a synchronization marker.

Looking at this high speed data stream for the first time, we couldn't get a feeling for what an obstacle with a high relative velocity would look like. We were also concerned that there weren't many embedded processing platforms available that could make obstacle detection decisions within the 27 microseconds between readings, whilst flying a UAV.

So we added an old fashioned analog output with an alarm that has a programmable activation distance. In the image below the yellow line is an analog representation of the measured distance and the blue line is an active low alarm that warns of a close obstacle.

Qualitatively, this is a much clearer picture of an obstacle than the earlier data stream and we can see that the obstacle was in front of the SF30 for about 4 milliseconds. So here's the cool part. The obstacle is an elastic band flicked at full force through the laser beam. The band was traveling at about 20 meters per second and the SF30 hit it 137 times.

My immediate response to this result was - this is going to work! My intuitive understanding of what it takes to hit a small obstacle from a fast moving platform is that you need to hit it lots of times to be absolutely certain that it is a real threat. Hitting the fastest thing that I could find 137 times is just amazing.

Of course, the next issue is how the host controller is going to catch a fast alarm signal. Certainly much more easily than a fast data stream but how about latching the alarm until the controller is ready to acknowledge it? In the image below, the blue alarm line has stayed low after the obstacle detection event. The alarm is reset by a command from the host sent through the serial port.

So now we end up with a remarkable solution to detecting obstacles that have a high relative velocity. On the one hand, the SF30 can measure even small obstacles many times no matter how fast they are moving. On the other hand, a simple alarm signal can warn the UAV about the presence of an obstacle without occupying all the processing capacity of the flight controller.

From Quartz

In a patent application from last month, uncovered by the BBC yesterday, Amazon outlined a plan for its proposed delivery drones to get packages to you in half an hour, regardless of where you are.

Up to now, Amazon’s drone plans have suggested they would arrive at your doorstep, dropping off packages like a smaller, louder mailman. But Amazon’s application suggests the company is exploring ways to have its drones come directly to wherever your smartphone is.

The application outlines a process whereby an Amazon customer orders something small—a book, perhaps, or maybe a box of Tide—via the Amazon app and selects the “Bring It To Me” delivery option. The nearest drone delivery system hopper would then saddle the drone with the order and deploy it to the location of the customer’s smartphone.

Once within range, the drone then will perform a controlled landing by somehow using the camera function of the customer’s smartphone to navigate a path from the sky to the ground. Exactly how is a little unclear, though the patent notes that the customer could theoretically land the drone herself. Presumably, though, the customer would have to make sure their phone was somewhere safe, in case the drone had to make a hard landing.

Not that landing is essential. The patent application suggests the drone wouldn’t have to actually touch the ground to drop off your delivery—it could just hover near you, release its package, and be on its merry way. The filing also says that Amazon wants to its drones to communicate with each other while in the air, “to share weather information, location information, routing information, landing areas.”

There are still a few hurdles that Amazon will have to clear before drones whiz through the skies bearing urgent deliveries of paperbacks and gluten-free pasta. There’s no guarantee that the US authorities will approve the patent, nor that Amazon will end up implement the technology if it does. The company is also still hoping for approval from the US’s aviation administration and other countries’ regulators for use of a drone program that wouldn’t require Amazon to keep drones within the line of sight of human operators. 

Phys.org adds:

Nate Swanner of SlashGear picked up on the patent discussion about how the drone may not only focus on delivering to a desired location but also communicate with one another, "sharing info on weather or landing zones. Those delivery drones may also share info on flight paths; for instance, they'd know a particular highway was gusty from big trucks based on their flight data, and fly a bit higher to avoid trouble or at an angle to ease its entry/exit from the airspace above the road next time, and share that info with other drones."

The patent wording includes talk of a wireless mesh network which may be used to provide communication between UAVs (e.g., to share weather information, location information, routing information, landing areas), UAV management system, materials handling facilities, secure delivery locations and/or relay locations.

 

Hey guys,

Thought I'd share the latest Pixhawk build. This little guy is a work in progress but so far the results are great. It's surprisingly stable and the battery lasts about 6minutes will full gear.

Even with the enclosed prop frame, FPV gear, Pixhawk + GPS + Telemetry, 2600mah 3S battery, Tmotors, and 12a OPTO this only weights 790grams. I'll share more details, video and the build photos if anyone is interested.

Happy droning, Tedro

Pre-orders are now being taken for the eXom inspection drone.  An early quote from a US based rep for Sensefly suggests it is going to be priced in the $40,000-$45,000 range.  You can buy two of these and map lots of cell towers....or perhaps just get a Tesla instead.

http://gpsworld.com/sensefly-launches-intelligent-mapping-and-inspection-drone/

Cool new board from Gumstix, designed from the ground up to run APM/PX4 code.  

Gumstix, Inc., a manufacturer of computers-on-module (COMs), has announced the latest update to its AeroCore series of micro-aerial vehicle (MAV) electronics, providing all the intelligence needed to build the next generation of aircraft. Comprising a full suite of hardware and software development tools, the AeroCore 2 is available in variants compatible with DuoVero or with Overo COMS. Designed with Gumstix’ Geppetto, the AeroCore 2 gives MAV developers greater selection in finding a computing solution tailored to their needs, with high precision GPS, WiFi connected autopilot, and video streaming functionality.

The AeroCore 2 runs NuttX real-time OS on an ARM Cortex-M4 microcontroller, with space on board for a Linux-powered supervisor COM. Gumstix COMs have successfully powered many applications in the field of MAVs, from real-time airborne target tracking to flying, self-organized wireless networks. The two-tier architecture provides a hard RTOS for machine controls and sensors, and high-level Linux programs to manage mission intelligence. RC radio control can be implemented by connecting a standard RC receiver.

The AeroCore 2 supports Gumstix’ new precision geopositioning boards, based on u-blox’ NEO-7 modules. The PreGO board featuring the NEO-7M module offers standard ±2.5 meter accuracy at a reduced cost, while the PreGO PPP board with the NEO-7P module offers precise, sub-meter level accuracy using PPP technology at an unbeatable price, with supported RTK capability.

“The AeroCore 2 combines the flexible, high-level integration of the AeroCore control board with both our best-selling series of COMs, Overo, and dual core processing power with our DuoVero COMs,” said W. Gordon Kruberg, M.D., president and CEO of Gumstix, Inc. “COMs have been at the heart of many user projects in the MAV field, and with the recent expansion of interest in MAV applications, the AeroCore 2 offers our users a sophisticated yet simple way to get offer wifi enabled autopilot and swarm technology.”

The AeroCore 2 is fully compatible with the PX4 open-hardware project’s suite of software, including MAVLink for autopilot communications and QGroundControl as its ground station. In addition, ArduPilot, Mission Planner and APM Planner 2.0 are now supported.

X-UAV had a stand at the Beijing expo displaying their new MFM material and showing off the difference between EPO and MFM.

The latest products, MFM (new materials), Comparing EPO and EPP, it is completely changes in technology and function.

Its density is between EPO and EPP, and 2-3 times rigid than the 35 density of EPO, more than 10 times toughness than EPO.

Be it the fall, or the spring, I welcome this time of year.  Teaching unmanned aircraft systems operations at the University of North Dakota is a lot of work.  This time of year, however, makes it all worth while.  It's the time when my students have completed their multi-rotors after having studied the components from a systems-engineering perspective.  And these young men and women are not engineers.  They are pilots that truly believe that knowledge, skills and professional attitudes are needed in this wonderful world of emerging UAS technology.  This semester, I had 14 undergrads and one graduate student taking my Systems of the Unmanned Aircraft (AVIT-331) course.  The accompanying photo shows them after having built their 3DR Y-6s.  All of them, contrary to popular belief, will have soloed their aircraft and will have completed a flight test and written system evaluation as part of the course by the time grades are due. It has been, and continues to be, my extreme pleasure to work with these enthusiastic young (or not so young) men and women.

Complementary filters enable sensor fusion, are easy to implement and eliminate integrating errors from gyro’s or accelerometers. Normally complementary filters are discussed in the frequency domain.  Using simple Python code a 1^st order linear complementary filter for determining the quadcopter ground speed was analyzed in the time domain. The results are depicted in the figure shown above.  voff represents the filter output of the accelerometer offset,  acc(n) the filter output  of the accelerometer, vgps(n) the output  of the GPS velocity, vgps,  and v(n) the sensor fusion output of the filter.

It follows from the figure above that the integrating drift of the accelerometer is converted into a constant steady state error.  Moreover this error can be eliminated by deriving the filter output at the start of the quadcopter with GPS input zero, and subtracting this value from the complementary filter output during flight mode. It also follows that the output v(n)  (steady state error corrected) corresponds nicely with the GPS velocity (noise added at simulation) and equals the algebraic sum of the more slowly varying acc(n) and vgps(n) contribution. Output noise is suppressed due to the low pass filtering of vgps.

Although these results confirm the already known features of complementary filtering, it helped me a lot in a better understanding of the basic mechanisms of complementary filtering, especially how a delayed, filtered signal vgps(n) nevertheless results in a correct complementary filter response.

The simulated results are confirmed by actual recorded data from my quadcopter, see figure below. For more details consult my google site.

Last November we posted the details and results of the first year of our prototype tilt rotor project. A lot has happened since that post, so we thought we’d provide an update. We also recently presented our progress to the Dronecode Foundation, and if you haven’t seen it you can find it here.

After the positive reception to “Tiltrotor 1”, we were given some guidance from the APM development team. We had reached both the limits of our APM 2.5 and our prototype airframe, and wanted/needed to devote more time to software and less time to airframe and aircraft hardware issues. We upgraded to Pixhawk, and were given a “FireFly 6” from Craig Elder and 3D Robotics to continue software development.

This winter was spent indoors working on improving our existing code and porting it over to Pixhawk. We originally started our code with a 3.1 version of copter, and needed to integrate this into both 3.2.1 and master to stay up to date with the project and have the best possible software for use on Pixhawk. We won’t bore you with the details, but there was an enormous amount of learning and man-hours to go from an APM 2.5 and the basic Arduino compiler to the current APM development environment!

Our current "Tiltrotor_Y6" code is a blend of both APM:Copter 3.2.1 and APM:Plane 3.2.3. It is designed very specifically to the “FireFly 6” airframe at the moment. This is for good reason! (disclaimer: we are not associated or working with birds Eye View Aerobatics, just using their aircraft for software development)  Like our first design, we spent an inordinate amount of time dissecting and studying the control of pitch, yaw, and roll at various thrust angles between vertical (helicopter) and horizontal (airplane). There are MANY ways to approach thrust vectoring tiltrotors, and each one comes with a very unique set of characteristics and compromises. Given the FireFly’s unique configuration of 6 motors, 2 elevons, and the thrust vector, we had to stay focused on this airframe.

The major components of our Tiltrotor_Y6 code include the following:

General Software Additions:

1.The Thrust Vector “Attitude Controller”  (Blended Aerodynamic and Thrust Vector Controllers)

2.The Thrust Vector “Speed & Angle” Controller ( Speed and Thrust Angle limiting functions)

3.A Unique "Turn Coordination" Controller for Hover / Conversion / Airplane Mode

4.Implemented the use of the Airspeed Sensor in Copter

FireFly 6 Specific Additions:

1. Aft Motor-Set Controllers to handle both VTOL and Airplane flight modes

2. Airplane Mode Differential Thrust Yaw and Differential RPM Controllers

3. Elevon function/authority management

4.  Thrust Vector conversion functions

We utilized a total of 7 PID controllers for attitude management (5 for rotor-based controls, and 2 for the elevons), so tuning was no small task! We executed a very methodical build-up test approach and had Hover, Conversion, and Airplane Mode attitude control tuned in about a week of flying. Here are the results…

Currently, we are only flying in “Stabilize Mode” with manual thrust vector control. Our conversion is nearly 100% effortless and only requires minor throttle adjustments at high thrust vector angles to control altitudes, and at lower angles the pilot can simply fly it like an airplane!  The transition towards airplane mode is easily accomplished while maintaining a target pitch of zero degrees (level deck).  There is no reason anymore to accelerate with a nose-down command prior to beginning the transition to airplane mode, which greatly simplifies the task for the pilot.  We are extremely satisfied, but we still have a lot of work to do to further refine the conversion scheduling and make the transition more robust to user inputs.

Our Tiltrotor software is still very developmental at the moment, and the entire picture of what an Autonomous Tiltrotor code will look like is foggy. We have a good idea, but here’s what’s next in the immediate future:

1.Continued “stabilize” development and data collection for use in Autonomy design

2.FireFly 6 airframe upgrades/modifications to improve performance and conversions even more

3.“Auto Conversion”

4.Blending Copter and Plane Navigation

5.Full AUTO VTOL ( Takeoff- Hover -Convert- Cruise- Convert- Hover- Land) sequence

Expect more updates as we progress this summer. A special thanks to Andrew Tridgell and Craig Elder for their guidance and support, and the entire APM Development Team who have provided the framework and capabilities for us to build upon.

Hi all,

i wanted to write down the journey i did over the past few years after a friend pointed me to diydrones.com.

I was quickly hooked by the hobby virus after assembling, flying and crashing my first rc-plane and afterwards fiddling around to get a APM1 integrated into a Bixler.

Since i live in a dense populated city i thought i should start with doing autonomous missions on the ground and so was pretty enthusiastic about the released rover code from Jean Louis Naudin in 2012.
I bought me a rc car from Hobbyking, strapped a APM1 on to it and it was great fun right from the beginning.

When i got involved with the rover community i teamed up with Tom and Tridge and we did a huge amount of tinkering, coding and testing in the following years.
I could get little deeper insights how things are working and Tom was able to win the 2013 AVC with his vehicle (Peloton class) which was a quite satisfying outcome i think.

I then bought me a few more components, a quad frame and started further explorations at the flying field.

Over the years i flew MultiWii, Megapirate, Harakiri, Baseflight and other available firmware/hardware combinations.
I did build a few big camera ships (Hexas, Octos) as well, mostly equipped with DJI and ZeroUAV autopilots.

But to be honest i am always missing the features and functionality ArduCopter/ArduPlane and APMrover2 comes with.

I will stick with Pixhawk in the future whenever its possible.

Today i can proudly report from the first big feature filming job with a X8 Octo equipped with a Red epic cinema camera beneath :) A rig worth 50.000 $. It was a long exhausting but very satisfying day.

So i think its time for a few nice words to all the developers and all other people involved.
This achievement wouldnt be possible without your work, the time you spend with the project and i am thankful for every single line you wrote over the years!

Im really looking forward to spend more time with pixhawk / linux autopilots and the community.

In deep gratitude for your time and efforts helping me to reach my very personal moon landing :)

Cheers
Linus

Τhis video shows tethered quadrocopters flying steadily together at high speeds exceeding 50 km/h in a confined space. With the tether exerting more than 13 gs of centripetal force, multiple quadrotors are able to fly 1.7m- radius circular trajectories in formation across different orientations in space and then successfully perform a coordinated braking maneuver.

This research was conducted at the Flying Machine Arena at ETH Zurich, read more on Robohub.

I've been working on a universal pod, to carry additional equipment on drones. While I was playing around with my 3D program of choice (Shade 3D) I got the brilliant idea to add a set of small wings to my pod.

The idea is to create some additional lift and control to the combined drone+pod (the drone is a delta wing).

But does it make any sense? I know very little about aero dynamics, but thought it might make the delta wing carry a bigger load (the Pod), if the load had a set of wings of it's own.

The Pod could even be dropped for a glide landing when the mission was accomplished.

Question is - does it make sense and how should can the wing design be optimised placement and shape wise? Anyone?

Drones provide an “eye in the sky” which can be very useful for water scientists. Many water bodies are often surrounded by difficult terrain, making it difficult to observe changes over time. Extreme droughts like the ones currently in California and Texas make the use of drones for monitoring rivers and lakes especially important.

A multinational team of American, German, and Estonian researchers have teamed up to measure the flows in rivers with unmanned aerial vehicles (UAVs) using a new real-time particle tracking technology.Obtaining the speed of the water in a river traditionally involves engineers wading into the river or using boats outfitted with special equipment for flow measurements. ...

Read more at: http://precisionlanding.irlock.com/?page_id=4364

HyDroneS
www.hydrones.de
Centre for Biorobotics
http://www.ttu.ee/en/?id=52131