Blogs

Hi all! In this video the first test of my new heavy CamLifter OktoKopter.
The specs:

- CamLifter Heavy OktoKopter - Carbon frame and landing gear by Klaus Peters (kopter4u.eu)
- Battery holder by Alessandro Parisi (AleBS)
- AltiGator A3536-LE Motors
- APC-E 13x6.5 Props
- HobbyKing 30A ESC (F30A) reflashed with "SimonK Firmware"
- AfroI2C converter
- Mikrokopter flight board
- 3DR Radio 900 MHz telemetry
- FC "hot swap adapter" by Marco Robustini
- 4S 5000 mhA 30C LiPo (x 2)

Using my "hot swap" adapter" I can remove the Mikrokopter board and install ArduCopter APM2 in just two minutes, without remove a single cable.

Bests,

-= Marco =-
(AC Dev Team)

Finally my x550 and APM2 quadcopter is complete! And I have successfully flown!. 

Right now I seem to have a bit of  yaw problem, as well as a trim/balance issue. Since the frame is not quite flat it can be hard to tell exactly what should be level, and when I yaw in a different direction, it seems to always return to original. I think I need to check my motor position perpendicularity and possibly PIDs. 

Hi All,

In the flight 31 of my VAnTri, I have had some problems that I didn't find yet in my system.

Fortunatly my cat is inspecting the damage, in order to find an explanation for the crash.

Here I post some photos of his work. If you need his services, contact me!

And a final tip: Why dictionaries are important in the hobby?

As most of you may or may not know, I've been a big proponent of using PPM Sum (aka CPPM) with the Ardupilot since I first figured out how to make it work.  The simplicity of just running a single wire from the Rx to the APM is very attractive.  It eliminates 7 possible failure modes (losing the wire connecting channels 2-8) which could result in loss of control.  There's only 1 wire to get right, but also one wire to get wrong.  Fortunately, the APM can handle complete loss of signal well, and if you set your failsafe to handle complete signal loss, all is good.

I was using this on my HK450GT FBL helicopter, along with a FrSky D8R-SP Rx. Again, as anybody who knows me is aware, I'm a big fan of FrSky radio equipment.  It is affordable, and high performance offering true diversity on the Rx, easy to use CPPM (just requires a jumper on two pins), the Rx is very tolerant of low voltage (it'll keep going LONG after the APM would have shut down, down below 3V).  And rebooting and reacquiring the Tx signal takes less than 1 second.

All of these features are superior to the big name brands, Futaba, Spektrum, etc.

And the telemetry features offered by FrSky is just the icing on the cake.  RSSI (signal strength), Rx voltage, external voltage (flight battery), and even the option for a telemetry hub with all kinds of goodies This is somewhat negated by using an APM, but still, you can put one of these on your Tx and have all the info right at your fingertips.

Anyway, back to my little 450 heli with a HUGE Rx mounted on it, the D8R-SP.

I discovered that FrSky offer a new Rx, the D4Fr which is a small, yet full-range Rx.  And while it only has 4 channels out, it can be configured to do 8-channel CPPM with the simple addition of a jumper! Brilliant, and there's no reason why any modern compact receiver shouldn't be able to do this.  This Rx does not have as many telemetry features as it's big brother.  It can only report RSSI and Rx Voltage, it does not have connectors for the telemetry hub or external voltage.  But that's fine, as the APM can be used to report voltage anyway.  So I ordered one and it arrived Friday.

I started working on setting it up, when the wheels started turning in my brain.  The "case" is just a flimsy plastic thing, almost useless anyway.  And I'm only going to have a single cable going from the Rx to the APM, and it's so small.  And the APM2 has those stand-off pins onto which the daughterboard is soldered.  And those pins are kinda long...  And I've got this piece of empty prototype board sitting around...

Pretty soon I had de-cased the Rx and stripped all the input pins off the APM2.

I soldered the proto-board to the daughter board standoffs, and then glued the Rx board onto the proto-board.  I soldered jumpers on both the Rx and APM2 in order to set both into CPPM mode.  And then I soldered a jumper wire for the CPPM signal, power and ground.  Done.

The complete unit is compact.  There's no wires to get in the way of whatever vibration-damping mount you are using.  There are no wires to come disconnected.  I suspect this setup is at least an order of magnitude more reliable than a standard 8-channel APM2 setup.

