Red Balloon Finder

How to build your own Quadcopter Autopilot / Flight Controller

Back to my home page
How to build your own Quadcopter Autopilot / Flight ControllerBy Dr Gareth Owen (drgowen@gmail.com)Fig 1: 3DR Quadcopter

Pseudovector

Physical examples of pseudovectors include magnetic field, torque, vorticity, and the angular momentum.

Each wheel of a car driving away from an observer has an angular momentum pseudovector pointing left. The same is true for the mirror image of the car.

Consider the pseudovector angular momentum L = r × p. Driving in a car, and looking forward, each of the wheels has an angular momentum vector pointing to the left. If the world is reflected in a mirror which switches the left and right side of the car, the "reflection" of this angular momentum "vector" (viewed as an ordinary vector) points to the right, but the actual angular momentum vector of the wheel (which is still turning forward in the reflection) still points to the left, corresponding to the extra minus sign in the reflection of a pseudovector.

The distinction between vectors and pseudovectors becomes important in understanding the effect of symmetry on the solution to physical systems. Consider an electrical current loop in the z = 0 plane that inside the loop generates a magnetic field oriented in the z direction. This system is symmetric (invariant) under mirror reflections through this plane, with the magnetic field unchanged by the reflection. But reflecting the magnetic field as a vector through that plane would be expected to reverse it; this expectation is corrected by realizing that the magnetic field is a pseudovector, with the extra sign flip leaving it unchanged.

http://www.altdev.co/2013/03/15/what-is-gimbal-lock-and-why-do-we-still-have-to-worry-about-it/

In linear algebra, an orthogonal matrix is a square matrix with real entries whose columns and rows are orthogonal unit vectors (i.e., orthonormal vectors), i.e.

In mathematics, a linear map (also called a linear mapping, linear transformation or, in some contexts, linear function) is a mapping V ↦ W between two modules (includingvector spaces) that preserves (in the sense defined below) the operations of addition and scalar multiplication. 

In mathematics, the orthogonal group of dimension n, denoted O(n), is the group of distance-preserving transformations of aEuclidean space of dimension n that preserve a fixed point, where the group operation is given by composing transformations. 

Equivalently, it is the group of n×n orthogonal matrices of a given dimension, where the group operation is given by matrix multiplication, and an orthogonal matrix is a real matrix whose inverse equals its transpose.

The determinant of an orthogonal matrix being either 1 or −1, an important subgroup of O(n) is the special orthogonal group, denoted SO(n), of the orthogonal matrices of determinant 1. 

mode control

-----------control_mode.pde--------------triggered by scheduler_tasks[] -> rc_loop() -> read_control_switch()
set_mode(flight_modes[switchPosition])
exit_mode(control_mode, mode);
control_mode = mode;
Log_Write_Mode(control_mode);
end

-----------flight_mode.pde--------------
triggered by update_flight_mode()
100hz or more (pixhawk 400hz, called directly in fast_loop)

switch (control_mode)
-- stabilize_run();
end

-----------control_stabilize.pde--------------
inside stabilize_run();

// convert pilot input to lean angles
get_pilot_desired_lean_angles(g.rc_1.control_in, g.rc_2.control_in, target_roll, target_pitch); (range 4500)

• where does control_in come from:
  --radio.pde--
  init_rc_in()

g.rc_1.set_angle(ROLL_PITCH_INPUT_MAX); //4500 g.rc_2.set_angle(ROLL_PITCH_INPUT_MAX); g.rc_3.set_range(g.throttle_min, g.throttle_max); g.rc_4.set_angle(4500); g.rc_1.set_type(RC_CHANNEL_TYPE_ANGLE_RAW); g.rc_2.set_type(RC_CHANNEL_TYPE_ANGLE_RAW); g.rc_4.set_type(RC_CHANNEL_TYPE_ANGLE_RAW); --RCchannel.cpp--

