All Posts (11086)

Sort by

Testing the new mapping plane, MAV79

The 3rd plane to be added to my fleet of mappers. I took it for a mission and flew for 34 mins before landing, wonderfully stable slow flight characteristics, mission speed set at 10m/s though it will still perform well at 8m/s. Based on a Buffalo FX79 with a Pixhawk FC running the 3.3.0 firmware, equiped wit digital airspeed sensor and dual GPS sensors.  A range of sensors can be mounted from 12-24MP and a 12MP NIR sensor for NDVI work. The plane has a 680W motor with 12x6 folding props powered by 6000mah 4S batteries, for now a single battery comfortably provides over 40 minutes of flight time before its time to land which gives ample time to carry out flight missions to the current VLOS regulations in Ireland and the UK. Current developments are ongoing to have RTK GNSS incorporated onto the mapping planes to operate alongside my ground-side equipment, this will allow greater flexibility on those projects with difficult and extreme terrain. I have been carrying out commercial mapping and surveying for almost 2 years using fixed wing and multirotors, expanding the range of products that are available to my clients ranging from contractors to consultant engineering and environmental engineers in the UK and Ireland. Examples of some of my aerial mapping projects can be viewed on my Vimeo channel. 

My test area is situated at the foot of the famous Mountains of Mourne in Northern Ireland about 200 metres from my house, probably one of the most surveyed spots in the world!

MAV79 Landing from Aquila on Vimeo.

Read more…

BOZEMAN, Mont. -

Drones raced and crashed at the first annual Bridger Cup drone flying competition Saturday. It was all good fun but the technology that powers drones can make them a lot more than toys. Tech giants like Amazon are looking to drones to change the way they deliver to customers.

Big Sky UAV CEO, Pepper Petersen, said, "The reason Amazon wants to deliver packages with drones isn't because they like drones or because they think they're cool. It's because they can save billions of dollars and open up new markets that never existed before."

Pepper said it can be used to revolutionize different industries including construction, agriculture, emergency services and delivery services.

"Now with drones, traffic doesn't matter anymore, the roads dont matter anymore, as long as the airspace is clear. and  so i think in the next five years we're going to be seeing drones do jobs we never though they would do," said Petersen.

Story...

Read more…

Tilted Contra-Rotating System / Vertical Frame

Here you can see the first "flying" prototype of TCRS UAV.

PID tuning need to be refined to have a smoother flight and video.

The frame is 3D printed

Lipo 3S 4400mAh ;

Maxxprod CR2816 with 2 x 20 A controller ;

2x Futaba S3155 digital servos ;

