I participated in a great Drone Journalism meetup at the Storify offices in San Francisco last night, with packed house of attendees. Other panelists were Matt Waite of the University of Nebraska Drone Journalism Lab, Tyler Brown of the Occucopter project, Jennifer Lynch of the EFF and Ryan Calo of Stanford University Law School. 

Jim Swanson also brought his big Mikrokopter octo (above), mostly to spin the props so people would know I was serious when I called multicopters "flying lawnmowers". (My point is that it's dangerous and illegal to fly these things over crowds, as some of the more naive drone journalism advocates want to do). 

The panelists described what was possible with drones today, but focused even more on safety, legality and practicality. You can read a Storify report on the evening here. 

Here's me with one of Tyler's quads.

Hey everyone,

Quick update regarding dronemapper.com. Big thanks to all the best test users who have been helping me work out plenty of bugs and also get certain data formats more reliable. TLOG processing is working and now using the correct log fields, for the best results we have found you should have a magnetometer installed. :) There are a couple of cool new features:

• SRTM3 DEM Data of your flight region, large and trimmed GeoTiffs are generated.
• 3D Mosaic Blending, 3D DEM and 3D Model generation. (roughly based on Andrew Hazelden's approach)
• Improved Ardu GPX/TLOG processing.
• Improved "blended" 2D mosaic generation. Lots of bug fixes!
• TLOG Processing via MAVLink Graph

Imagery Courtesy: Martin R.
Mikrokopter Platform: 43 Images, 25 Used in 3D Mode
 

Thanks to everyone involved.

Best,

JP

Want to play with the awesome Invensense MPU-6000/6050 sensor used by APM 2 but struggling with the fine-pitch surface mount form factor? Sparkfun has come to your rescue with this handy breakout board version of the 6050. They're a little expensive at $40 each, but it's a great chip and very much the future of aerial robotics. 

(BTW, the difference between the MPU-6000 and the MPU-6050 is that the first uses a SPI data interface and the second is I2C)

For the last six month we (my friend and I) have been working on the development of autopilot. We called it SmartAP - Smart Autopilot.

It's all started in October 2011, when I decided to try to build our own autopilot, designed using the latest components.
Firstly, we purchased evaluation boards for a desired microcontroller, we have chosen STM32F103, based on ARM Cortex M3. Then we started to build autopilot step by step-by-step from the scratch on the breadboard, creating preliminary version of the software.
A couple of month later we had been focused on the autopilot hardware. We made our own PCB design, ordered several PCBs and SMD electronic components to produce several boards for tests. The last step was placing components on PCBs and it was done two days ago (unfortunately, MPU-6050 is missed, due to some shipment delays, we are expecting it to be delivered next week).
Yesterday was the first power-on test and all works fine!

Here is the bottom view:

Now we are working on the first final version of the software to make maiden flight. Also we are thinking about implementing some interesting features, which no one of existing autopilots has today.

We don't know exactly about the future development of this project (we definitely continue to work on this), but if there will be a demand for this, we might establish mass production and start sales.

Here are some main features:
PCB size 60x40mm, (4 layers), weight 14g
72MHz STM32 ARM Cortex M3 microcontroller
6 PWM inputs, 6 PWM outputs
IMU - Invensense MPU-6050 (using internal DMP)
Magnetometer - HMC5883
Pressure sensor - BMP085 (I wanted to use MS5611, but it was very difficult to order it)
UART port for wireless telemetry connection (e.g. Xbee)
MicroSD card slot for flight data logging
GPS port
Sonar port
Airspeed sensor port

I'm very greatful to DIYDrones community and 3DRobotics company! A year of experience with ArduPilot Mega gave me an inspiration and good knowledge in this area, which made possible for me to build my own autopilot.

If you have any questions - feel free to ask them.

Kirill

The ArduIMU v3 is a very interesting little device for minimalists. For my own project, I needed a device that could keep the plane level, maintain heading/altitude and sometimes steer to a particular waypoint. The majority of the time, I intend to control the plane myself, but I need the autopilot to take over at certain times to allow me to perform some other minor tasks. This is a video showing a full 'hardware-in-the-loop' demonstration of the IMU with only the platform replaced by the flightgear simulator. Manual control is effected by a wii motion+, which is held in the angle that I want the plane to be. Pressing the "B" (actuator) button means I take over control manually, letting it go allows the imu to take over and maintain course/altitude.

The Ardu IMU v3 ticks all the boxes in terms of inputs, outputs, size and price. My requirements:

• Keep a plane level in a certain direction at a certain attitude when there is no overriding control input
• Fly home in failsafe conditions and land after x seconds.
• Send down telemetry of the entire sensor array, servo commands and specific autopilot messages at a frequency of at least 10Hz with a goal of 30 Hz.
• Very small form factor and at least one spi, i2c and analog bus free.
• I wanted to push the code complexity of navigation and autonomy from the plane back to the ground, where debugging and verification is easier, which also highly facilitates debugging, as everything can be connected to simulators. It's clear that I'm making the assumption that I can guarantee the stability and availability of a two-way datalink at a high bitrate.

Instead of a fully autonomous system, this project explores the requirements for a system where the pilot is kept closer in the loop and where the role of this single operator changes frequently during the flight. Piloting, navigation and mission execution are seen as three different concerns that are hierarchically associated. What this hopes to achieve is to smoothen out the cognitive consequences of changes in context and situation that occurs when operators switch between these roles and what is needed in terms of technology and displays to help the operator make that transition. The more fluid this transition is perceived to be, the better the system is perceived.

The other very interesting benefit is that, if the assumption of the datalink guarantee holds, the kind of applications that become possible are very interesting. This is especially the case in situations where a lot of data is available on the ground, which cannot be easily sent or stored on the platform (realtime data about ground movements, collaborative searches, etc. ). This paves the way for a rich augmented reality display, where positions of interest, movements of other mobile objects, home locations, antenna beam limits and landing tunnels can be visualized virtually, supporting the flight operations of the pilot. The assumption being that merging a symbolic, graphical display with actual video, instead of showing numbers and arrows that require interpretation is significantly better.

I personally foresee that it makes more sense to move back the navigation+piloting code from the ground to the plane eventually, but this is a great starting point for systems where the tasks for navigation and mission control could blend in more with the actual environment of the plane.

Thanks to our friends at Tacocopter, who decided to base their only slightly imaginary robotic food delivery service on the ArduCopter platform, we have now made the big time: The Colbert Report does a whole segment on ArduCopter-powered fictional food transport.

I've been struggling to understand how to get the APM failsafe working properly and have yet to find some clear instructions that a noob like I can follow. It suddenly dawned on me how to get it all setup.

Here is my normal zero throttle output:

Here it is when the radio is off:

The AR8000 can be taught what to do if it looses contact with the mothership. The default is to leave or move the throttle to zero. As you can see, zero is normal and not enough to invoke the APM failsafe. (see here for more info on the APM Failsafe: http://code.google.com/p/arducopter/wiki/AC2_Failsafe)

What you need to do is tell the AR8000 to go below zero when the radio is lost and here's how you do it:

1. Turn on the radio and go into servo setup.
2. Find the throttle travel setup (on the DX8 it's the first screen)
3. Scroll down to negative travel (Left hand 100%). Change that to as high as it'll go. 140% in my case.
4. Confirm in Mission Planner that throttle input is now around 920uS
5. Turn off radio and receiver.
6. Insert Bind plug into RX and turn on.
7. Remove bind plug from rx. Light should continue blinking.
8. Ensure throttle stick is down.
9. Turn on radio while holding down bind button. Radio should rebind.
10. Turn everything off.
11. Turn radio back on and change the throttle throw back to 100%
12. Turn on quad and connection with MP
13. Confirm that minimum throttle is back to around 1100.
14. Turn off radio and throttle should now drop to around 920uS (or whatever it was beforehand)
15. If not, start again.
16. Now go to parameters in MP
17. Find THR_FAILSAFE and set it to 1.
18. Find THR_FS_ACTION and set it to 2 (1 = continue on Auto mission, 2 is RTL)
19. Click on the write params.
20. Click on Refresh to ensure it wrote it.

What you have done is told the receiver that when you loose contact, this is the new throttle position. It is of course, way lower than normal range. The low value is enough to trigger the APM failsafe which will RTL and land.

This all works in theory for me and MP seems to agree, I'll be out testing it tomorrow but just wanted to get it all down on paper so to speak.

My money is on a few people buying the systems just for the video downlink and screen. 

Lets see how the first few review ones fly.

http://www.suasnews.com/2012/03/13932/ready-to-fly-first-person-view-aircraft/

Hi Everyone,

Maybe you remember, last week my 200mm size quadrocopter (MQ-200) was lifted a GoPro.
After outdoor flight under 15-20km wind conditions without any problem,  i designed MQ-202.
It is same size microquadro but including landing gears and more rigid than MQ-200.

MQ-202 flying with OpenLRS Multi board with MultiWii code. If you interesting, I just released the code in the MultiWii repository .
 

This weekend i will test Magnetometer and GPS functions(RTH and waypoints). 
I think these small size quads sufficient for some tasks (FPV patrol or taking video with gopro). We will try and learn their limits :)

Cheers

Melih

Last video from my retired MQ-200 :)
 

Gary Mortimer at sUAS News spotted this excellent post from the Center for Democracy and Technology that gives the timeline for the FAA rulemaking process on integrating commercial UAVs into the national airspace. Here's the part for non-government drones:

Rules for Non-Government Drones

Nov. 10, 2012: Development of a comprehensive plan
The Secretary must develop a “comprehensive plan” to integrate non-government drones into the national airspace system by Sep. 30, 2015. The plan is required to contain several elements, including recommendations on acceptable standards for operation, certification, and licensing of non-government drones. The recommendations in this plan will influence subsequent rulemakings. Sec. 332(a)(1)-(4).

Aug. 12, 2012: Early integration of "safe" drones
The Secretary must determine if certain types of drones (government and non-government) can operate in the national airspace before completion of the comprehensive plan, rulemakings, or guidance required elsewhere in P.L.112-95. The Secretary must base this determination on whether the drone can perform without hazard to the public or national security. The Secretary must develop rules to integrate these drones into the national airspace, though P.L.112-95 gives no deadline for these rules. Sec. 333(a)-(b).

Feb. 14, 2013: Deadline for the comprehensive plan
The Secretary must submit the final version of the comprehensive plan to Congress. Sec. 332(a)(4). The Secretary must also approve and publish a 5-year roadmap - to be updated annually - for phasing non-government drones into the national airspace. Sec. 332(a)(5).

Aug. 14, 2014: Final rule for non-government drones
The Secretary must publish a final rule that will allow small non-government drones to operate in the national airspace system. Sec. 332(b)(1).

Aug. 14, 2014: Proposed rule to implement the comprehensive plan
The Secretary must issue a notice of proposed rulemaking to implement the recommendations of the comprehensive plan. Sec. 332(b)(2).

Sep. 30, 2015: Integration of non-government drones
This is the target deadline for the completed implementation of the comprehensive plan to integrate non-government drones into the national airspace. Sec. 332(a)(3).

Dec. 14, 2015: Final rule to implement the comprehensive plan
The Secretary must issue the final rule to implement the comprehensive plan. Sec. 332(b)(2).

Very clever one this from Jimmy Prouty @Hanger 18, simple is always best.

Read more http://www.suasnews.com/2012/03/13827/maple-seed-recovery-method/

Photohigher have made a standalone camera gimbal stabilizer optimised to work with their AV130 and AV200 gimbals.

There are some retailers taking pre-orders.  Shipping expected in April.

http://shop.coptercam.com.au/Skyline-RSGS-p/skyline.htm

http://www.uavrotorking.com/

The nice X525 and X1 QuadCopter frames are cheap and light, perfect for beginner as they have suspension legs helping in the hard landings.  This frame also fold and is great for transportation.  More and more people are using it as basic platform and hack it and improve it.  

This new product is to specifically address the carbon fiber motor mount flex issues and stress fatigue failures. 

CNC machined from billet aluminum it is designed to adapt a large range of 28mm and 35mm motors.

These mounts are much stronger than the stock ones and will eliminate the common cracking and vibration issues. The nice bonus is that it's a direct replacement with no modifications necessary.

Designed and cut by Terry at http://smallpartscnc.com They are now on sale for Canadians in my store. 

http://www.canadadrones.com/X1-X525-Aluminum-Motor-Mount-Set-p/x1-motor-mount-set.htm

I know a lot of you did some similar plates but these looks way nicer and are quite lighter as excess aluminium is removed. 

Here is my own home made ones, soon to be replaced by these nice ones! 

Will post picture of them mounted on the Quad as soon as I get them! Should be 5-10 days. 

Dany

www.CanadaDrones.com

Ok, so the heading is a little misleading.  By UAV, Lockheed probably means Umanned Aquatic Vehicle.  They're planning to offer this UAV for sale in late 2012.  But, seriously, maybe we all need to get out of the air and into the water.  Is there such a thing as FSA (Federal Submarine Authority) or does Transport Canada have regulations for submarine vehicles?

Hobbyking just posted this altimeter to their site:

Altimeter is a stand-alone, small, light and convenient unit for recording altitude and temperature changes throughout your flight. Once you have finished flying, you simply plug the altimeter into your computer via the supplied USB interface and download all the recorded flight data which displays an Altitude/Temperature/time graph for each flight.

Specs:
Dimensions: 21x13x5mm
Weight: 1.3g
Connector: 1.25mm pin
Operating Voltage: 3.7~8.4v
Working Current: <7mA
Upload Interface: USB
Height Range: -500~9000m
Height Accuracy: 0.3m
Operating Temp Range: -20c~65c
Temperature Accuracy: 1c
Sampling Fequency: 1hz/2hz/4hz/8hz
Storage Capacity: 63h(1hz)

More information at Hobbyking: http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=22630;

Get ready for a lot of these sort of op-eds. Here's one in the LA Times from John Villasenor, a Brookings Institute fellow, who thinks the current FAA rules on RC have got to go. Extra points for anyone who can explain the logic of the bolded sentence below:

Although reasonable people can disagree on how long it would take terrorists to build or acquire weaponized drones that can be guided by video into a target, there's really no dispute that it is a question of when and not if. The day will come when such drones are available to almost anyone who wants them badly enough.

In fact, there is ample evidence that terrorist groups have already experimented with drones. As far back as the mid-1990s — practically ancient history in drone terms — the Japanese Aum Shinrikyo sect that carried out the sarin gas attack in the Tokyo subway reportedly considered drones. So too have Al Qaeda and the Colombian insurgent group FARC.

Nations with a record of close ties to terrorists are another concern. Iran unveiled a drone in August 2010 that President Mahmoud Ahmadinejad managed to describe as an "ambassador of death" and a "message of peace and friendship" in the same sentence.

So what can we do to reduce the risk? One good place to start is the "model aircraft" provision in the new aviation law, which allows hobbyists to operate drones weighing up to 55 pounds with essentially no governmental oversight. The law allows recreational drones to be operated in accordance with "community-based" safety guidelines established by a "nationwide community-based organization." The inclusion of this language was a lobbying victory for model airplane enthusiasts. But is it really in the broader national interest?

It is not. One of the hallmarks of an effective national antiterrorism policy is consistency. The hobbyist exception is glaringly inconsistent with our overall approach to antiterrorism. By what logic, for example, do we prevent airline passengers from taking 8-ounce plastic water bottles through security checkpoints, while permitting anyone who so desires to operate a 50-pound, video-guided drone, no questions asked?

The overwhelming majority of the people in the model airplane and drone hobbyist community would never consider carrying out a terrorist attack. Yet the same could be said for the overwhelming majority of airline passengers, all of whom are subject to the same rules about what can be taken through airport security checkpoints.

Given the realities of the world we live in, it doesn't seem unreasonable to require all civilian U.S. operators of drones capable of carrying a significant payload to obtain a license. A useful model can be found in fishing licenses, which provide an inexpensive, non-burdensome way for government agencies to know who is fishing.

A licensing program obviously wouldn't eliminate the threat of drone terrorism. After all, terrorists won't necessarily feel compelled to get a license. But the federal government has a legitimate national security interest in monitoring domestic drone use. Today, its ability to do so is inadequate. A licensing program would help plug a critical gap in the government's knowledge regarding who should — and shouldn't — be operating drones.

I just finished a long debugging session with Andrew Tridgell and he has discovered the cause of my yaw (and attitude) issues. In case you don't know Andrew Tridgell, he is the genius developer who made the the latest release fly so well with his DCM improvements.

I think the majority of people out there are experiencing this issue can fix the problem very easily.

"So, what is it?!?!"

It turns out that the automatic compass calibration code on the APM does not work so well. I suspect it is working even more poorly under 2.5 because of the improvements to the DCM, but that correlation has not been confirmed. Like most of the users out there, I have never given more than a moments thought to compass offsets because they have been set automatically for as long as I have been a user, but it turns out they have an enormous impact on the performance of one's copter.

First, what are compass offsets? The offsets are three values that account for the difference in the magnetic field of the earth and the magnetic field that your copter experiences due to interference created by the ESCs, motors, etc. So, the magnetic interference can't possible effect heading that much, right? Wrong. If you don't believe me take a look at this graph:

You can see that towards the beginning of the flight when I am not doing much, the red and green lines are not that far off. As the flight continues and I start using more throttle, they are way off. At about 5:20:20 my heading is off by about 250 degrees. That is massive!!!! So why does it change throughout the flight? The more throttle that is applied the more current is flowing through one's electronics which increases the magnetic interference. Normally this field offset is accounted for, but recently I suspect that some users have bad offsets like I did. My offsets were essentially 1,1,1 when they should have been -180,3,52. Check out the next graph which shows the effect throttle has on the magnetic field:

This is a log from another user, Marco Robustini. The green line shows the throttle and the red line shows the magnetic field. You can see that as the throttle increases, the magnetic field more than doubles.

So how do you fix it? There is a new feature in the latest Mission Planner that allows you to use a telemetry log to determine the offsets OR you can calibrate your compass in real time by holding and spinning your copter 360 degrees. It is highly recommended that you use the telemetry log method. The reason is that when you are holding your copter and spinning it, you are not accounting for the amount of mag interference from the motors (because they are hopefully not running :-D ). Follow these steps:

With Telemetry Log (recommended)

1. Connect to your copter via telemetry.

2. Take off and fly around for a few minutes like you would normally fly. At this point we are collecting data about the magnetic fields during flight.

3. Land and disarm.

4. Download the tlog from that flight. (Instructions here: http://code.google.com/p/arducopter/wiki/AC2_Logs)

5. Connect to your board

6. Goto the Configuration tab

7. Click on the Setup tab

8. Click on the Hardware tab in the popup

9. Click the "Calibrate" button

10. Click "No" when asked if you want to use live data.

11. Browse to the fresh tlog

12. Your offsets are now saved

Without Telemetry Log

1. Follow the above steps 1 through 9

2. Click "Yes" when asked to use Live Data

3. Rotate the copter 360 degrees

The calibration utility is leagues ahead of the automatic calibration on the board that most of us are relying on. Many thanks to Andrew Tridgell, Michael Oborne, and all the devs who had a hand in the compass calibration utility in the planner. There is some serious brain power behind these features we take for granted.

Andrew Tridgell is working on improving the automatic calibration routines that reside on the board based on the updated (and original) algorithms by Bill Premerlani, but for now the Mission Planner calibration is everyone's best bet for improved flight performance.

If you have any questions just leave a comment.

Thanks,
Adam

This was actually the first flights performed in the USA. We travel outside to a safe place and test and adjust our equipment, performing measurements and checking how the gear has survived air travel. Obviously it's a good opportunity to play around a bit among red rocks as well ... enjoy :)

Outdoor scenerio demo

From the Robot Operating System news:

Announcement from Johannes Meyer and Stefan Kohlbrecher of Team Hector Darmstadt to ros-users

We are happy to announce the hector_quadrotor stack. While impressive results have been demonstrated by different groups using real quadrotor UAVs and ROS in the past, to our knowledge so far there is no solution available for comprehensive simulation of quadrotor UAVs using ROS tools.

We hope to fill this gap with the hector_quadrotor stack. Using the packages provided, a quadrotor UAV can be simulated in gazebo, similar to other mobile robots. This makes it possible to record sensor data (LIDAR, RGB-D, Stereo..) and test planning and control approaches in simulation.

The stack currently contains the following packages:

• hector_quadrotor_urdf provides an URDF model of our quadrotor UAV. You can also define your own model and attach our sensors and controllers to it.
• hector_quadrotor_gazebo contains launch files for running gazebo and spawning quadrotors.
• hector_quadrotor_gazebo_plugins contains two UAV specific plugins: a simple controller that subscribes to a geometry_msgs/Twist topic and calculates the required forces and torques and a sensor plugin that simulates a barometric altimeter. Some more generic sensor plugins not specific to UAVs (IMU, Magnetic, GPS, Sonar) are provided by package hector_gazebo_plugins in the hector_gazebo stack.
• hector_quadrotor_teleop contains a node and launch files for controlling the quadrotor using a joystick or gamepad.
• hector_quadrotor_demo provides sample launch files that run the quadrotor simulation and hector_slam for indoor and outdoor scenarios.

As many users of real quadrotors can probably confirm, testing with the real thing can lead to broken hardware quickly in case something goes wrong. We hope our stack contributes to a reduction of the number of broken quadrotor UAVs in research labs around the world

We plan to convert the plugins for Gazebo 1.0.0 as soon as ROS fuerte is released.

Indoor simulation:

Operation Aphrodite

This is our first FPV and RC the granddaddy

After seeing the video in youtube i did a quick lookup on wiki

From Wikipedia, the free encyclopedia:

Aphrodite and Anvil were the World War II code names of United States Army Air Forces and United States Navy operations to use B-17 and PB4Y bombers as precision-guided munitions against bunkers such as those of Operation Crossbow.^[1]