--set_pwm_no_deadzone(int16_t pwm)-- if (_type == RC_CHANNEL_TYPE_RANGE) {         control_in = pwm_to_range_dz(0);     } else {         //RC_CHANNEL_ANGLE, RC_CHANNEL_ANGLE_RAW         control_in = pwm_to_angle_dz(0);     }

// get pilot's desired yaw rate
target_yaw_rate = get_pilot_desired_yaw_rate(g.rc_4.control_in);

// get pilot's desired throttle
pilot_throttle_scaled = get_pilot_desired_throttle(g.rc_3.control_in);

// call attitude controller
attitude_control.angle_ef_roll_pitch_rate_ef_yaw_smooth(target_roll, target_pitch, target_yaw_rate, get_smoothing_gain());
parameter used above : RC_FEEL_RP, ACCEL_RP_MAX

• // calculate earth-frame feed forward roll rate using linear response when close to the target, sqrt response when we're further away     angle_to_target = roll_angle_ef (=target_roll,-4500~+4500) - _angle_ef_target.x (angle controller earth-frame targets);

angle_to_target -> calculate rate_ef_desired (linear or sqrt response) -> limit the rate _rate_ef_desired.x ->update new _angle_ef_target,angle_ef_error, update_ef_roll_angle_and_error(_rate_ef_desired.x, angle_ef_error (to be received from the funtion), AC_ATTITUDE_RATE_STAB_ROLL_OVERSHOOT_ANGLE_MAX);


// body-frame rate controller is run directly from 100hz loop

// output pilot's throttle
attitude_control.set_throttle_out(pilot_throttle_scaled, true);

Acc and mag direction

Accelerometer: 
x +: accelerate to the front
y +: accelerate to the right
z +: accelerate to the up

Magnetometer:
x +: rotating to the right
y +: rotating to the back
z +: yawing to the right

Roll, Pitch, Yaw:
Roll +: roll to the right
Pitch +: pitch backwards
Yaw +: CW angle from N pole

RCIN:
RC1 +: roll right
RC2 +: pitch backwards
RC3 +: throttle up
RC4 +: yaw right

我来说下，重心无论在上还是下对稳定性没有什么影响，lz要知道即使重心低也不能使四轴和直升机这两类飞行器的稳定能力增加，因为普通四轴在飞行的时候螺旋桨产生的拉力始终是垂直于四个螺旋桨平面的（四个桨在同一平面），飞行器并不会产生一种可以使其重的部位朝下而轻的部位朝上的力矩，这不同于我们提篮子时篮子收到的力，篮子收到的力是始终竖直向上的，所以重的部位才会下垂，而在空气中飞行则不会有始终向上的力，机身一旦偏转那么拉力也跟着偏转了。除非只有一种情况下低重心才能起到稳定效果，那就是像固定翼那样，机翼有上反角，四轴则是四个螺旋桨朝向中心安装，未完稍后继续






对于普通四轴而已，重心离开螺旋桨平面越远只能增加飞行器的惰性，（无论重心在上还是下都是一样的效果），为什么会这样呢？因为重心越远，机身做伏仰和侧倾动作的时候螺旋桨所需要克服的力矩会大大增大，所以使动作变得缓慢迟钝，不适合机动飞行，控制变得缓慢而笨重，此时如果还是使用原来的参数则会显得过底，所以需要把感度调高才行，再次强调：重心在上在下只要距离一样那效果也是一样的，除非螺旋桨内倾才能显出区别！！！













这是理论上的，实际上重力趋稳几乎对四轴没用（对飞控操作的飞行器来说，理论上重心远离运动轴心都是有害的）。
因为飞控的校正速度很快，其加速度是大于重力力臂产生的加速度的，所以飞控校正过程中，远离轴心的重心由于惯性的原因其实是起阻碍飞控校正作用的（重力加速度G是远小于飞控校正加速度的，因此基本上是飞控校正力带着重心围绕轴心在跑）。同时，校正过程中四轴到了水平点后，由于重心远离运动轴心，重心在惯性作用下继续推动四轴绕轴心运动，破坏水平，造成飞控不得不再次校正，反复摇摆。因此不管在上面还是在下面，重心远离四轴轴心都是有害的（轴心在哪，看我前贴，我是这么认为的，不一定对）。

On a quadcopter, there isn’t this point of inefficiency, but having to continuously slow down and speed up the props to remain in the air does waste a lot of energy (however regenerative braking would reduce this wastage, but not many models do this at the moment). What’s interesting is that the effect of this was very evident when we were tuning our quadcopter – our quadcopters were designed to lift about 1kg of payload, but they could be made to lift a brick (about 2.3-2.6kg) ONLY if the stabilization tunings were relaxed so that the craft was less stable in the air, but wasted less energy trying to stay absolutely level. Either way, aerodynamically, larger and slower spinning props are more efficient than small fast-spinning props.

This comes down to a lot of aerodynamics, but in effect it’s to do with the fact that the formula for kinetic energy is 1/2mv^2: it takes four times more energy to move a mass of air at twice the speed; compared to only twice the amount of energy to move twice the mass of air. In both cases, the same amount of momentum is conferred (m*v). So it turns out that it takes less energy to exchange momentum with a large amount of air at slow speed than it is to exchange momentum with a small amount of air at high speed. Therefore a large, slower-moving prop is more efficient than a small large-moving prop, especially at hover.

How does an ESC work

Some brushless motors use hall effect sensors to sense the magnet position and provide feedback. However, most of the brushless motors used for RC are sensorless. When energizing the 3 coils, at any given time one wire is driven positive, one is driven negative and the third is undriven. The magnets on the spinning rotor induce a voltage in the undriven coil which the sensorless controller detects and uses to determine when to switch to the next step in the sequence. 

One problem with the sensorless motors is that voltage induced in a coil is proportional to the speed of the magnet moving past it. At very low speed there is not enough voltage to detect so at startup, the controller has to drive the motor without feedback until it is spinning fast enough to induce a detectable voltage.

4-POLE BRUSHLESS DC MOTOR ANIMATION

Todo

Test slip current of motor

GPS Glitch

1. The vehicle is loitering normally and then suddenly takes off in the wrong direction.  This is generally caused by a GPS Glitch.  There is no 100% reliable protection against these which means the pilot should always be ready to take-over manual control.  Beyond that ensuring a good GPS HDOP before take-off is always good and it may help to reduce the GPSGLITCH_RADIUS and/or GPSGLITCH_ACCEL parameters (see GPSGlitch wiki page for details) to tighten up on the glitch detection.

ERR-GPS 2 means a GPS glitch. ERR-GPS 0 means a recovery.


FS_GPS_ENABLE should be set to 1

Building Mission Planner with Visual Studio

Building Mission Planner with Visual Studio

Downloading the ArduPilot code and setting up SITL in Ubuntu.

Thanks to TheQuestor, there is now a really smooth way for installing and launching SITL.
These Guides contains all you need to get SITL up and running in it's basic form

This one covers installing/running SITL on an Ubuntu machine.
SITL_Installer_launcher_g...

Get this one for info on how to get Ubuntu installed, using VMware
SITL_Manual_Setup_v3.1

This one details how to connect SITL to MissionPlanner, as well as customizing start-up location.
MP_SITL_and_Location

This one deals with getting FlightGear installed and connected to SITL.
FlightGear_SITL

This file is the launcher/installer: (Hint: Download it from the Ubuntu-machine.)
sitl_installer_launcher

Updated July 8, 2014.
I've added guides on connecting MissionPlanner, customizing start-up location and installing and running FlightGear.
Next up is the guide for control with a Taranis.

The Taranis connection is roughly described here:
Install and run FlightGear with SITL. Connect a Taranis.

Loiter_turns Command Troubleshooting

The problem we faced at today's flight test was:

• The LOITER_TURNS command recognised the centre of the circle, BUT it seemed to rotate around the point with no radius
• However, the CIRCLE_RADIUS is correctly set, and it is working in CIRCLE mode
• After it completed LOITER_TURNS, and heading to the next waypoint, the altitude drift to ~33m, far away from the designated 20m height.

The first two bullets indicate that the problem is something to do with the code. AND IT IS!

Here is the code of our concern:

---------------------------------------------------------------------------------------

case MAV_CMD_NAV_LOITER_TURNS:                      // MAV ID: 18
          copy_location = true;
          num_turns = packet.param1;                      // number of times to circle is held in param1
          radius_m = fabs(packet.param3);                 // radius in meters is held in high in param3
          cmd.p1 = (((uint16_t)radius_m)<<8) | (uint16_t)num_turns;   // store radius in high byte of p1, num turns in low byte of p1
          cmd.content.location.flags.loiter_ccw = (packet.param3 < 0);
          break;

---------------------------------------------------------------------------------------

This clearly shows that the third parameter of the LOITER_TURNS command is used to store the radius data. HENCE, we shall not simply put 1 or -1 to indicate direction of turn, but should type in something like +20 or -15.


There is a minor issue hiding in the code above. The cmd structure in the code only accept one general parameter. This means that the num_of_turn and radius_m must be squeezed in to the single uint16_t variable. This is evident below:

-------------------------------------------------------------------------------------

struct PACKED Mission_Command {
        uint16_t index;             // this commands position in the command list
        uint8_t id;                 // mavlink command id
        // CHM - the commande structure have only 1 parameter in short int. This cause the loiter_turn cmd to be squeezed (num of turn + turn_radius).
        uint16_t p1;                // general purpose parameter 1
        Content content;
    };

-------------------------------------------------------------------------------------

In conclusion, the 1 should be changed to larger number. TO BE VERIFIED BY TOMMOROW

Parameter related to NAV / AUTO performance

WPNAV_LOIT_SPEED: original 500, changed to 900
WPNAV_RADIUS: original 200, changed to 100
WPNAV_SPEED: original 500, changed to 900
WPNAV_SPEED_DN:
WPNAV_SPEED_UP: original 250, changed to 350

PILOT_VELZ_MAX: original 300, changed to 350

ANGLE_MAX : original 4500, changed to 5000

Info about Spline waypoint

If you want to use your arducopter to create nice smooth videos you usually need to fly it manually to get nice smooth turns (apart from using a decent gimbal3). If you fly a mission in auto mode you will notice that as your arducopter reaches a waypoint it will suddenly turn to the next one, not ideal if you want a smooth, flowing video. However David Dewey2 has been working on making some improvements to the arducopter code that allows you to fly smooth continuous curves between waypoints for great autonomous aerial videos!

Each spline segment is a cubic polynomial curve defined in 3D space, with 1st and 2nd derivatives continuous wherever two segments meet at a waypoint. This gives a nice smooth transition between curve segments during flight. It also saves time and battery, since abrupt speed and direction changes are avoided.

This is apparently being included in a future arducopter release, but if you cant wait to test it out you can find the code over on github8

Week 13 Day 1 Video quality summary

Test 1

Video 1: Week 10 First video test

Remarks: Rubber duck antenna (below) was used for both transmitter and receiver for our first flight. Video quality was not ideal as flickering was noticed in the second half of the video.

Rubber duck antenna

Problem: The flickering of video could be the usage of rubber duck antenna which is not the best for video transmission.

Solution: To change rubber duck antenna to clover leaf (3-leaf and 4-leaf) for better transmission.

Clover leaf antenna

Test 2

Video 2: Testing of high speed video quality

Remarks: After replacing the antennas to clover leaf antenna, we brought it to test the video quality when attempting high speed. Video quality is definitely much better than test 1 but there is still a bit of flickering and colour loss.

Problem: The problem we guessed was that the transmitter we used had some faults in it.

Solution: To replace it with transmitter available in the lab.

Test 3

Video 3: New transmitter

Remark: Lesser flickering of video. Yet to try high altitude flight video testing. 

Week12 Day 7 Speed test

Top speed 19.99m/s, 70km/h

vibration at Pixhawk is tolerable, but vibration at arm end can be great.

SimonK flashed ESC spin speed set

MOT_SPIN_ARMED changed from 84 to 70 then to 60 (not spinning) to 69 (minmum spin speed).
finalized value: 70

THR_MIN : try 0.09 (0.09*817=73.53>70). finalised.

smoothing RC control

I'm not actually flying trunk Marco, I'm still flying a branch based on my initial implementation.  I think nobody else "found" the problem because they actually like how it flies now.  Actually, that is not looking too bad to me Marco.  You're inputting REALLY sharp stick inputs.  You're asking a lot from it.

The idea for the angular rate accel damping, was that copters which are tuned with really aggressive PIDs for good attitude accuracy in winds, were much too sensitive to really minor stick inputs.  Just the jitter on the sticks, which all humans have, was enough to get the motors jerking the copter around.  This is really bad for video work, as I'm sure know.  It's also the cause of the "bounce back" that you get in acro modes.  

So I was trying to fix all that.  The bounce-back in acro mode happens because you moved the stick faster than the copter can possibly accelerate the pitch or roll.  So an error builds up, and after the motion stops, the controller fixes the error.  With the way I had done it, you could tune the acceleration rate to something quite high.  It would still feel crisp, but you wouldn't be capable of asking the copter to do something it couldn't do.

Here's a video of from when I started all this.  In the video, the code is active on the roll axis, but not pitch.  And I didn't learn until recently, that there was a bug which meant it was only *decelerating* at about half the rate it should, so the stops were a bit softer.  Anyway, you can see the copter still responds sharply.  And you can hear the difference in the sound of the motors on the pitch axis.  They are too sharp.  It's very jumpy and hard to control pitch smoothly like that, but it fights winds really well.  The roll axis has the same PID gains, but is much easier to control.

https://www.youtube.com/watch?v=ROnwYCZReDs

This also helped smooth out Stabilize mode.  If you have a camera ship, you could lower the accel rates to smooth out the motions of the copter.  You could run very high PID's to fight winds aggressively, but it would prevent you from jerking the copter too hard, upsetting the gimbal.  However, using low values, would lead to a lag if you input sharp inputs.  But really, this is up to the user to tune these.  If you want smooth for a really big octo carrying a big camera, you use 360 deg/sec/sec.  If you want sharp, you could use 1080 deg/sec/sec, which is about as much as any multi-copter can do anyway.  Heck, you could set it to 2000 deg/sec/sec if you wanted, which is 3D Helicopter territory.  The algorithm couldn't *make* the copter do what you ask, but it would make it *try*. 

About the same time, Jason came up with a different concept, which I believe was simply a low-pass filter on the RC Input to smooth the pilot's commands.  This can also create a lag.  I don't know what his filter frequencies were.

Then, Leonard combined both ideas into a single implementation, and that is what you are flying.  I don't think it's "crap", but might just need to have it's parameters set to something you like.  Maybe RC Feel of "100", whatever that is, is not high enough for you.  For sure, you should try increasing the acceleration rate to 108000 from 54000.

Back in February, I forwarded some comments to Randy and Leonard from when I reviewed their code.  Among them was:

2) Get_Smoothing_Gain can only be between 2 and 12, based on rc_feel of 0-100.  Smoothing_Gain seems to be expected to be between 1 and 50 in angle_ef_roll_pitch_rate_ef_yaw_smooth().  Not a big deal as it's dimensionless, but just sayin.

