Blogs

Reporting to the Vice President (VP) of Sales and Marketing, the Editorial Director will set and guide the strategy and creation of all internal and external communications, website content, and public relations messages to consistently articulate the mission of 3D Robotics. 

I've just wrapped up a new design based upon a lot of ideas I stole found on this site.

I've posted full details of the build and more pictures on my website:

Composite Folding H-Quad

We begin the tour of Iris' guts by looking at the new 4-in-1 ESC/Power Module. Each ESC is rated at 20amps capacity and is running the SImonK firmware for enhanced response and stability. The onboard Power Module provides regulated power to the flight control board, in addition to voltage and current monitoring.

An aluminum heatsink is attached to the power handling transistors

This 4-in-1 represents an elimination of 110 grams when compared to four individual ESCs, Power Module, and Power Distribution Board.

Hello All,

A little ride in French Alps with my TBS Discovery in fpv.

My spec :
Naza + GPS
Kypom 4S 3300 mAH
ESC DJI 30A
Motor SunnySky 2212 980Kv
Propeller 10*5
ImmersionRC EzUHF Tx/RX
5.8GHz 600mW Tx
Gopro 3 Black edition

Enjoy !

Polak
 

Garmin jumps into the actions cam market with the VIRB.  Specs, video and details can be found HERE

I've been working on an accessory-cage based quadcopter design to have a modular way of adding and removing components. The intent is to avoid the rubber-band and tape method of attaching components to the airframe. The accessory cage is comprised of four vertically-oriented carbon tubes and is meant to hold everything but the motors. There's a 3D-printed stage for each component; the flight controller, battery, ESCs, etc. each sit in their own carriers that slip on and off and can be repositioned as one sees fit. I have a basic "starting point" CAD model for an accessory stage, and I modify it as needed for whatever component I want to add.

The design needs some refinement: I'm going to implement a better thermal break between the motors and the [low-melting temperature] PLA airframe. It also has underside LED lighting (not visible in the pictures) that I would like to make removable for wiring access in the next version. I designed and printed prop guards but haven't installed them because I don't want to mess with the aesthetic and add too much weight, so instead I have minimalist stainless spring-wire prop guards in mind for v2.

Once I'm really happy with it my hope is to upload the files to the Thingiverse for those with a 3D printer, if anyone is interested. I'll also include the "starting point" file for the accessory stages, as well as the Inventor part files (2009) for anyone with access to that program.

You'll note in the pics that the flight controller is simply supported in its stage, so I should also work out an isolation web for it (maybe something like a shock mount for those old-timey microphones).

I decided to embark on the scratch build journey after putting together a DJI f450 kit. I love that quadcopter, but it was time to do my own thing.

My purpose on this journey was to design something of my own, a design I could call my own and I wanted it to be a hexacopter. I mainly fly with the purpose of taking videos/photos and the hexa seemed like the perfect platform. As I looked around scratch-build posts, I saw lots of interesting stuff on quads and tris, but nothing much on hexas. I sat down with Sketchup, and after a couple of days I came up with the following design.

It is loosely inspired by H-quads, but the frame is much stiffer! The prop2prop distance is 55cm (I got this from the DJI F550, so it made sense to me at the time), and the grey discs represent what 10" props would look like on it. You will have noticed that the props are on the bottom, so this picture is missing the landing gear. Also, on the left side you can see the tray where the cameras will be located.

From there I started ordering the parts:

This was the list I came up with. With is missing from here... are the bullet connectors to solder onto the ESCs (more on this later), and most of the FPV equipment (except for the MinimOSD). From the list, I still don't have the moongel, and I am still missing the landing skid, they will be coming soon hopefully :).

Anyways, since the frame was going to be made out of wood, I needed to buy the wood, and have the tools for the job. Before doing anything, I made a small mockup, practically 1:1 scale to check that the cables reached, and that I hadn't missed anything obvious and to start thinking how things will be arranged.