Even better, it's compact, and easy to move between vehicles.

If you don’t like to power down your Heli at every battery change, and losing your GPS fix... there is a solution.

Just install a parallel second battery connecter (can be a much smaller one), prepare an old battery with the matching connector and a Diode in the + wire as a backup battery.

(To charge the backup battery you have connect the charger behind the diode)

Before changing the main battery connect the backup to the 2.connecter, change the battery, disconnect the backup and go flying again without loss of GPS fix and so forth.

By the way I had a very successful first flight with my T-Rex450 Pro and APM2

in stabilize mode. Very stable Tail and Hover, unfortunately the weather turned bad I had to stop.

Will keep you posted.

I'm the captain for Team Awesome, the UAS team from Embry-Riddle Aeronautical University, Arizona Campus.  We're headed to the Small UAS competition in Pax River, MD in five days, and we're using an ArduPilot 2.0 equipped airplane. This will be our first year at the competition. We're using the ParkZone Radian powered glider airframe, and the GoPro Hero 2 camera.  

We want to extend a big thanks in advance to the developers of ArduPilot.  We've come a long way in our first year, and we couldn't have done it without you.  

I'll be posting updates from the competition, so stay tuned.  Questions are welcome!

Good news: HobbyKing is now the official commercial sponsor of the DIY Drones Multicopter Rodeo next Sunday in Boulder, CO after the Sparkfun AVC! They'll be providing prizes, including the cool Talon Hexacopter frame (shown) and gift certificates and t-shirts. 

Thanks to Sparkfun for the Multicopter Rodeo callout this week, too! Everyone is welcome to attend, whether they're participating, observing or just want to hang out with the DIY Drones team. 

Not necessarily practical (or quiet), but definitely unique. Found here. 

 Marcy 2 finally does the 1st step in flight: stabilized rotation on the ground, using the onboard camera & blob detection. Making the RPM slow enough for maximum efficiency makes it too unstable to take off without active control.

It took only 1 week for the super simple ESC to arrive from Hobbyking.  The way to deal with them is to break up an order into segments small enough to ship in 1 week.  Instead of 10 motors on the 4 week shipping plan, create 10 orders on the 1 week shipping plan.

  The evolution of optical targets continues.

It could be passively stable, with landing gear, higher RPM, & more weight.

For now, the lighting is provided by 150W CFL's.

 Next is the hard part: detecting position from the onboard camera in flight.  Exactly how to test it is the hard part.  Coning angle & RPM change depending on altitude & payload.

 In other news, there have been some ideas of going back to ground based vision for Marcy 2 & having a higher quality airborne camera just for viewing.  Blob detection might be good enough to get ground based vision to work in ambient light.

 The ground based camera is smaller than the ground based target & the payload is lighter.  2 cameras on the aircraft for navigation & aerial images are unlikely because of the CPU load.  It would take another chip to serialize the data from 1 camera.

 There's no way to envision 2 cameras with a single chip, but the ground based vision takes a lot more money.  The ground based camera needs the 2 servos & a lot more fabrication than the target & both options need a takeoff stand.

Aerial vision is having real problems with inconsistent light.  Takeoff happens on the ground, so the ground is covered in a shadow.  There are taller takeoff rods.  LEDs don't do white.  They either make everything blue or red.  Only CFL lights produce a real white which can differentiate between red & blue.

There's always requiring the user to fly in a well lit area & lighting the takeoff area with red LEDs.  Most interiors are very dim.  People keep their windows closed & use 60W lights, especially single people.

 The mighty flood fill algorithm from 1980's PC Paint makes another appearance in Marcy 2's blob detection algorithm. It's normally instantaneous with a 160x240 image, but here it has to flood fill hundreds of blob candidates in each image, then take the largest blob. That's very slow.  After much optimization, 25fps of 160x240 takes 10% of a 3.8Ghz processor.

The Marcy 2 algorithm separates a marker from a background with changing viewing angle & lots of noise. Here it's shown separating markers from a lion. The camera is configured to only capture hue & saturation, to reduce the JPEG compression load on the microcontroller.

There was a blob tracking demo in OpenCV, with undoubtedly the same algorithm, somewhere. The demo only seemed to show a difference algorithm with a static background. There wasn't any documentation for any other blob tracker, & 10MB is a bit large for a blob tracking library.