Custom flight controller (see http://vgrsystem.free.fr) ;

2 props 9x7 ;

GOPRO Hero3 Black Edition ;

TBS BOSS 200mW 5.8Ghz video Tx ;

Below is a scheme of the system.

3689667128?profile=original

Read more…

A "wearable" UAV/FPV GCS with a twist

3689666781?profile=originalHere's an update to our handheld (or rather body worn) modular commercial/civilian UAV GCS, an all-in-one FPV system with a fully functional integrated PC telemetry head. This is something that we've had in the works for some time now, but only as a nice concept and some sketchy plans. Since one of our old clients has been pushing us hard for it, we had to put our CAD design into a tangible form eventually at the beginning of this year.

3689667052?profile=originalEven though our modular FPV tray system has become a very successful product with many working configurations and options, mounting a PC in it or over it was hardly a trivial task. We've been offering our own separate rugged telemetry system in the same Peli 1400 format as a companion to the belly box, so we knew what we were up against when we wanted to go even further.

3689667027?profile=originalOn the one hand, we were very much aware of the weight issues that may arise with the number of functions we need to include. The telemetry PC needs a complete support frame, a practical user interface, brings the necessary RF modem into the tray, and it may have a huge impact on total battery endurance, all resulting in added weight. This will also affect console balance, which is a very important factor with all types of belly boxes, because you need a stable tray to control both the direct RC and the PC GUI with precision.

3689667077?profile=originalOn the other hand, such a high number of electronic and RF systems in close proximity can cause havoc in both interoperability and interference. On top of the three obvious RC/AV/modem RF bands there are also some additional radio modules working in the PC. Of course WLAN, BT and NFC can easily be turned off in the field, but the embedded 3G modem is pretty handy for on-site live map services, and there's also a GPS in there. Depending on how you count them, we are talking about 10-12 different RF devices working close enough to bust each other's LNAs or end stages, even with their out-of-band or spurious emissions.

Anyway, the weight and balance issues never really cropped up, and we could use the same old folding brackets we made for the original control tray. We could mount the unit on the cross-over strap without a hitch. Even though the fold-up frame, its internal support and the PC adds some 700g to the set, you don't feel the difference, even after several hours of running around with it.

3689666982?profile=originalProbably because of careful module placement, adequate filtering and possibly some luck we haven't run into interference or loss of range issues, either. The current production sets are running with UHF LR RC, 868-915MHz telemetry and 5.8GHz AV in such a small unit, but we've also tested the same telemetry/AV combo with high power 2.4GHz RC without any issues.

The embedded tablet PC has a Z3740D Dual Atom CPU, 2GB RAM, 32-64GB RAM + micro SD card slot, 8" IPS Display with 1280 x 800 resolution and 10-point capacitive touchscreen, but it also works as a digitiser for even more accurate waypoint programming. It runs Windows 8.1, so Mission Planner and other standard GCS sw are there in your lap in full function.

In addition to the usual WLAN and BT modules, it also has a built in 3G-4G modem and both front facing and rear cameras. We've added a matte and low-reflectance (the two are not necessarily the same!) screen protector from 3M, to make the otherwise really high nit and high contrast panel even more sunlight readable. We have left both the SIM card and the micro SD card slots accessible, and we have also added a full size USB socket in the tray.

3689667048?profile=originalAdapting such a small piece of tablet hw has its own caveats, so, apart from toughening it up mechanically, we had to solve simultaneous OTG USB and charging, too. This is done through a single connector on the base for both the control tray electronics and the tablet. Despite the slightly higher power consumption of an embedded telemetry modem, battery endurance is still around five hours for the control tray. Since the tablet has its own battery, we have left it to its own devices for now, which will take it over the eight-hour mark easy, especially because there's an active powered USB hub for the peripherals.

3689666995?profile=originalFor those in favour of lighter IT packages, we also have the same station framework with an 8" Android telemetry control head. Not only is it much lighter and still totally waterproof, it's also a bit easier to operate via touchscreen than Win8.1 systems. As DroidPlanner and now Tower is getting more and more mature as an all-round GCS sw package, I think the future is bright for both platforms.

Thanks for your kind attention,

Azjeg


Find more photos like this on DIY Drones

Read more…

MTBF (Mean Time Before Failure) Analysis of the APM 2.6+

I am participating in the UAV Outback Challenge and wanted to calculate the MTBF of the APM 2.6+ for use as a standalone fail safe device. 

Time_between_failures.svg?width=700

MTBF is a standard measurement of failure rate in the Engineering world, it is normally represented in Hours, or failures per Million Hours. From Wikipedia: 

Mean time between failures (MTBF) is the predicted elapsed time between inherent failures of a system during operation. MTBF can be calculated as the arithmetic mean (average) time between failures of a system. The MTBF is typically part of a model that assumes the failed system is immediately repaired (mean time to repair, or MTTR), as a part of a renewal process. This is in contrast to the mean time to failure (MTTF), which measures average time to failures with the modeling assumption that the failed system is not repaired (infinite repair time).

Why do we care? 

MTBF is an important indicator of reliability in a system, the higher it is the less likely it is to fail.

How do you calculate it? 

I looked at the schematics for the APM 2.6+ and exported the Bill Of Materials (BOM), used this tool to calculate the MTBF of all the items according to the ANSI/VITA 51.1 standards assuming the operating temperature was 60°C (very Conservative), and that ther were the most unreliable class of devices (Consumer Grade), and for more specialized items (ICs and such) I looked them up on the manufactures website (here is an example, the 3.3v level shifter for the MPU).

3689666947?profile=original

After finding all these values I input them all into a spreadsheet, and classified them by Subsystem, and if the item was critical for that subsystems operation. (For example LEDs are critical to the LED subsystem, but not critical to the USB UART subsystem)

I then took all the components in every subsystem that were critical and totaled up the MTBF (assum any faluare of any part would cause a total system failure, using the formula: total MTBF = 1/(1/1st MTBF + 1/2nd MTBF + 1/3rd MTBF ect...)) 

This gives the following MTBFs for the following subsystems:

MPU MTBF:876099.0559
3.3v Regulator MTBF:2097175.403
AT2560 MTBF:1738803.191
AT32-U2 MTBF:291897.2053
DataFlash MTBF:4334969.547
MUX MTBF:1116667.245
Pressure MTBF:680851.5715
PWM input MTBF:558709.4613
PWM output MTBF:558709.4613
Magneto MTBF:581071.3857

We can then use that data to total the MTBF for the entire APM to be 61664.5 Hours (7 Years!), however not every one of those systems are required to maintain level flight, as far as I am aware only the following subsystems are required to continue to fly, MPU, 3.3v Regulator, AT2560, and PWM Input/Output Giving us a MTBF of 173218.9 Hours (~20.7 Years!)

Take everything I have said here with a grain of salt, as I am not a professional, in addition most of these failure rates were calculated, and the calculations might be a little off, or the manufacture data might be overestimating the true lifetime of their products. I have attached the Excel sheet I have used to calculate these values in the hopes someone might spot some mistakes I have made or find it useful in the future.

Download the Spreadsheet

Read more…

Drone configurator : simulate your drone configuration

3689666701?profile=original

Today I'm proud to introduce you Drone Configurator.


I designed this tool to help people choose their drone parts by :

- Simulating their configuration and giving them easy to understand indicators like flight time, thrust to weight ratio, ...

- Comparing the prices of the parts from various stores


Drone-Configurator is an alternative to ecalc as it can simulate the drone behavior but it works a different way.

Instead of basing our simulation on motor specifications, we choose to use real life benchmarks to be as close as possible to the reality. 

Our tool is easy to use as you just have to select the parts you need from our database and check the results, no need to understand very technical data.

3689666923?profile=original



We already reference lots of parts to cover most of the users needs but everybody is free to propose new parts so we hope the databse will grow fast. Please ask us the parts you need :-)