Finally, last weekend I drove up to Cobourg to see my aunt and Larry. Larry has the tools (and skills and knew where to get what I needed) for cutting the wood into the shapes that I wanted.

So we started with some cutting large 3/4" slabs 70cm (this will be a mixture of metric and imperial... c'est la vie...)

Then we proceeded to further slice this into 1/2" slices:

And then it was time for sanding

At this point is when I started panicking because I noticed I was missing the bullet connectors for the ESCs, so 5 trips to the mall later and about 10 phone calls, I end up with this temporary solution:

These were used to nicely hug the ESCs cables, and the same was done for connecting the motors to the ESCs. This is not ideal, but I really wanted to fly to show my aunt and uncle what we had achieved.

By then, we had glued the frame together, and started thinking on how to get things connected. It got pretty late, so we had dinner and went to sleep.

Next morning, bright and early I started attaching things... this is version 0.1 BETA :)

You will notice that the motors are on top, which is not the final design, and of course it is missing the landing gear. The PCB is attached under the APM, but I will move it and I already have all the plans for better routing all the cables. Also, I really don't like using zip ties to hold the motors. Do you guys know where I can get square mounts?! The arms are 1/2" by 3/4" most of the ones I find online are round :(

Anyways, here is a video of the maiden, it needs PID tuning of course... but it freaking flew! I couldn't believe it!

https://www.youtube.com/watch?v=8dCJc5se_7c&feature=c4-overview&list=UUGhAP80QJf_o8_17gTVt0xg

I would like to thank my aunt and Larry that made this possible, and all of you guys that are always posting good information

P.S. If someone has built a hexa like this before... sorry!

We would like to present you our first artistic video about how to build a flone for flying a smartphone:

 
Sorry, there is only one sentence in the video and is in spanish, but don't worry finally the drone knows what to do ;)

I have made a test of a NEX5 brushless gimbal used on my X8 Arducopter platform.

The video is raw and has not been post-processed.

For the more technical among you:

-Arducopter APM2.5 platform, firmware V3.0.1

-2-axis (tilt/roll) Brushless gimbal for Sony NEX5 from altigator.com (it is in fact a (re)labeled RC timer aluminium gimbal), using white labeled GBM5010 brushless motors (150 turns, able to hold 500gr cameras) 

-Sony NEX5R with 16-50mm objective. This big sensor compact camera delivers 50 frames/sec video and 16 mios pixels pictures. It can be radio remote controlled through APM and a IR trigger (i used stratosnapper)

It is a second episode of the X8 series of Summer Flights in France and will soon be continued with a third...

I would like to introduce my APM2quadLEDshow, a frugal alternative to using an IO board for LED's with Arducopter3.X. In a nutshell, I took U4eake's famous showleds UserCode, eliminated the 50hz loop to keep AC3.X happy, ported it for APM2.x hardware, added GPS status, and formatted the patterns for quadcopters using ports AN3-7. Please refer to U4eake's well written blog for basic information on wiring, changing light patterns, etc:

http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A750391&xg_source=activity&page=8#comments

The only required hardware is a ULN2803 chip, and of course whatever LED's, limiting resistors, and harnesses you need to wire your LEDs to it. I have flight tested this code with Arducopter3.1dev, and there were no ill effects on looptime, even flying in auto modes. This code is licensed under GPLv3; so feel free to use, copy, and redistribute this code, as long as it remains available free to the public. I owe credit to:  U4eake, Rob_Lefebvre, Bill Sanford, and Max Levine... without their help I would still only be crashing, not sharing this code with the community.

Files:

apm2ledShow.zip

Software Setup :

For your convenience, I have provided an AC3.1dev hex file in the above zip, which was compiled with APM2ledShow, and configured quad-X. You may flash this hex using "custom code" MP. Nothing on a copter is truly "plug-n-play". So if you go this route, be sure to compare your configuration and make sure everything works for your copter before flight! ...and you may skip to "Hardware Setup" below.