Leonard responded that he thought 12 would be enough, and even that 8 would be as much as most people would want.  I can't really comment, as I haven't flown it, and the numbers are dimensionless.

In addition to changing the accel rate to 108000 (1080 deg/sec/sec), you might also try increasing RC_Feel.  It looks to me like you might be able to push it as high as 480, before the constrain in angle_ef_roll_pitch_rate_ef_yaw_smoth() will limit it.  RC_Feel of 480 will give you the Get_Smooth_Gain of 50, there's a constrain on that above 50.

But I caution, I have no idea how the rest of that function works, I can't follow it.  Something else might break down and fail if you go that high, so proceed with caution.

If you wanted to try my original implementation which has a accel limiting, but no filtering, I sent you that info way back in February, but I never heard anything back from anybody.

Rob

AC3.2 - 3 new parameters

Holy crap batman the sky is falling!

This is pre beta people :)

First up I would like to say a couple of things:
- A big first up. Everybody please try to keep the feedback constructive until you understand what the new features are.
- Thanks Marco for your feedback! and... relax I am confident you will like these features once you understand them.
- As far as I can see this isn't lag, it is doing exactly what it is supposed to do.
- These features are designed to improve the performance for the sharpest acro pilot, the gun fpv pilot, the instructor for a new beginner (on the gun acro quad), and the massive camera ship. If you don't understand how this can be true then you have some learning to do. :)
- Finally my whole interest in the control code of Arducopter is to make it possible to squeeze every last bit of performance out of a frame. And I understand I need to do this in a way, that keeps tuning parameters to a minimum, and makes it easy for a beginner to start using arducopter.