Drone Configurator is already available in English, French and Deutsch, we are looking for volunteers to help us translate it in other languages, contact me if you want to make it available in your laguage. 


I hope you'll find Drone Configurator usefull, I put all my love on it :-)

As I told you, this is just the begining and we are already working on lots of new features to make your life easier...


Fell free to share it !

Thanks,

Gauthier
www.drone-configurator.com

Read more…
3D Robotics

3689666687?profile=original

3689666890?profile=original

From the Dronecode blog:

I'm thrilled to report on Dronecode's community growth and interest in the project. Dronecode is supported by 40+ member companies and continues to welcome new members. We are excited to count AutoModality, Aerotenna, Droidika, DroneDeploy, Falcon Unmanned, Hex Technologies (66Hex), Matternet, ProDrone, SBI Software, Skedans, Yin Yan Model Tech (EMAX) as our newest Silver members. 

Stanford University Aerospace Design Labs, OpenTX Project and Humanitarian UAV network (UAViators) have joined the project as Sponsored members. We look forward to working with our members and developer community to improve the Dronecode UAV platform and technology stack.

3689666760?profile=original

Come meet us and interact with project leaders at our first Eurpean event, co-located with Linux Conn and Embedded linux Conference, in Dublin Ireland. Dronecode will be hosting a developer workshop, that will allow ​​participants ​​to ​​get hands on experience ​using ​​the ​​Dronecode ​​technology ​​stack. This workshop will be led by Lorenz Meier, PX4 Project lead and Tully Foote Platform Manager for ROS, October 5th, followed by a “Flight Day” on October 8th. This is a companion ​event ​for ​participants ​to ​show ​off ​their ​UAV ​capabilities ​and ​flight ​skills, ​network ​with ​industry ​insiders, ​in ​a ​safe ​controlled ​environment. This event will occur at an airfield in Newcastle, Ireland. We would like to invite you to participate: 

Register Today for Dublin, Ireland! 