For those more comfortable compiling their own hex, I have included all of the necessary files in "APM2ledShow.zip". Like U4eake's blog says, you must overwrite your UserCode.h and UserVariables.h files with the one's in my zipfile. Then you must make these changes to APM_Config.h

Add these lines:
#define SHOW_LEDS             1
#define MID_VOLTAGE      10.7
#define COPTER_LEDS           0                       //The rest of these items can be set in the MissionPlanner if you wish.
#define battery_EVENT      ENABLED             //My values are included just as an example, but all aircraft are unique.
#define LOW_VOLTAGE      10.5           //So your numbers are likely different. NEVER blindly copy someone else's parameters!
#define VOLT_DIV_RATIO      3.46
#define INPUT_VOLTAGE      5.05

Note the first 2 defines are required for compiling, the rest are accessible through the Planner. These voltages and dividers work for my quad... make sure your values match your copter. Also, you must uncomment these lines in APM_Config.h (remove the leading "//"):

#define USERHOOK_VARIABLES "UserVariables.h"
#define USERHOOK_INIT userhook_init();                      // for code to be run once at startup
#define USERHOOK_MEDIUMLOOP userhook_MediumLoop();        // for code to be run at 10hz

Hardware Setup:

U4eake's blog is already a well written resource; no need to reinvent the wheel. Just follow the diagrams posted in U4eake's blog, but instead of wiring your ULN2803 in to APM1, you wire it to APM2 ports AN3-7... arranging your LED sets like this:
     AN7   AN6   AN5   AN4   AN3    AN0-2       -APM2 Plug ID
     Fr/L   Fr/R   Rr/R   Rr/L   GPS    A,V,RSSI  -LED Arm Location (does NOT follow Arducopter esc numbering convention!!!)

Note that this code uses bitwise and/or to mask the sensor ports from bitshift operations. If you wire your rig different than shown above, you will have to make sure "legledmask" in UserVariables.h matches (read below).

Editing Flash Patterns:

I am not much of a programmer. So I feel a newb's pain when it comes to understanding/editing code. Therefore, I put lots of effort in to writing/commenting the code so almost anyone can read it get right to making successful modifications. Editing APM2ledShow patterns is a great way to get acquainted with Arduino, and learn about bitwise operations too. I hope this leads to users making/sharing their own creative patterns! ;)

Again we will refer to U4eake's blog for the basics. He points you to the Arduino bitmath playground... highly recommended reading if you plan on editing your ledshow. You should right away notice some differences in the byte format, and the port address. The latest APM Arduino and AC3 code requires us to use the format "0bXXXXXXXX" instead of "BXXXXXXXX". Also, we are using APM2 hardware, so we are working with DDRF/PORTF, rather than DDRK/PORTK. The code writes directly to port F with a bitmask. This means you can have fun with bitshift operations on the leg LEDs, without fear of switching your sensor ports high. The default reserves AN0-2 for sensors (A, V, and RSSI on my quad). If you wish to use a wiring configuration other than default, the bitmask is declared as "legledmask", in UserVariables.h. The GPS bit does not use masking because it only operates on the 4th bit "0b0000x000". So, do not bitshift "gpsbit" unless you know what you are doing. Same goes for the 2 low voltage warning patterns; use conditional "0bXXXX0000" operations there.

PostScript:

No more comments for now... I already mentioned this has been tested with auto modes on my rig... still no guarantees, YMMV...

Enjoy!

[update 10/11/2013

For AC3.1rc3 or higher, "battery_voltage1" was changed to "battery.voltage()". Updated compatible UserCode and Hex attached.

apm2ledShow-AC3_1rc3.zip

]

I wrote a feature for ArduPlane that allows the home position to be somewhere else than where the APM was started. This is useful for flight under "flying line" rules or if you want to ready your plane in one place and fly it from another.

The feature was requested and discussed in this thread and here. My modified code is here.

The original APM behavior: Home position is set to one of the first positions the GPS reports after powerup. Even if you desired another position as home. The position is written into waypoint 0 too, so you will see the home position by (re)loading the mission into MP.