First up you should be able to get back to the sharp feel you like by setting:
RC_FEEL_RP to 100
ATC_ACCEL_RP_MAX to 216000 but anything over 108000 shouldn't be noticeable. I would suggest 94500.
ATC_RATE_RP_MAX to 54000 but don't do this on your big copter! I also don't think this parameter is your problem.

This should make things very similar to your original experience.

Ok so what are these parameters doing and how have I chosen the defaults. The defaults are chosen to make a sharp-as-hell copter feel like a stock 3dr quad on the old default setting before we discovered that autotune could turn it into a razor blade. So if you had a sharp-as-hell copter before, expect it to feel like a docile beginner quad.

So how have we done this? There are three layers.
1. RC_FEEL_RP
2. ATC_ACCEL_RP_MAX
3. ATC_RATE_RP_MAX 

1. For the old hats, RC_FEEL_RP is basically an artificial Stab_P. It controls how aggressively the copter reacts to small changes in the stick inputs. A value of 25 will give you the equivalent of Stab_P of 4.5 and a value of 100 will give you an equivalent Stab_P of 12. "12!" I hear you say, "that will make it oscillate". Well, that is the point, it won't. If your value is higher than the copter is capable of, all that will happen is your commanded position will leave your actual position behind and your copter will just do it's best to keep up. 