Dronecode project participated in the Interdrone Conference, in Las Vegas last week to overwhelming interest and attention from the InterDrone community. Our sessions were very well attended; not an empty seat in the house! It was exciting to see the range of products and services on offer at the Expo, that were built on the Dronecode stack. I'd like to give a special thanks to our team including Craig Elder, Tom Pittenger and Jamie Machuca for representing Dronecode at Interdrone. 

20150909_132706.jpg?width=700

If you are using Dronecode technologies, we'd like to hear from you and would very much appreciate it if you share that fact. Not only will you be helping spread the word, you will be complying with some of the requirements under the open source licenses of the software projects. We would be happy to help you ensure license compliance. We would be happy to help you ensure license compliance.

Read more…
100KM

img_5386.jpg?w=300&h=273

Team West Coast UAV achieved one of our major milestones during testing on the weekend, controlling multiple UAVs through a multi-point comms network suitable for the 2016 Outback Challenge. 

One of the main challenges for our mission will be establishing reliable communications between our ground station and the retrieval aircraft when it lands at a distance of over 10 km away. To solve this we will keep our support aircraft flying in the air and use this to relay the telemetry from the ground station to the retrieval aircraft on the ground.

img_5400.jpg?w=269&h=300

On the weekend we successfully demonstrated the relay concept in the field using a 1W 900 Mhz radio link between the ground station and the support aircraft (Ben’s X-UAV Talon), and then relayed to the second telemetry link to the retrieval aircraft (Steve’s Crash Test Hobby Reaper) using a 25mW 433 Mhz radio link. Both aircraft were fully controllable in autonomous flight. The retrieval aircraft was flown to a distance of 700m from the support aircraft and still maintained a reliable link.

To read more see the full blog post at our website:

http://westcoastuav.org/2015/09/15/major-milestone-comms-network-controls-multiple-uavs/

Read more…

The future of the Micro Drone

3689666861?profile=originalI see a very exciting future for the micro drone! Say the size and weight of this Hobby King Q-Bot quadcopter. The reason being these small drones are far quieter and offer far less danger to people, aircraft, cars, motorcycles, children and even pets!

I see a world of useful and safe personal drones with all the features of arducopter and then some that everyone can enjoy safely! I see a lot of fun being had with micro drones WITHOUT any regulations needed.

I'm willing to bet this is the true future of the drone revolution! The micro drone!

Sure I see what a lot of people want to do commercially with larger drones, but the true future of the personal drone must be the micro drone!

Have you ever flown a Q-Bot? The flight times are actually great! They are a heck of a lot of fun too. All I'm saying really is I'd like to see more focus on the tiny drone with no more weight than the Q-Bot. Sure I see a lot of small drones but anything that weighs more than a Q-Bot is going to be just a little bit too much momentum.

The future of the personal drone is without a doubt the micro drone and nearly everyone will have one of these.

Just pull the back off your cellphone and throw it in the air it's a micro drone!

 

Read more…

UgCS server API

3689666832?profile=original
We've been asked many times to offer an API for UgCS server to open integration with additional devices and systems such as antenna trackers, security systems and ATC.
Finally it's done and published.
You can find it here:
https://github.com/UgCS/ucs-java-client

You will also find 2 examples, the first one showing how to get telemetry, the other one demonstrating the creation of a flight path, uploading it and executing it.

The usefulness of UgCS comes from the fact that your code will be working with all types of drones and autopilots supported in UgCS. And there are quite a few of them already:

- 3DR APM

- 3DR Pixhawk

- Mikrokopter

- Parrot ArDrone

- Parrot Bebop (will be available in UgCS 2.7)

- DJI Phantom 2

- DJI Phantom 2 Vision+

- DJI Wookong-M

- DJI A2

- DJI Naza-M V2

- DJI Phantom 3 (will be available in UgCS 2.6 very soon)

- DJI Inspire 1 (in UgCS 2.6)

- Microdrones (including the "new" flight controller version)

- LM Kestrel (will be available in UgCS 2.7)

- Micropilot (will be available in UgCS 2.7)

The API will work starting from UgCS 2.6. Early adopters can request UgCS 2.6 beta.
Have a good time coding and don't forget to test the code on an emulator before flying a real vehicle.

Safe flights,
UgCS Team