Modified behavior: There is a new parameter STICKYHOME_RAD, in meters. If the GPS position is nearer than this from waypoint 0, home will be se to waypoint 0. Otherwise it will remain unchanged and the controls will wiggle 3 times. This allows one to set an alternative home position without risking a flyaway of more than STICKYHOME_RAD meters. In this version, I have removed the servo wiggling at normal startup because I find it unnecessary and it makes my planes rock'n'roll at gyro calibration. Wiggling = something was not as expected.

Waypoint 0 is only overwritten if it was previously undefined. Reading the mission, the waypoint 0 read is the one last written. Any reason to change that?

There are a few console messages too. It appears that not all get though because they come in a too rapid succession. See init_home() in commands.pde.

The home altitude may be quite inaccurate too, because GPS takes some time to get altitude right. If you fly with pure baro altimeter (ALT_MIX=1) and you use relative-altitude waypoints, you will not be affected. Funny enough, this is default. I fly in hilly terrain and need to check my missions carefully against Google Earth etc. and therefore need absolute altitude. I often get home altitudes that are 100s of feet off, potentially disastrous if not rejected.

To try solve that problem, the altitude of waypoint 0 is also used. If the horizontal distance to waypoint 0 was OK, the GPS altitude is compared to the waypoint 0 ditto. If off by less than STICKYHOME_MAD (Max Altitude Deviation), the altitude of waypoint 0 is used for home. Else, the controls will wiggle 5 times.

So all in all

No wiggles: Waypoint 0 was undefined at startup, or both position and altitude were within bounds of waypoint 0
3 wiggles: Position was not within bounds of waypoint 0. GPS position and altitude were used for home3 wiggles:
5 wiggles: Position was within bounds of waypoint 0 but not altitude. GPS altitude was used for home. Recommended action if using absolute altitude: Wait a few minutes, try reset APM.

For consideration: When reading the mission, should the EEPROM stored waypoint 0 be returned as waypoint 0, or should the actually used home position (which is the same if within bounds)?

If postion is OK but altitude is off, should the APM go into a wait loop until altitude is OK?

From Techcrunch:

An Indian startup, Social Drones, is using its home-grown arsenal of bi, quad, and octo-copters to survey the effects of a recent natural disaster which claimed 580 lives, and is planning to courier medicines and foods to isolated victims. Drones don’t have the best reputation on the subcontinent and in the Indian state of Uttarakhand, sandwiched between war-torn countries of Pakistan, Kashmir, and Nepal, villagers no doubt harbour suspicions of the remote-controlled flying beasts infamous for dropping bombs. Social Drones hopes to change that perception.

The startup has joined forces with ten other Indian startups to form the Rise Uttarakhand campaign, where entrepreneurs will build apps and use their products to assist with the recovery effort in Uttarakhand, which was devastated by floods and landslides on June 16 and 17. There are still 5,100 people missing, including 300 foreign nationals.

After the floods struck, Mane sent two of his staff and two of his $8,000 quadcopter drones to survey the damage from up to 300 metres in the air. These images and videos are being given to organisation Help India 2013, a group of over mountaineers delivering food, water, and medical supplies to over 200 villages. Mane said the drones, which are 100% Indian-made, are operating in the areas between Uttarkashi and Gangotri, where about 5,000 local villagers have been stranded in makeshift camps since the floods completely wiped out the local infrastructure, including the 100km road that connects the two towns.

“The government didn’t make any footage available to the public because they couldn’t capture it so we thought, let’s go film the disaster and the volunteers, who are the real heroes,” Mane said.

After seeing the mountaineers trek over 20 kilometres each day through the unstable mountainous terrain, Mane saw an opportunity to lighten the load by having his airforce deliver the goods. The four-blade quadcopters couldn’t navigate the disaster conditions when the floods first struck a month ago but it’s a different story now that the fierce conditions have subsided. After running some early tests he is confident of making the first deliveries starting from next Monday, and they’re also organising a crowdfunding campaign to raise money for medicines, fruits and even portable water purifiers.