Why use 0 to 100? That was just to make it easy for people to adjust the way it feels. 

Finally for those of you digging into the physics of motion that we design these control systems around. RC_Feel_RP basically defines the Jerk and therefore stops the hunting around zero.

2. Now the big one, ATC_ACCEL_RP_MAX. This is the maximum acceleration you can request of your frame. If you set this to 18000 it will feel like you are flying the avengers aircraft carrier. I would not recommend going below 36000 and 54000 is a nice number for everyday relaxed flying. Most agile frames, running 10" props, are capable of 100000 to 120000 (on high powered micro quads this could easily double again). How do I know this? Because I have been looking at this on everybodies autotune logs since it was released. This brings me to my next point. The next release of Autotune will set this parameter to something like 75% of the maximum your copter is capable of while staying in control.

Ok, so why did we want to include this. There are 3 basic reasons. Many people were detuning their Stab_P after autotune because they found it too aggressive and fast. Camera ships need smooth movements to get the best video. And finally my favorite, FPV and acro pilots get a slight bounce back or digital feel to acro.

For people that aren't ready or don't like the ultra sharp control afforded by autotune on many copters can make their copter feel like a larger, lower powered copter without sacrificing the stability of a small agile tune. This is where 54000 is a good number.

Camera ships are able to make much smoother movements without relying as heavily on the steady hands of a talented pilot. The camera ship operator is effectively able to control both the Jerk (change in acceleration per unit time) and the angular acceleration with the RC_FEEL_RP and ATC_ACCEL_RP_MAX parameters respectively. The aggressiveness of copter movement can then be controlled to ensure that camera gimbals can stay perfectly level or to remove that last little wobble on very large copters.