Read more…
3D Robotics

ROS support for Parrot Bebop

3689666749?profile=original

More synergy between Dronecode members! (in this case Parrot, which makes the Bebop, and the Open Source Robotics Foundation, which makes the Robot Operating System, ROS). From the ROS blog:
I would like to announce the release of "bebop_autonomy" package: ROS driver for Parrot Bebop Drone [1].
This driver is based on Parrot's official ARDroneSDK3 [2]. As of this release, it provides interfaces for piloting the drone, subscribing to its camera and on-board sensory data as well as tweaking its configuration.
Happy flying!
Mani Monajjemi
Read more…
Moderator

nigelwilsonemirates.jpg

This chap got off lightly I thought with the amount he was fined, much less than a flyaway that landed in a nuclear sub base. Its not the first prosecution in the UK as many outlets are touting, but the first of this kind.

The fellow does now have a criminal record. It also means the police in the UK have a case to look towards when prosecuting others based on YouTube videos.

As an aside my brother was at one of the matches and called me to say he could see the chap flying, he was plainly not staying out of the way.

A man has admitted illegally flying drones over professional football matches and London landmarks.

Nigel Wilson admitted nine breaches of taking video over football grounds and tourist attractions last year.

Wilson, from Bingham, Nottinghamshire, was originally accused of 17 breaches of the Air Navigation Order but some charges were dropped due to insufficient evidence.

He was fined £1,800 at Westminster Magistrates’ Court.

Wilson, 42, was accused by Scotland Yard of flying the aircraft unmanned and “failing to maintain direct visual contact”.

The charges he admitted included flying the drone on:

  • September 16 - Liverpool v Ludogorets FC at Anfield
  • September 23 - Derby County v Reading at iPro Stadium, Derby
  • September 27 - Palace of Westminster, London
  • September 27 - Arsenal v Tottenham Hotspur at Emirates Stadium, London
  • October 9 - Queen Victoria Memorial outside Buckingham Palace and north bank of the River Thames in London
  • October 18 - Manchester City v Tottenham Hotspur at Etihad Stadium, Manchester

This was the first case of a person being prosecuted by the Crown Prosecution Service for using drones after a police-led operation.

The court heard police horses were startled by Wilson’s device as it flew over a Champions League group stage game between Liverpool and Bulgarian visitors Ludogorets at Anfield.

He was also twice arrested in London and had his drones confiscated.

Ignored safety warnings

District Judge Quentin Purdy told Wilson, a security guard, he had put the public at risk by flying the drones over busy, built-up areas.

He said: “At each and every one of these places an accident could have occurred simply by a gust of wind or something of that nature taking it out of your control.

“In each and every case you knew what you were doing. Several times you were warned by police, who seized drones from you, and on numerous occasions by people posting on your YouTube channel.

“It was the height of arrogance in terms of public safety.”

Wilson, a father-of-two, shot the videos using three unmanned aircraft and uploaded them to his YouTube channel, PV2+ Adventures.

Susan Bryant, defending, described Wilson as a “hobbyist”, adding: “It was something he put a great amount of time into in terms of improving his skill.”

http://www.bbc.com/news/uk-england-nottinghamshire-34256680

Read more…

thumb1024_7059_bm2015_f7_front.jpg?width=720

After lots of work (too much to detail here, but it was months of building and testing planes and autopilots, as well as FPV gear), I have 2 summary videos (day and night), some screenshots, and the longer raw videos if you'd like to see them:


http://marc.merlins.org/perso/rc/post_2015-09-01_Flights-over-Burning-Man_-and-the-current-unfortunate-BMorg-and-FAA-policies.html

thumb1024_8065_bm2015_f8n_front.jpg?width=720

thumb720_200_BFG_OSD_Night.jpg?width=720

Read more…
3D Robotics

Let Skynet Become Self-Aware!

3689666587?profile=original

Here's a crosspost of my article this morning in Hackaday. We'll see how many people get the Terminator joke. 

Not so long ago, it was hard to fly. Forget actual manned aircraft and pilots licenses; even flying model aircraft required hours of practice, often under the tutelage of a master at a flying field. But along with that training came an education in the rules of safe flight, including flying at a designated airfield and watching out for obstacles.