There is a camshift algorithm in OpenCV which might do a better job.  The algorithms have usually not been precise or reliable enough to fly something.  There's a big change going from a Willow Garage robot which takes 30 seconds to move an arm to an unstable aircraft which needs precise, reliable data 4 times a second to avoid crashing.  You also have to be under 25 to use OpenCV.

URB_ERROR resolved

So the mighty USB problem of 3 months was narrowed down to a toggle error, meaning a packet was dropped. No surprise, since it was always the 1st 64 bytes of an 802.11 frame that were missing.

The improvement after keeping the bus busy was because the packets were all multiples of 64 bytes, not the bandwidth.

The breakthrough was noticing the errors only came after packets which were even multiples of 64 bytes.  A hack to only flip the toggle bit after packets of odd multiples of 64 bytes fixed the great stm32f407  URB_ERROR problem.


It was a single line in USB_OTG_USBH_handle_hc_n_In_ISR:

       if(((pdev->host.XferCnt[num] + 64) / 64) % 2)
          pdev->host.hc[num].toggle_in ^= 1;


Ping then became 100% successful, manely limited by RF glitches.  No lockups anywhere, no URB errors, & the promise of full wifi with the microcontroller was finally realized until the next microcontroller comes out.

While simultaneous send & receive still isn't possible, it's not necessary for any of Marcy 2's requirements.

That was a lot of work & a waste of time.  The Wifi settings could have been changed with a much faster ground station protocol.  There's no desire to implement packet spanning in the http protocol.  There's just enough space in a single packet to handle all the configuration pages.

The USB limitations make it impossible to time out while waiting for an ACK, so TCP over wireless is really clunky & doesn't promote a lot of confidence in putting $100 of parts in the air.  The UDP protocol for flight control is bulletproof, but psychological impressions come from TCP.

It's yet another interface to worry about.  The web server only came up because it's the 1st place people think of for configuring the wifi parameters.

DNS & TCP need to be hidden features, enabled by a buried option in the ground station.  A jumper across 2 pins will be required for resetting to factory defaults.  A key for you web based wifi configuration coders: disable the motor until reboot.

The Marcy 2 router package is as complete as can be.  Up to 8 stations are supported.  They can't do anything besides ping, flight control, & the web based configuration.

You should be aware that EVERYONE is in a race to build the 1st personal flying droid.  The winner will happen when the 1st personal position system that actually works appears, setting all 500 of you UAV entrepreneurs off on 30 endless nights promoting your kickstarter accounts, ordering your sparkfun parts, & getting the thing working.

The leading candidates are now based on vision.  The radio, sonar, GPS, & lidar contenders all have problems.  1 thing you may not have thought of is for a personal droid, flying within 10ft of the user, battery power isn't always required.

If it's hovering near someone exercising or shooting video of a talking head in a defined space, it can be tethered.  Tethering gives an element of infinite loitering time that your inductive charging stations can't match.

Quad rotors still seem too expensive to penetrate the mass market.  Those 12x30mm brushless motors are never going to be produced in enough quantities to meet demand while those 7x16.5mm brushed motors don't last long enough. 

A lot of people wanted to know what these proximity passes they see in our videos look like unedited, from top to bottom. So we went through the archives and dug up some we haven't shown yet, and made a quick video. Hope you like it:

My Distributor tell's me that the Easy Star II is in there system ready for some back orders.

• Folding propeller for reduced drag in glider mode
• Protected pod motor mount
• Easily detachable tail plane for ease of transport
• Large internal space with ample room for high capacity LiPo packs

Updated and upgraded, the quick-to-build and easy-to-fly EasyStar II is sure to become one of your favorite models. Based on one of Hitec's most popular aircraft, the original EasyStar, this improved kit boasts larger internal space, more payload capability and optional ailerons. It is designed to accept a powerful brushless motor which makes it a versatile, durable aircraft sure to impress both the beginner and more advanced pilots. Its gentle gliding characteristics and ease of transport make the EasyStar II effortless hobby fun.

$99.99 Free Shipping From Us. :-)

Thanks Paul
Wavetech Rc