Finally Acro and especially FPV pilots, flying in ACRO, can choose ATC_ACCEL_RP_MAX just under what their frame is capable of. What this does is slow the desired point as it reaches the final target. Without this the pilot can request changes in rate the copter is capable of, the result of which is a small overshoot and bounce back. This means that a well setup copter (one that has done autotune) will stop reliably and repeatedly without bounce back or overshoot when performing aggressive maneuvers like rolls or loops. This is where the last little bit of precise control is squeezed out of the copter. This is the pointy end of the stick that all but the most talented pilots won't even notice and even the pilots that do will only be able to describe the performance in terms of confidence or feel. Of course the FPV pilot will be able to pick this up much easier. The most obvious axis that this improves is Yaw.

3. Now ATC_RATE_RP_MAX is the safety net that sits below everything else to ensure the copter is always in control. The two parameters I just described bypass the stabilised controller and feed their commands directly into the rate controller. This provides a very fast response (faster than any other Arducopter release) because we don't need to wait for the position error to build up before the copter reacts. The ATC_RATE_RP_MAX acts on the output of the Stability controller that is working to minimise the remaining error between where the pilot's filtered input says it should be and where it is. 

We choose ATC_RATE_RP_MAX to be a rate we know the copter can safely stop from and again I can calculate this from Autotune. Here I will probably go to something like 30 to 50% the maximum value calculated by Autotune.