We accidentally messed that up. We in the drone industry made aircraft super easy to fly — perhaps too easy to fly. Thanks to smart autopilots and GPS, you can open a box, download an app and press “take off”. The copter will dutifully rise into the air and wait there for further instructions — no skill required. And it will do this even if you happen to be in an NFL football stadium in the middle of a big game. Or near an airport. Or in the midst of a forest fire.

The problem is that along with taking training out of the process of flying a drone, we inadvertently also took out the education process of learning about safe and responsible flight. Sure, we drone manufacturers include all sorts of warning and advisories in our instructions manual (which people don’t read) and our apps (which they swipe past), and companies such as DJI and my own 3DR include basic “geofencing” restrictions to try to keep operators below 400 feet and within “visual line of sight”. But it’s not enough.

Every day there are more reports of drone operators getting past these restrictions and flying near jetliners, crashing into stadiums, and interfering with first responders. So far it hasn’t ended in tragedy, but the way things are going it eventually will. And in the meantime, it’s making drones increasingly controversial and even feared. I call this epidemic of (mostly inadvertent) bad behavior “mass jackassery”. As drones go mass market, the odds of people doing dumb things with them reach the singularity of certainty.

We’ve got to do something about this before governments do it for us, with restrictions that catch the many good uses of drones in the crossfire. The reality is that most drone operators who get in trouble aren’t malicious and may not even know that what they’re doing is irresponsible or even illegal. Who can blame them? It’s devilishly hard to understand the patchwork quilt of federal, state and local regulations and guidelines, which change by the day and even the hour based on “airspace deconfliction” rules and FAA alerts written for licensed pilots and air traffic control. Many drone owners don’t even know that such rules exist.

Drones Themselves Should Know Rules of Each Area

Fortunately, they don’t have to. Our drones can be even smarter — smart enough to know where they should and shouldn’t fly. Because modern drones are connected to phones, they’re also connected to the cloud. Every time you open their app, that app can check online to find appropriate rules for flight where you are, right then and there.

Here’s how it works. The app sends four data fields to a cloud service: Who (operator identifier), What (aircraft identifier), Where (GPS and altitude position) and When (either right now or a scheduled time in the case of autonomous missions). The cloud service then returns a “red light” (flight not allowed), a “green light” (flight allowed, with basic restrictions such as a 400 feet altitude ceiling), or “yellow light” (additional restrictions or warnings, which can be explained to the operator in context and at the point of use).

image01

Right now industry groups such as the Dronecode Foundation, the Small UAV Coalition (I help lead both of them, but this essay just reflects my own personal views) and individual manufacturers such as 3DR and DJI are working on these “safe flight” standards and APIs. Meanwhile, a number of companies such as Airmap and Skyward are building the cloud services to provide the up-to-date third-party data layer that any manufacturer can use. It will start with static no-fly zone data such as proximity to airports, US national parks and other banned airspace such as Washington DC. But it will quickly add dynamic data, too, such as forest fires, public events, and proximity to other aircraft.

(For more on this, you can read a white paper from one of the Dronecode working groups here and higher level description here.)

There’s Always a Catch

Of course, this system isn’t perfect. It’s only as good as the data it uses, which is still pretty patchy worldwide, and the ways that the manufacturers implement those restrictions. Some drone makers may choose to treat any area five miles from an airport as a hard ban and prohibit all flight in that zone, even at the cost of furious customers who had no idea they were five miles from an airport when they bought that toy at Wal-mart (nor do they think it should matter, since it’s just a “toy”). Other manufacturers may choose to make a more graduated restriction for the sake of user friendliness, adding a level of nuance that is not in the FAA regulation. They might ban, say, flight one mile from an airport, but only limit flight beyond that to something like 150ft of altitude (essentially backyard-level flying).

That’s a reasonable first step. But the ultimate safe flight system would go a lot further. It would essentially extend the international air traffic control system to millions of aircraft (there are already a million consumer drones in the air) flown by everything from children to Amazon. The only way to do that is to let the drones regulate themselves (yes, let Skynet become self-aware).

Peer-to-peer Air Traffic Control