Great video of Rano Raraku 3D via Easter Island Statue Project [eisp.org]. DEM and Orthomosaic generation by DroneMapper.com using imagery from Trimble/Gatewing UAV. 140 Images, 30cm GSD final. Cloud processing time was around 1 hour. Animation in ArcScene by Kim Anh Hoang. 

Video 3D RR Flyby

The above image shows the outer quarry and certain Moai statue in 3D. 

You can download the dataset from the following URL: http://dronemapper.com/gatewing1

Enjoy!

I've been looking for a good flying tiny quad for indoor use, and had a chance to look at (but not fly) Chris's Ladybird.  I've been waiting for a sign as to whether or not to get it, and here it is.  I know other people here have been looking for a good quality small indoor quad, so I thought I would mention it here.

I'm interested in the included transmitter, which includes two-way telemetry (not supported by the Ladybird, as far as I can tell).  You can get it with either a Mode 1 or Mode 2 transmitter, or as a bind-and-fly if you already have a Walkera.

Ladybird with Mode 2 Tx

Ladybird with Mode 1 Tx

Ladybird BNF

"The AMA Executive Council has agreed that it may be time to revisit FPV. Many of our members have been forthcoming in offering constructive suggestions about what might be done to modify our current policy so that it is more reflective of what is occurring today in the field. These suggestions will be taken into consideration as we move ahead with the review.

Many prominent members of the FPV community have offered their help. We intend to take advantage of their background and expertise as well."

http://amablog.modelaircraft.org/blog/2012/06/07/the-growing-world-of-first-person-view-model-aviation/

I thought I would share a couple of photos of the quick connector I soldered on to my arducopter Sonar which incorporates the power filter I posted a while ago (Link).   I started experimenting with different sonars from MaxBotix and wanted a way to incorporate the passive filter and connector together.  Over time having everything wired up including the resistor in the +5v line seemed to eventually break with the cable moving / being unplugged from the APM.  If you look closely you can see I have the 10 ohm resistor going into the +5v on the Sonar board and the other end connects to the appropriate edge connector pin.  I find this setup very reliable when swapping out parts for testing.

Here are some other photos:

The above photo shows the 100uF Electrolytic mounted across the +5v and gnd.

Western Australia.  A mini tornado ripped through a the Perth suburb of Dianella today.  With all the streets blocked off by the Police, power poles and trees uprooted, the media contacted COPTERCAM to fly in and take photos and videos of the area.

More photos here:

http://www.flickr.com/photos/coptercam/sets/72157630071544992/with/7162430283/

Just small manned planes for now. Key quote:

"Asked if Google had any plans to use unmanned aerial drones to gather photos for its 3D cityscapes, McClendon said it was an interesting question, but noted that drones were still being evaluated by the Federal Aviation Administration.

“That’s a larger can of worms that we’re not going to get into here,” he said."

(via @drones)

From IEEE Spectrum:

One of the ways in which robots are just starting to get really useful is with hauling aerial cargo. Last year, the optionally-manned KMAX made its first autonomous cargo delivery in Afghanistan, and since it can fly as many missions as you have fuel to keep it going, it's definitely a safer and more efficient way to get supplies to troops, especially in dangerous areas.

To move cargo around, helicopters (autonomous or otherwise) often carry stuff slung beneath them on long ropes, and as you can probably imagine, said cargo often ends up doing all sorts of swinging about, especially if the helicopter that's carrying it has to maneuver. Researchers from the University of New Mexico have been developing algorithms that allow robots to compensate for motion-induced swinging of suspended loads, and testing them out on real live quadrotors.

Essentially, what the quadrotor is doing here is dynamically adjusting its trajectory to damp out the swinging motion of its cargo (think tacos). It's sort of like an upside-down version of pendulum balancing, with maybe a little bit of this insane hinged stick balancing thrown in for good measure. Next, the researchers plan to see if they can get their algorithms to work on platforms that are less balanced (and more realistic), which (they say) should be "an important step towards developing the next generation of autonomous aerial vehicles."

Trajectory Generation for Swing-Free Maneuvers of a Quadrotor with Suspended Payload: A Dynamic Programming Approach, by Ivana Palunko, Rafael Fierro, and Patricio Cruz from the University of New Mexico, was presented last month at the 2012 IEEE International Conference on Robotics and Automation in St. Paul, Minn.

[ MARHES ]