This addresses the problem with large copters that fly fine until they are commanded to go from full right 45 degrees to full left. The copter then overshoots and flips. This is being caused by the Stab controller asking for a higher de-acceleration than the copter can achieve because of a large Stab_P value. When correcting small angle errors, say 45 degrees, the copter doesn't build up too much speed. However, when the angle error becomes large the copter is able to get a real head of steam up and it is like comparing the stopping distance of a car from 60 km/h to doing 120 km/h (the stopping distance isn't double, it is quadruple).

The beauty of this parameter in the new system is we are able to set this to very conservative values without compromising the performance of the copter. This value is really only used when the copter is forced away from it's desired attitude by an outside force, impact, or mechanical failure.



Ok, it looks like I have finished my essay just in time for Marco to have worked out the settings without my help but I hope this has explained a couple of things here. Thanks again for everybodies feedback! And remember that the ATC_ACCEL_RP_MAX and ATC_RATE_RP_MAX parameters will be set by Autotune based on measurements of the system. It is only RC_FEEL_RP that is purely a user defined parameter. The defaults for the ATC_ACCEL_RP_MAX and ATC_RATE_RP_MAX parameters should be chosen as safe numbers for everybody to start with and leave autotune to update them or experienced users to tune them as they please.

Ok, this has taken me longer than I thought.

Good night everybody and sorry I didn't discover this earlier!!!

SimonK Firmware

This tree contains Atmel AVR assembly code for ATmega-based 3-phase sensor-less motor electronic speed control (ESC) boards, originally for Turnigy and similar models. This work is based on Bernhard Konze's "tp-18a" software, which was a port from his earlier personal work to the TowerPro 18A and original (not current!) Turnigy Plush boards. Please see tgy.asm for Bernhard's license.

Patches and comments are always welcome! Let me know how it goes!

Features

• 16MHz operation on most boards
• 16-bit output PWM with full clock rate resolution (~18kHz PWM with a POWER_RANGE of 800 steps)
• 24-bit timing and PWM pulse tracking at full clock rate resolution
• ICP-based pulse time recording (on supported hardware) for zero PWM input control jitter
• Immediate PWM input to PWM output for best possible multicopter response (but NOT where soft start or really any significant current limiting is needed!)
• Accepts any PWM update rate (minimum ~5microseconds PWM low time)
• Optimized interrupt code (very low minimum PWM and reduced full throttle bump)
• Configurable board pin assignments by include file
• Smooth starting in most cases
• Forward and reverse commutation supported, including RC-car style reverse-neutral-forward PWM ranges, with optional braking

Hardware

See http://wiki.openpilot.org/display/Doc/RapidESC+Database and/or https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE for a more complete list. Some board pictures here: http://0x.ca/sim/esc/

Tested boards by target:

