Here's the video from day 2 of testing my 3D / reversible prop code. I still have a minor bug to work out in the acro pitch leveling code, but what's working is working well!

- Afro 30A ESCs with SimonK (reversing/braking/complementary)

- RcTimer 9x4.7" CF props (doubled up for symmetry) 

- RcTimer BC3530-10 1400KV motors

- Rctimer 450 frame

- Adrucopter3D code (based on Arducopter 2.9.1b)

Here's a close up of the prop configuration:

This was the maiden flight of my 3D hacks to the Arducopter 2.9.1b code. So while my piloting sucked, I was pretty impressed that it actually worked!

The ESCs are Afro 30s with SimonK configured with COMP_PWM=1, MOTOR_BRAKE=1, BRAKE_SPEED=8 and of course RC_PULS_REVERSE=1 to allow reversing.

The props are actually two sets of carbon fiber props stacked on top of each other with one set upside down - another hack. This is far from ideal, but all I had on hand at the time. Normal props are far too inefficient in reverse and I actually don't have any I can flatten out (yet). I can't wait until 10" 3D props are common!

The code needed quite an overhaul to simply support negative throttle. On top of that, I added some delays when switching direction to make sure the motors stayed in sync when reversing direction. The final cherry was to have the acro mode self leveling mix switch the roll target to upside down when the throttle reversed. What you kind of see in the video is me just reversing thrust and letting the computer flip it over for the inverted hover.

Next up: learning how to fly and tune it!

I see a lot of work being done to increase the update rate getting to the motors of a quad for stability. The APM only updates the PWM value at 100hz (not ideal), so I got to thinking about how one could improve the performance without too much headache... (TODO: see if the 100hz loop could be increased to 200 or more...)

In this graph I modeled a couple of step responses being imposed on the motor - blue line is requested throttle, purple line is an idealized response from the motor ignoring load conditions. Basically, the motor responds to the step input with a certain time constant. 

The red and the green lines represent a calculated output pwm based on the requested "throttle in" and the modeled motor response. The goal being to shorten the step response time constant by boosting the pwm output during the initial rise. 

KA = constant for motor response estimate. 0.1 = slooooow response, 1.0 = instant. 

KB = Boost factor. Multiplied by the difference between the request and the response and added to the request. 

LIM = caps the amount added or subtracted from the request.

I coded this idea up, and have to say I'm please with the results. On a new quad I was playing with, I noticed that if I let it freefall for a while and then punched the throttle to hover, I'd get some wobbles. With this in place, you can hear the motors responding much quicker and get much more stability. Unfortunately, the SimonK firmware I have in the HK30A escs doesn't actively slow the props down. If it did, I think this mod would be even more effective. The next steps are to play with the Stability / Rate gains to see if there are improvements to be made there. 