I built the AC SIm to do gain tuning and now AB testing of various control algorithms. I've made some significant strides in the control loops, so I though I would detail out how it was done.

There is very little code left over from AC 1 in the current code base. When I started AC 2, I used the v1 control loops and assumed they were good. (Everyone was very happy at the time with them.) I also had no real way to measure the performance of them.

A few months ago I started to get very suspicious that the old carryover code was causing a lot of the flight headaches I've been experiencing such as aggressive flight leading to a flip. Or slow, wobbly response in descents. Max was complaining that AC2 lacked "wings". That's not a lot to go on, but it is real feedback that something needed done.

I built the SIM specifically to tackle this type of problem and here is how it was used:

In the SIM a parameter was created called g.test. A checkbox toggles the value of this param and the boolean value is used to turn on or off chunks of code. This gives me a side-by-side comparison of the impact.

Suspect code:

Attitude.pde: get_stabilize_roll() and get_stabilize_pitch();

// limit the error we're feeding to the PID

target_angle            = constrain(target_angle, -2500, 2500);

This line limits the desired rates sent to the rate loop.  A before and after plot shows the performance gain when this line of code is disabled. The Initial state of the copter was roll left at 450° per second. The plot shows the roll angle going to -85°, then recover to 0. Removing that line improve the recovery time from 1.15s to .75s

Suspect code 2:

This is the quad suddenly rotating at 600°/s to the right.

I've increased the roll output limit  in rate_roll and you can see the recovery time to level has decreased  35% to .8 seconds to level from 1.24 seconds. The angle error significantly decreased as well.

 

Patch 3:

There is an iterm in the stabilization code that causes the copter to level out when the CG is off or a motor is out of balance. The problem is the iterm can drift around when flying because drag or a low CG can prevent a copter from holding an steep angle and cause us to be 1-2° off when going back to level. We only want this term to hold level, so I placed a limit on the iterm like this:

if(abs(ahrs.roll_sensor) < 500){

    angle_error  = constrain(angle_error, -500, 500);

    i_stab  = g.pi_stabilize_roll.get_i(angle_error, G_Dt);

}else{

    i_stab  = g.pi_stabilize_roll.get_integrator();

}

Here is the effect plotted on a copter that has a 3° lean to the right. The iterm ramps to 3°, but it moves a lot when flying around.

Here is the patched code:

Notice the iterm ramps up and doesn't really budge. That should really help in keeping the copter still in the air.

 

Patch 4:

Keeping the copter holding altitude while pitching hard was work OK, but not great. The copter tends to drift down. I got that piece of code from a description in Berkeley's STARMAC copter project. 

static int16_t get_angle_boost(int16_t value)

{

    float temp = cos_pitch_x * cos_roll_x;

    temp = 1.0 - constrain(temp, .5, 1.0);

    int16_t output = temp * value;

    return constrain(output, 0, 200);

}

I changed it to this:

static int16_t get_angle_boost()

{

    float temp = cos_pitch_x * cos_roll_x;

    temp = constrain(temp, .5, 1.0);

    return ((float)g.throttle_cruise / temp) - g.throttle_cruise;

}

This has the effect of maintaining perfect downward acceleration at all times. The reason this works is the throttle-cruise (say 500 out of 1000) is = to 9.81m/s/s of downward acceleration. We can use a linear mapping of throttle to acceleration to achieve the additional throttle necessary for the combined roll and pitch tilt.

Bonus 

The last example not is not a patch but a tuning example:

For a basic setup we've been using Rate_P of .14 and Rate_D of 0. Also a Rate dampener similar to the Wii project of .15 Many folks were OK with these gains, but the performance was meh in Max and Marco's experience.

Here is a copter at 45° returning to 0° with the current gains and no patches:

With Patches:

Notice the overshoot and the bell ringing. The frequency with the above with patches is lower and that's good.

Here is the comparison of the above, but with the optimum gains:

These gains are now the default gains:

rate_P of .18

rate_D of .004

stab_D of 0

Please try these gains in the simulator and raise and lower the rate_D term. I was pretty surprised to see how tied the Rate_P and Rate_D are to each other. They cannot be tuned independently. A rate_P of .18 and Rate_D of 0 will not fly well at all. It will fast wobble in the air quite a bit.

I hope this was interesting. The SIM is currently residing at www.jasonshort.com

Jason