• afro:
  • AfroESC (http://code.google.com/p/afrodevices/downloads/list)
• afro2:
  • AfroESC 2 (prototype)
• afro_hv:
  • AfroESC HV (high voltage, with all-N FETs and drivers)
• afro_nfet:
  • AfroESC with all-N FETs (revision 3)
• birdie70a:
  • Hobby King Birdie 70A (BIRD-60A)
  • Hobby King Red Brick 200A (RB200A, black board)
• bs:
  • Hobby King 6A (HK_261000001)
  • Hobby King 10A (HK_261000002)
  • Hobby King 40A (F-40A)
  • Hobby King 60A (F-60A)
• bs_nfet:
  • Hobby King 20A (F-20A)
  • Hobby King 30A (F-30A)
• bs40a:
  • Hobby King BlueSeries 40A (and some Mystery 40A boards)
• dlu40a:
  • Pulso Advance Plus DLU40A with opto-isolated inverted PWM input
  • Hobby King Multistar 45A
• dlux:
  • Turnigy dlux 20A SBEC
• hk200a:
  • Hobby King SS Series 190-200A (HK-SS200ALV)
  • RCTimer 50A TQFP version
• kda:
  • Keda 12A rev B with inverted PWM input (30A should also work)
  • Dynam 18A, 25A with Blue Heat Shrink
  • Hobby King Multistar series (30A and under)
• maytech30a:
  • Maytech 30A and 20A, complementary PWM
• maytech40a:
  • Maytech 40A, complementary PWM
• maytech60a:
  • Maytech 60A, complementary PWM
• mkblctrl1:
  • MikroKopter BL-Ctrl v1.x (flashable by ISP only)
• rb50a.hex
  • Hobby King Red Brick 50A (RB50-ESC)
• rb70a.hex
  • Hobby King Red Brick 70A (RB70A)
  • Hobby King Red Brick 200A (RB200A-BTO, black board)
• rct50a:
  • RCTimer 50A older MLF version
• tbs:
  • Team BlackSheep TBS 30A ESC (ICP input version)
• tp:
  • Original TowerPro 17A, 25A
  • Hobby King SS models without "-HW" in part number
• tp_8khz:
  • tp at 8kHz PWM (workaround for DYS/HK-SS clones with PWM noise problems)
• tp_i2c:
  • tp modified for I2C input (old ADC4 routed to ADC1)
• tp_nfet:
  • Newer TowerPro 25A with inverted low side (BL8003 drivers)
• tp70a:
  • TowerPro 70A with BL8003 FET drivers (inverted low side)
• tgy (these boards typically have no external resonator):
  • Original TowerPro 18A
  • Original Turnigy Basic and Turnigy Plush 10A, 18A, and 25A (Hobbywing OEM)
  • RCTimer 10A, 18A, 20A, 30A, 40A (18A, 20A, 30A are same board with more or less FETs)
  • Hobby King SS models with "-HW" in part number
• tgy6a:
  • Original Turnigy Plush 6A

Notes

• If it breaks, you get to keep both pieces!
• Use at your own risk, and always test first without propellers!
• New Turnigy Plush, Basic, Sentry and Pentium boards (Hobbywing OEM) have all switched to SiLabs C8051F334, d'oh!
• If your ESC has 6 pads and an AVR, it's probably compatible; the pads are MOSI, MISO, SCLK, GND, VCC, and RESET. If it has 4 pads, it is probably a newer SiLabs-based one, for which this code will not work. (Except HK_261000001 which has 4 pads but has an AVR.)
• I build and maintain this in Linux with AVRA (1.3.0 or newer). Patches welcome for AVR Studio APS files, etc.
• The TowerPro/Turnigy Plush type boards typically do not come with external oscillators, which means their frequency drifts a bit with temperature and between boards. Multicopters and RC-car/boat controllers (with a neutral deadband) would probably be better on a board with an external oscillator. The Mystery/BlueSeries boards typically have them, as well as most higher current boards.
• This doesn't yet check temperature or battery voltage. This is not desired on multi-rotor platforms; however, people still want to use this on planes, cars, boats, etc., so I suppose I'll add it.