There’s a precedent for such peer-to-peer air traffic control: WiFI. Back in the 1980s, the FCC released spectrum in the 2.4 Ghz band for unlicensed use. A decade later, the first 802.11 standards for Wifi were released, which was based on some principles that have application to drones, too.

  1. The airspace used is not otherwise occupied by commercial operators
  2. The potential for harm is low (in the case of WiFi, low transmission power. In the case of drones, low kinetic energy due to the weight restrictions of the “micro” category)
  3. The technology has the capability to self-”deconflict” the airspace by observing what else is using it and picking a channel/path that avoids collisions.

That “open spectrum” sandbox that the FCC created also created a massive new industry around WiFi. It put wireless in the hands of everyone and routed around the previous monopoly owners of the spectrum, cellphone carriers and media companies. The rest was history.

We can do the same thing with drones. Let’s create an innovation “sandbox” with de minimus regulatory barriers for small UAVs flying within very constrained environments. The parameters of the sandbox could be almost anything, as long as they’re clear, but it should be kinetic energy and range based (a limit of 2kg and 20m/s at 100m altitude and 1,000m range within visual line of sight would be a good starting point).

As in the case of open spectrum, in relatively low risk applications, such as micro-drones, technology can be allowed to “self-deconflict the airspace” without the need for monopoly exclusions such as exclusive licences or regulatory permits. How? By letting the drones report their position using the same cellphone networks they used to get permission to fly in the first place. The FAA already has a standard for this, called ADS-B, which is based on transponders in each aircraft reporting their position. But those transponders are expensive and unnecessary for small drones, which already know their position and are connected to the cloud. Instead, they can use “virtual ADS-B” to report their position via their cell network connections, and that data can be injected into the same cloud data services they used to check if their flight was safe in the first place.

Once this works, we’ll have a revolution. What WiFi did the telecoms industry, autonomous, cloud-connected drones can do to the aerospace industry. We can occupy the skies, and do it safely. Technology can solve the problems it creates.


Read more…

Multiple Flying Robots on a Daily Basis

3689666498?profile=original

As a practicing DIY Drones member, I thought folks might like to see  some real world testing of open-source flying robots. No flashy, over-promised, marketing hype. No large corporate backed interests, just a motivated engineer, some great open-source UAV systems and many, many hours of time invested in building safer flying robots.

I've started to capture daily videos on Periscope as I continue to work on these system. The videos are only up for 24 hours, so if you're interested, you will need to consume them before they time out. I try to do at least one video a day focused on flying robots. My Periscope and Twitter handle is hooperfly@epmuav if folks are interested. I'll include a link to today's flights below. 

CLICK THIS LINK FOR FLYING ROBOTS

Read more…

thumb1024_103_BFG2600_Airframe.jpg?width=720

I had a hard time finding a replacement for my Multiplex Cularis, and thanks to suggestion from many (thanks) I settled for the Diamond 2500 which was out of stock, but replaced by the BFG2600 available from Hobbyking:

Build and pictures here:
http://marc.merlins.org/perso/rc/post_2015-08-15_BFG2600-FPV-build-with-Pixhawk-Ardupilot-3_3-_Diamond-2500-remake-from-Hobbyking_.html

thumb1024_111_BFG2600_Airframe.jpg?width=720

thumb720_612_BFG2600_OSD.jpg

Read more…

Boundary Layer considerations

Figure%2B1%2B-%2BLovely%2BHeidelberg%252C%2Bdeparting%2Bpoint%2Bof%2Bboundary%2Blayer.jpg

Figure 1 – Lovely Heidelberg. I've been there. Birthplace of the boundary layer

When a body moves through the air, its interaction with the surrounding air mass generates a region where the air conditions are different from the freestream conditions. This region is named boundary layer. In basic air data applications there is a need to make accurate freestream conditions measurements, so we're really concerned about boundary layers. Boundary layers have been studied since the very beginning of aerodynamics. In 1904 a twenty-nine-year-old Ludwig Prandtl laid down the groundwork for modern aerodynamics with a short boundary layer presentation in Heidelberg [1].