Patch against 2.9.1b (I'm sure it looks like hell just pasted in, sorry)

diff --git a/ArduCopter/ArduCopter.pde b/ArduCopter/ArduCopter.pde
index 945b187..26009bf 100644
--- a/ArduCopter/ArduCopter.pde
+++ b/ArduCopter/ArduCopter.pde
@@ -1,6 +1,6 @@
/// -*- tab-width: 4; Mode: C++; c-basic-offset: 4; indent-tabs-mode: nil -*-

-#define THISFIRMWARE "ArduCopter V2.9.1b-Bob 2014-Mar-12"
+#define THISFIRMWARE "ArduCopter V2.9.1b-Bob 2014-Mar-14"
/*
* ArduCopter Version 2.9
* Lead author: Jason Short
diff --git a/libraries/AP_Motors/AP_Motors.cpp b/libraries/AP_Motors/AP_Motors.cpp
index 5a435ac..3c4876a 100644
--- a/libraries/AP_Motors/AP_Motors.cpp
+++ b/libraries/AP_Motors/AP_Motors.cpp
@@ -35,6 +35,24 @@ const AP_Param::GroupInfo AP_Motors::var_info[] PROGMEM = {
// @Range: 20 80
AP_GROUPINFO("TCRV_MAXPCT", 3, AP_Motors, _throttle_curve_max, THROTTLE_CURVE_MAX_THRUST),

+ // @Param: TBST_KA
+ // @DisplayName:
+ // @Description:
+ // @Range: 0 - 1.0
+ AP_GROUPINFO("TBST_KA", 4, AP_Motors, _throttle_boost_ka, THROTTLE_BOOST_KA),
+
+ // @Param: TBST_KB
+ // @DisplayName:
+ // @Description:
+ // @Range: 0 - 1.0
+ AP_GROUPINFO("TBST_KB", 5, AP_Motors, _throttle_boost_kb, THROTTLE_BOOST_KB),
+
+ // @Param: TBST_KB
+ // @DisplayName:
+ // @Description:
+ // @Range: 0 - 1000
+ AP_GROUPINFO("TBST_LIM", 6, AP_Motors, _throttle_boost_limit, THROTTLE_BOOST_LIM),
+
AP_GROUPEND
};

diff --git a/libraries/AP_Motors/AP_Motors.h b/libraries/AP_Motors/AP_Motors.h
index 18e7754..671f80f 100644
--- a/libraries/AP_Motors/AP_Motors.h
+++ b/libraries/AP_Motors/AP_Motors.h
@@ -50,6 +50,11 @@
#define THROTTLE_CURVE_MID_THRUST 52 // throttle which produces 1/2 the maximum thrust. expressed as a percentage of the full throttle range (i.e 0 ~ 100)
#define THROTTLE_CURVE_MAX_THRUST 93 // throttle which produces the maximum thrust. expressed as a percentage of the full throttle range (i.e 0 ~ 100)

+#define THROTTLE_BOOST_KA 1.0
+#define THROTTLE_BOOST_KB 0.0
+#define THROTTLE_BOOST_LIM 0
+
+
// bit mask for recording which limits we have reached when outputting to motors
#define AP_MOTOR_NO_LIMITS_REACHED 0x00
#define AP_MOTOR_ROLLPITCH_LIMIT 0x01
@@ -182,6 +187,10 @@ protected:
AP_Int8 _throttle_curve_mid; // throttle which produces 1/2 the maximum thrust. expressed as a percentage (i.e. 0 ~ 100 ) of the full throttle range
AP_Int8 _throttle_curve_max; // throttle which produces the maximum thrust. expressed as a percentage (i.e. 0 ~ 100 ) of the full throttle range
uint8_t _reached_limit; // bit mask to record which motor limits we hit (if any) during most recent output. Used to provide feedback to attitude controllers
+ AP_Float _throttle_boost_ka; // motor time constant (0.01 = very slow, 1 = instant response)
+ AP_Float _throttle_boost_kb; // boost factor, multiplied by the difference between the normalized motor speed estimate (based on ka) and the requested throttle
+ AP_Int16 _throttle_boost_limit; // max boost/cut to apply to the commanded throttle
+ int16_t _motor_v_estimate[AP_MOTORS_MAX_NUM_MOTORS];
};

#endif // AP_MOTORS
\ No newline at end of file
diff --git a/libraries/AP_Motors/AP_MotorsMatrix.cpp b/libraries/AP_Motors/AP_MotorsMatrix.cpp
index fff0a74..e6149f7 100644
--- a/libraries/AP_Motors/AP_MotorsMatrix.cpp
+++ b/libraries/AP_Motors/AP_MotorsMatrix.cpp
@@ -85,6 +85,8 @@ void AP_MotorsMatrix::output_min()
if( motor_enabled[i] ) {
motor_out[i] = _rc_throttle->radio_min;
_rc->OutputCh(_motor_to_channel_map[i], motor_out[i]);
+
+ _motor_v_estimate[i] = _rc_throttle->radio_min;
}
}
}
@@ -253,6 +255,17 @@ void AP_MotorsMatrix::output_armed()
}
}

+ // throttle booster, experimental. Try to get motors to the desired rpm faster
+ if(_throttle_boost_kb != 0)
+ {
+ for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
+ if( motor_enabled[i] ) {
+ motor_out[i] = motor_out[i] + constrain( ((motor_out[i] - _motor_v_estimate[i])*_throttle_boost_kb), -_throttle_boost_limit, _throttle_boost_limit);
+ _motor_v_estimate[i] = (_motor_v_estimate[i]*(1.0-_throttle_boost_ka)) + (motor_out[i] * _throttle_boost_ka);
+ }
+ }
+ }
+
// adjust for throttle curve
if( _throttle_curve_enabled ) {
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {

Here's what I can do for photos this late in the game. I really should have taken build photos before everything got covered up with electrical tape and zip ties ;) The craft is crude, but I'm really happy with how it flies with modded 2.9.1b firmware. I'm working on 3.0.1, but tonight's weather got in the way of my test flight.

Finally completed the 3dr mod on my 9x. Seems to link up instantly - no more waiting for mission planner to download parameters or the awkwardness of forwarding the mav data back out over bluetooth!

More details, as requested:

The stock 9x has the Throttle Cut and Aileron switches connected to a UART on the Atmega. These need to be re-routed to free up the UART for telemetry purposes. There are several posts out there on how to do it - this was the cleanest (from https://code.google.com/p/open9x/downloads/detail?name=9x_modifications_EN.pdf):

Since I have a smartieparts 9x programmer, I didn't have to worry about the connections going to the header on the left - just the two connections that are circled in red.I reused the resistors that came off the pads (Thanks to Rod for his fine soldering skills). Note that the connections are made from the bottom most resistor pads up to the resistors then they cross over and attach to the two free pads on the right. Keep in mind that once this mode is made, firmware is required that knows about the new locations.

After that, I installed the smartieparts programmer according to their installation instructions:

http://www.smartieparts.com/shop/index.php?main_page=page&id=9

With that in place, the extra UART is now availible on the TelemeterEZ port (two pin header, top row, left):

The 3dr air module conveniently runs at 5v, so I grabbed 5v and ground off the back PCB (you can just barely see the connections in the 2nd photo from the top above). 5v is in the middle, ground on either side of it.  

When installing, I connected power and ground to the 3dr module first (red and black wires on the cable that came with it). Fired up mission planner and when through the radio setup to load the correct settings into the module. Then I unplugged the usb radio for the PC (to make sure it didn't interfere) and powered up my quad - data stated flowing to the module in the 9x. This made it easy to identify which way to hook up the RX/TX lines to the TelemetryEZ port on the 9x Programmer board using my DSO Quad pocket scope.

Next time I open up the 9x, I'll grab photos of the actual connections. The OpenTx developers are currently working on adding Mavlink support - I was a little impatient and rolled my own, but I do intend on getting my code to them so they can merge all the best ideas. 

I should also add that I'm not 100% sure the radio module won't draw too much power... it probably makes sense to at least add a cap between the power and ground connections to help the regulator out. 

I built this guy out of PVC plumbing parts from Canadian tire and an old plastic food container:

30 deg V

10 x 4.5 propellers

D3530/14 1100kv Motors

30A HK ESCs (SimonK )

APM 2.5 brain with 915 Radio + GPS

(arducopter 2.9.1b modified to support my VTail mix)

4000mAh 40-80C nanotech battery (I like them for my Stampede 4x4)

all up weight is about 1500g (1760g with my 'trainer landing gear' shown above)

Hovers at 25A / 45% throttle and gets about 7 min flight time

I also added Mavlink support to my Turnigy 9x. Currently I forward mavlink data from my PC over bluetooth, but I hope to put a 3dr radio in place of the bluetooth to avoid the PC. The screen I added provides battery Amps / Volts / % Remaining (with warning beeps), flight mode, satellite fix / count / hdop and my favorite feature: distance from home and bearing offset to get home. 0° means fly forward to get home, 180° means fly backwards to get home - handy!

This was and continues to be a really fun project!