“A month ago the disaster management was there and they were recovering people and finding people but right now the majority of that work has been completed,” Mane said. “However, there are still people in various camps scattered across Uttarakhand and there are no linkages or channels to connect them. There’s no co-ordination with the government, which is mainly repairing popular tourist regions.”

Mane believes drones are the answer,  and is working alongside Dutch weather forecasting firmAeolis, which is providing real-time satellite information to military and volunteers. Also Weekend Ventures recently organised hackathons in Mumbai, Bangalore, and Delhi, where one team developed a phone-based version of the Google person finder app.

“We think the aerial delivery would be the best option, as well as developing applications to co-ordinate all the volunteers. We’ve already designed those and are in talks with companies to deploy web and mobile apps to these areas.”

I made this video to show a typical easy set-up on a DJI Phantom but the concept is the same for any multirotor.

Since everybody seems to be sharing LiPo stories. I have one from March 17th when a 2200 Mah 3s burned my entire garage. Check this out!

From Signal magazine:

The Defense Advanced Research Projects Agency (DARPA) program is known as High-Assurance Cyber Military Systems, or HACMS. Kathleen Fisher, HACMS program manager, says the program is aiming to produce software that is “functionally correct and satisfying safety and security policies.

“It’s not just that you’re proving the absence of a particular bad property from the security perspective,” she explains. “You’re actually positively proving that the software has the correct behavior.”

Fisher points out that with unmanned systems, an attacker can reach the relevant software remotely. Until a few years ago, cyber-physical systems such as automobiles had their own built-in security because they were not networked. But, automobiles increasingly are likely to have network connections, especially those that automatically provide for emergency response in the event of an accident. “The fact that pretty much all of these systems are networked means that the kind of vulnerabilities we’ve seen on desktop and traditional computing systems for the past 20 to 30 years now carry over directly to these kinds of cyber-physical systems, such as vehicles,” she says.

...

One target platform is an ArduCopter, which Fisher describes as a hobbyist unmanned aerial vehicle. The code in this relatively small system is readily available, so developers should be able to replace the code completely. Developers already have built a domain-specific language called Ivory that would generate flight control types of code. Half of the original control system code has been replaced by the new high-assurance version—enough that the helicopter can be flown using this new code, she posits.

This effort is paired with a helicopter being produced by Boeing that can be manned or unmanned, so the ArduCopter’s architecture is being adjusted to match that of the Boeing helicopter. This will allow for easy transfer of the software developed for the ArduCopter to the Boeing craft. Fisher points out that the Boeing helicopter effort does have specific software replacement goals for each phase, unlike the other vehicles.

I submitted final revision to oshpark for a board run today

the rest of the parts should arrive this week for the batch in production

Here is a video of the prototype mockup:

The board consists of :

2x 10mm super bright 20ma red & blue led's
 1x 12mm 5v active 89db buzzer module
2x .5watt 330ohm resistors (or 220ohm)

It's also capable of taking smaller smd leds also as the pad/hole spacing matches most types (may require different resistors to correspond with led used)

I did some more flights on the weekend to test out my branch of Arducopter 3.0.1 -THdev and wanted to show what it's like from on-board the heli in a reasonably high-speed run.  This run used 12 waypoints to form a rectangular pattern with rounded corners around the flying field, trying to achieve a nice smooth flight path.  I still haven't been completely successful as it's a bit jerky.  This was using WP Acceleration of 200 cm/s/s, and WP Speed of 25 m/s, but this was not achieved on this flight.  It did hit 20 m/s, and I'm happy to see that it's very very smooth.  With settings of 20 m/s and 100 cm/s/s acceleration it's much smoother but takes too much room to accelerate. This was also using the Yaw Look Ahead mode which causes the yaw to automatically look into the direction of flight.  The flight ends with an RTL which causes the yaw to return to the original orientation on the final descent.