Let's visualize the boundary layer over a flat plate, refer to Figure 2. We have depicted a laminar air flow, with vectors highlighting the velocity profile. The air flowing near the wall is slower than the air far from the wall, so the local velocity \(u(y)\) is a function of the distance from wall \(y\). The boundary layer is defined as the region where the local velocity values \(u(y)\) are less or equal than the 99% value(or other reference value) of the freestream value \(u_{infty}\). The speed at the wall is zero.

figure%2B2.png

Figure 2. Laminar flow boundary layer velocity profile

Air is viscous so to move one air layer with respect to other is necessary to apply a force.  Let's consider the flow (Couette flow) between two parallel flat plates of area \(A\) at a distance \(y\), one fixed to the ground and the other free to move. The force \(F\) needed to maintain the speed \(u\) of the moving plate is \(F=\mu Au/y\). The newly introduced parameter \(\mu\) is the air dynamic viscosity, with SI unit of measurement the \(Pa \cdot s\). It is evident that energy is required to maintain a boundary layer of given characteristics between the two plates. 

Video 1 – Turbulent and laminar flow

IIn general, boundary layers are affected by the relative speed of the fluid, the fluid properties and body geometry; see the following video that visualizes an example of laminar and turbulent flow.

Figure%2B3-%2BVelocity%2Bprofile.png

Figure 3 - Boundary layer velocity profiles in CFD pipe

The simplest way to visualize a boundary layer is to run a CFD simulation of a tube. You can find a tutorial here. From the figure 3 it is evident that the boundary layer is present and changes its shape along the pipe, the boundary changes along the length of the pipe, so the flow is said to be developing along the longitudinal axis. Let's suppose we want to calculate the flowrate across the pipe measuring the speed of the fluid at a single point inside the pipe. Flowrate is the integral over time of the velocity across a fixed section multiplied by the fluid density (Eq 12.2). To reconstruct the velocity values on the whole integration section based on a single measurement we need to know the analytical expression of the velocity profile. In many cases, that information can be gathered from precedent research work. It is evident that if we use the only measured velocity value as mean speed, neglecting the boundary layer, then we get a wrong flowrate measurement value. 

Let's change the scenario and suppose that we want to know the true airspeed of a racing car, refer to figure 4. The issue here is that airspeed measured within the boundary layer is lower than the freestream airspeed. How far should our Pitot probe protrude from the car body to work properly? Visit this page for an analytical introductory approach.

Figure%2B4%2BPitot%2Brake%2Baaaf1pitottubearrayindex.jpg

Figure 4 – Pitot rake on a race car

At a glance to deal with a boundary layer we need to know

  • The boundary layer thickness
  • The boundary layer velocity distribution and flow status: turbulent, laminar or transitional?
  • Flow development patterns: where will the flow change from laminar to turbulent?

In our typical application we're dealing with a flying platform, where unfortunately the boundary layer characteristics change with the aircraft attitude and airspeed. For example the wing downwash affects all the posterior parts of the fuselage. The magnitude and pattern of the airflow are dependent on the angle of attack.

In the real world it is not trivial to find a position that is not affected by the aircraft attitude. To push the measurement performance further, CFD analysis, wind tunnel studies and in-flight calibration are needed.

Until now we focused our attention to the air velocity field, but the same definition of boundary layer can be used to define a temperature boundary layer. both boundary layers impact on basic air data measurements. 

In the next post we will go into detail with a numerical example.

Further readings 

[1] John D. Anderson Jr(2005), Ludwig Prandtl's Boundary Layer, December Physics Today 2005

Read more…
3D Robotics

Official Development Guides for 3DR Solo

3689666620?profile=original

We are very pleased to announce the launch of the official 3DR Development Guide for Solo. This is a huge first step in introducing developers to the 3DR platform and growing the Solo dev community! We are excited keep building out this resource and also encourage others to participate as well. As the Solo Development Guide continues evolving, so will the endless possibilities of different Solo applications.

 

http://dev.3dr.com/

 

The Solo Development Guide currently covers:

 

  • A general overview of how Solo works

  • How to Access and work with Solo's Linux distribution

  • How to Upload and run Python scripts, including DroneKit-Python

  • How to run services that run on boot

  • Process video as it’s being streamed to and from Solo

  • How to Troubleshoot Solo


Brought to you by the Solo Dev Team

Read more…