Overall, I'm very happy with the performance, but I really anxiously await the Spline Nav feature! :)

The heli itself is still a work in progress.  Obviously the camera vibration damping is completely unacceptable and I'm redesigning that.  But other than that, it's going well.  The Direct Drive Tail is brilliant, and really simplifies the mechanics.

I am getting about 12 minutes flight time, including a 3 lb payload (yes, I'm using steel blocks as ballast), and this is with a battery load smaller than a 700 typically has.  Normally they run 12S 5000 mAh, and I've only got 8S 5000 right now.  But I plan to run a total of 8S 10,000 which should give better than 20 minute flight times.  

Once I'm comfortable with the reliability, I'll be stretching it's legs on longer runs.  I'd like to have this capable of at least 100 km/h flight with a camera on-board.  What I envisage building is a compact high-speed aerial filming platform capable of chasing race cars, etc.  Ultimately I will build a completely custom frame but for now I'm just hacking on this 550 frame stretched to 700.

This is a summer flight video of my "Mr. Red" Arducopter, configured as an X8.

Although the arducopter X8 setup is the least efficient in terms of number of motors/lifting power ratio, it is a super stable platform for aerial photography and aerial filming.

For the more technical:

-APM 2.5 running v3.0.1

-Tiger motors 3110-17 (700Kv)

-3DR 20 amps ESCs

-Smaller props on top motors: 11x4,7

-Bigger props on bottom motors : 12x3,8

-Frame built based on 3DR, VulcanUAV and other home built/exotic parts

I will soon post a second episode showing filming results you can get with this platform together with a brushless gimbal embarking a NEX5 camera.

As some of you may have noticed at the recent SUSB Expo in San Francisco, we’ve been busy working on a brand-new, consumer-friendly quadcopter.  The day has finally come to officially take off the wraps and show it to you all.  Here it is: Iris.

3DR Iris provides the autonomous functionality you’ve come to know and love in APM:Copter with a next generation PX4-based 32-bit autopilot (UPDATE: this has now been announced, and is called Pixhawk) and an all-in-one housing.

Building on the existing 3DR family of multi-rotor vehicles, Iris is compact, ready-to-fly, and fully autonomous. Navigate from takeoff to landing with point-and-click mission planning and configurable GPS waypoints, all from your mobile device or computer. Iris supports the full set of features offered by APM:Copter, including loiter, altitude hold, return to launch, circle, follow me, acrobatic flying mode, and more. With a stylish, durable, and sleek body, Iris is designed with a wide angle between the front arms to provide a clear view for an on-board camera--add a GoPro Hero 3(R) to capture your favorite moments from a unique perspective.

Features:

• Multiple control options provide redundancy and flexibility: RC, computer, phone, tablet

• Built-in data radio for real-time mission monitoring, data-logging, and control

• Powerful cross-platform ground station/mission planning and analysis software that runs on Windows, OS X and Linux, providing simple point-and-click programming and configuration

• Mobile apps allow intuitive “draw a path” mission planning

• Picatinny rail mounting system integrated in the arms provides painless mounting for future accessories (stay tuned!)

• Camera options include a live video link with programmable on-screen-display, and will soon support a fully integrated stabilized camera gimbal with autopilot control

• GoPro(R) compatible camera mount

• Available with a 9-channel RC transmitter pre-programmed for the most popular flight modes.

• GPS waypoints allow for professional-grade mission capabilities, such as: mapping, scripted cinematography, scientific research, and other applications where repeatable flight plans are required

• Robust arms and feet produced from Zytel Nylon(R) for the ultimate in wear, abrasion and impact resistance over a wide temperature range. They are easily and inexpensively replaced if required.

• Auto takeoff and landing along with Return-To-Launchpoint command at the press of a button or under programmable failsafe conditions

• Follow Me function for the ultimate "selfies". In this mode, Iris will follow (at an adjustable distance) any ground station device equipped with a GPS antenna and one of our 3DR telemetry/control radios

• Geo Fencing provides a virtual box to keep your drone within a user-selectable space

• Failsafe programming options bring peace of mind in the event of lost control signal/GPS or low battery conditions

• External micro-USB port

• RGB LED for status and orientation

• Buzzer for audible status and warning messages

• Safety switch adds a second level of protection against inadvertent start-ups

• Open source flight code, ground station software and electronics are all freely distributed under standard open source licenses. This means that Iris' capabilities are always improving and expanding with a simple firmware update!

Specifications:

• Motor to motor dimension: 550 mm

• Height: 100 mm

• Weight (with battery): 1282 grams

• Average flight time: 9-14 minutes

• Standard battery: 11.1v 3.5Ah lithium polymer with XT-60 type connector, weight 262 grams

• Propellers: (2) 10 x 4.7 normal-rotation, (2) 10 x 4.7 reverse-rotation

• Motors: AC 2830, 850kv

• Telemetry/Control radios available in 915mHz or 433mHz

• PX4-based 32-bit autopilot with Cortex M4 processor

• 3DR uBlox GPS with integrated magnetometer

Iris is currently available in a developer release for experienced operators to participate in the ongoing development of this exciting new product. Iris developer pre-orders are available now from store.3drobotics.com and will ship September 16th. Operators not interested in development are encouraged to wait for the consumer release of Iris coming soon!

Official press release can be found here.

As wildfires grow in number and size, drones could drastically change the nature of the fight.

By Katie Lobosco  @KatieLobosco August 19, 2013

In their losing battle against wildfires, drones could be a firefighter's ace in the hole.

Wildfires have grown in number and size, but fighting them has remained an old-school game that sometimes relies on paper maps and gut feelings.

"We can get more information for less cost, and it doesn't put anyone in harm's way," said Sher Schranz, a project manager at National Oceanic and Atmospheric Administration who researches fire weather modeling.

Fighting wildfires is a tricky game, since the direction and intensity of the massive blazes can change in seconds. Drones can help in two ways: They can safely gather more information about fire conditions than is currently available, and they can send that information to firefighters on the ground quickly.

Related story: Cheap drones could save your life

Today, firefighters are often sent out with tablets and smartphones so they can be updated about conditions, but those devices don't help if Internet service is weak or non-existent -- which is likely, as wildfires typically rage in rural areas where rough terrain keeps firefighters out of signal range.

Drones can hover over dead zones, providing an Internet signal. That's something researchers are making a priority, said Tim Sexton, the program manager at the Wildland Fire Management Research Development and Applications Program.

Where Internet connections are available, great information about fires can be disseminated to firefighters. Internet-based tools can help calculate the risk of a fire reaching homes or other structures, and they can determine how fires may move, depending on the weather. Currently, firefighters hike up to a ridge where they can get an Internet connection, or they'll work with the local telecom company to set up portable cell towers.

But when those Web-based modeling systems aren't available, firefighters rely on "gut feelings" from those who knew the area well, Sexton said. Without an Internet connection, they have to rely on data they received that morning, which was likely gathered late the night before.

Information available to firefighters is often so out-of-date, because manned airplanes and helicopter flights that take pictures and infrared images to map the fire perimeter are costly and risky, so they only fly over a fire once or twice a day. 

Drones, on the other hand, are comparatively cheaper, and more than one can be launched at once. Schranz estimates that a drone can cost as little as $2,000 for an eight-hour flight -- the same price for just one hour of a manned flight.

"Drones can sit up there all day long, or for days," said Sexton.

Drones aren't quite ready to assist in fire suppression, since the fire community is still in the early stages of making sure the technology is applied effectively and safely, said Erin Darboven from the Department of Interior. Unmanned aerial systems are strictly regulated by the Federal Aviation Administration.

Fifty years ago, photos taken from a plane above would have to be dropped in a tube to firefighters below, said Sexton. The process is a lot more advanced today, but drones could be a tool that gives firefighters an edge up in the battle against wildfires.