Gentlenav

Sections
Gentlenav suppliers

Matrix Kalman Airspeed control using potential and kinetic energy. See options.h for airframe.

Gentlenav VTOL Avoid Euler angles DCM and quaternion rmat.c file Ground robot Data fusion Python integration, Uav coning Control gain units Polar coordinates Radio mixing Waypoint over serial Servo preventing servo failure Gentlenav quad Nasa branch uses euler angles, sign reversal on 180 rotation. Magnetometer Mount in the wing tips. Catapult
 * Gimbal lock
 * Gentlenav altitude speed control The idea is to use potential and kinetic energy to find equivalent altitude for given velocity.
 * Dead reckoning
 * Gyro drift  Location of IMU
 * Serial
 * Uav landing
 * Acceleration compensation quads
 * Control gain units
 * Gentlenav code branches

imu mounting
https://groups.google.com/forum/m/#!topic/uavdevboard/MqzXKiuaGAQ mounting of UDB5 IMU control board Regarding location of any IMU in general, including UDB in particular, there are two sensors to think about, the gyros and the accelerometers. As far as the gyros are concerned, there are no restrictions at all on location, since the rotation rate is the same at any location on the plane.

It is only the accelerometers that you need to think about, because of unaccounted for centrifugal effects. The acceleration of the IMU is equal to the acceleration of the center of gravity, plus the centrifugal acceleration of the IMU with respect to the center of gravity, due to rotation of the plane. The only location where the accelerometers do not experience an unaccounted for centrifugal effect is the center of gravity. So, ideally, that is where you would mount the IMU.

However, the unaccounted centrifugal acceleration is usually small, so you can get away with mounting an IMU anywhere on the plane, as long as it is not too far from center of gravity. Most of the error arises from yaw rate. The unaccounted for acceleration in meters/sec/sec is W*W*R, where W is the yaw rate in radians per second, and R is distance from center of gravity in meters.

Mounting the IMU in front of or behind center of gravity will generate pitch error. Mounting the IMU off the side will generate roll error. But as long as you keep the offset less than about 12 inches, you should be fine. For example, lets suppose you put your plane into a continuous tight turn at 60 degrees/sec (6 seconds for a full turn). That is about 1 radian per second. Suppose you mount the IMU 12 inches off center radially. That will generate an acceleration on the IMU of about 0.333 meters/sec/sec, or about 0.0333 g, which will generate an equivalent tilt error of about 2 degree. Nothing to worry about.

Notice that I keep using the phrase "unaccounted for centrifugal effect". That is because there is already a centrifugal compensation computation to account for centrifugal effects, that assumes the IMU is mounted at the center of gravity. Actually, it is theoretically possible to account for the acceleration effect of mounting the IMU very far away from the center of gravity, all you need to know is the 3D location of the IMU with respect to center of gravity. But as far as I know, none of the popular autopilots let you do that.

Code base

 * https://groups.google.com/forum/#!forum/uavdevboard
 * https://groups.google.com/forum/#!forum/uavdevboard-dev
 * https://github.com/MatrixPilot/MatrixPilot
 * https://github.com/KeesGuijt/MatrixPilot Fork by KeesGuijt

Matrix pilot features

 * http://diydrones.com/profiles/blogs/a-closer-look-and-demo-of-helical-turns, http://diydrones.com/profiles/blogs/helical-turn-controls Helical turns
 * http://www.diydrones.com/profiles/blogs/sustained-rotations-pushing Sustained rotations
 * "Dead-reckoning" algorithm that provides high-bandwidth estimates of location and velocity.
 * Improved accuracy during sustained high rate turning
 * http://gentlenav.googlecode.com/files/WindEstimation.pdf
 * http://gentlenav.googlecode.com
 * https://groups.google.com/group/uavdevboard/browse_frm/thread/81935f5433df5b78 Quaternion-DCM hybrid discussion on DIYDrones ....
 * Magnetometer is placed in the wingtip to avoid interference from the engines.

The other method is a linearization of the non-linear, exact, trigonometric expressions in which the cosine is approximated as being equal to 1, and the sine is approximated by the magnitude of the rotation.....
 * Self-aligning magnetometer . Allows one to mount the magnetometer in the wing tip away from magnetic noise in the center of the frame. See the forum discussion on diydrones from this link Gentlenav
 * Matt C's recent work on improving MP for his 5 meter wingspan glider is going well . Matt has a full channel mixing system, new air speed control features, and bi-directional MAVLink PID tuning and calibration features  (as well as the audio variometer previously mentioned). Most of his code is now in trunk. The APM team, and in particular Tridge, has been working with Bill to  try and see if he can make the latest IMU algorithms work in their quads  ... because the algorithm, in theory, may offer better orientation and   positioning https://groups.google.com/group/uavdevboard/browse_frm/thread/51261f625298c83e#

Ardu pilot has not yet implemented these features and neither it seems openpilot. Gyro saturation occurs during rotations, which Gentlenav solved.

Earth frame, Body frame translation
https://groups.google.com/forum/m/#!topic/drones-discuss/H2l3PeYeYr4 Drones forum on goole groups Onion: The code layout is still based on the early days before we understood the significance of the earth frame body frame translation. This means that Roll, Pitch, and Yaw are all effectively handled separately in both the way we are forced to write our control code and the way we define each mode. This means that we have to use overly complex and hard to understand code to implement what should be simple control structures. It also means that it is easy for a person experimenting to mix incompatible control algorithms resulting in a crash.

Yaw
https://groups.google.com/forum/m/#!topic/drones-discuss/2KGOMKFZKUQ Yaw

Andrew Tridgell
https://github.com/tridge/MAVProxy/tree/master/modules

http://diydrones.com/forum/topics/an-improved-method-for-accounting-for-acceleration-in-gyro-roll
 * https://groups.google.com/group/uavdevboard/browse_frm/thread/8f56b199d1aa151f Switch between different algorithms dealing with magnetic interference.
 * https://groups.google.com/group/uavdevboard/browse_frm/thread/c6d2686366eeb5b9

Attitude problems
https://groups.google.com/group/uavdevboard/browse_frm/thread/8c5ab3866be17824

Construction details
https://groups.google.com/group/uavdevboard/browse_frm/thread/e54d345da5149017# Configuring hardware, udb imu, servo's etc.

Quad test frame
http://groups.google.com/group/uavdevboard/browse_frm/thread/8fdbccd17b9f2a5d Test frame used for quads

Dead reckoning

 * http://www.diydrones.com/profiles/blogs/a-simple-deadreckoning
 * http://groups.google.com/group/uavdevboard/browse_frm/thread/60086c3843ef8de

There are two "hard" problems still on my list of things to solve. One of them is relevant to your question. The two problems are:

1. Measuring accelerometer offsets and calibration in flight. 2. Performing centrifugal compensation without assuming angle of attack and side-slip. (Somewhat useful for fixed wing, very useful for quads.)

I have the theory for the solutions to both problems. Now I just have to implement.

The first problem is the major contributor to error in dead-reckoning. (You are correct, noise is not the major problem any more, because of our high sampling rate.) Solving it would provide improved performance across the board, including more accurate dead-reckoning.

option.h file
https://groups.google.com/group/uavdevboard/browse_frm/thread/a1459b978cca12f8 Raven 3d plane in strong winds
 * https://groups.google.com/group/uavdevboard/browse_frm/thread/267be56dd1dbb2c6 Twinstar calibration setup PID values etc.

https://groups.google.com/forum/#!topic/uavdevboard/sHu5hkb3ezk X8 wing HI all,

Tom and I just flew our Skywalker X8 for the first time. It included an 'interesting' launch and landing, but otherwise the flight was flawless under MatrixPilot/UDB4 control.

The entire flight was flown in stabilized mode. The options.h file is attached.

The link below show the flight from launch to landing.

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

Best regards, Phil

Logo flight plans
https://groups.google.com/group/uavdevboard/browse_frm/thread/40435c933c47ff55
 * https://groups.google.com/group/uavdevboard/browse_frm/thread/40435c933c47ff55 gliding airspeed using spoilers crashmatt

Fixed wing, Matrix pilot best solution
http://groups.google.com/group/uavdevboard/browse_frm/thread/27b434d9940e0d40


 * Major IMU improvements, including "dizzy-proofing", automatic inflight gyro calibration, and compensation for magnetometer latency.
 * - Live camera tracking of one UDB from another.
 * - User-configurable OSD layouts.
 * - Full support for the DIYDrones MediaTek GPS.
 * - Maintain minimum ground speed. The speed control loop is now based on the smaller of ground speed and air speed.
 * - Improvements to inverted stabilization.
 * - Improvements to the Flight Analyzer tool.
 * - More bug fixes.
 * Antenna tracking of plane is done from ground using UDB with magnetometer.

DCM algorithm
https://groups.google.com/group/uavdevboard/browse_frm/thread/81935f5433df5b78

http://www.diydrones.com/group/arducopter-evolution-team/forum/topics/suggestion-for-arducopter-v2-6

Sustained rotations
http://diydrones.com/profiles/blogs/sustained-rotations-pushing?id=705844%3ABlogPost%3A429539&page=2#comments

Anyway, version 949 of MatrixPilot in the code repository contains the improvements that have been made to compensate for the errors that arise during sustained high rate rotations. With it, you can spin around any axis at 500 degrees/second for as long as you like.

http://frankhermes.com/

http://www.rocketelectronics.com/

Mavlink
http://groups.google.com/group/uavdevboard/browse_thread/thread/53e1b94e6a3f6ce0/0928616bd915a43c?lnk=gst&q=mavlink#0928616bd915a43c

Temperature effects
Temperature gyro

Calibration

 * http://groups.google.com/group/uavdevboard/browse_frm/thread/76a17e323375294d  Wind compensation
 * http://groups.google.com/group/uavdevboard/browse_frm/thread/48da77786706c41e Elevon calibration

Channel reversing

 * http://groups.google.com/group/uavdevboard/browse_frm/thread/e7d2c2f9ecd2a111 Swap Aileron and Elevator
 * http://groups.google.com/group/uavdevboard/browse_frm/thread/a430392169762a7e Peter Hollands discusses issue further

Losing GPS lock
http://groups.google.com/group/uavdevboard/browse_frm/thread/60086c3843ef8de

In clear weather devoid of fog, IR sensing Paparazzi uavav]] provides wing leveling control. When flying in clouds or fog and over mountains the IR control fails. Gentlenav IMU works in any weather, over any terrain. Combine Paparazzi_uav and Gentlenav in a UAV, using Gentlenav as the primary means of control and correlate it with IR on losing GPS lock.

Board orientation
http://groups.google.com/group/uavdevboard/browse_frm/thread/917bb38696d7b5b6 GPS orientation and installation of boards

Asymmetric elevator response
http://groups.google.com/group/uavdevboard/browse_frm/thread/48da77786706c41e

confirm with ground testing with your settings that there is asymmetric response to roll. That is what is expected from ROLL_ELEV_MIX, to produce some up elevator during a turn. The only thing you need to figure out is what you want it set for.

In flight PID tuning, raise slew rate of controls
http://www.diydrones.com/profiles/blogs/in-flight-tunable-gain In flight PID tuning and http://www.diydrones.com/profiles/blogs/in-flight-tunable-gain?id=705844%3ABlogPost%3A180450&page=2#comments. Describes modding the servo for better IMU control, but that under manual control will be harder.

I have made some modifications to the MatrixPilot code to do tests on In flight tunable gain. If this is further refined, it will be possible to do tuning of P/D gains on roll, pitch and yaw axis while in flight. The idea is that the gains can be tuned with a spare button on your RC transmitter one after the other (separately) while you fly the plane in stabilized mode. The gain you want to tune is gradually increased until oscillation is seen at max desired airspeed and then reduced back somewhat to ensure stability on that axis with that gain. My code mods is a hack at the moment, but this is just to illustrate the concept

Ric - the servos I'm using on my Funjet http://www.diydrones.com/profiles/blogs/gt200kmh-funjet-the-fastest are those (0.068 at 60° / 6V). http://www.hobbyking.com/hobbyking/store/uh_listCategoriesAndProducts.asp?idCategory=84. They are well centering and generally well suited. Centering is a main must, because high speed and bad centering isn't worth a penny (not forgetting leverage accuracy and free play). Those servos are small and light enough (10.9g), not needing high voltage (HV 380 12V !?) and, not least, cheap.

Ric is correct, centering is important. Which reminds me, there is a mechanical technique that you can use to raise the effective slew rate of the controls. You can use leverage to reduce the required deflection at the servo. You use the holes in the servo arm that are far from the center, and the holes on the control surface arm that are close to the surface. This increases the effective control gain without bumping into the rate limit. Of course, if you use this technique, you must eliminate all "free play" in the mechanical linkage, and the manual control will not be easy. But the control stabilization will be better.

Matlab - I did some Matlab simulations for "John Mac" while we were trying to get heading hold working for his helicopter. We had a "damping" feedback gain turned too high, it was pushing a servo into rate limiting, I finally figured it out with some simulations. There are two nonlinear blocks in Matlab's simulink library that do a nice job of capturing the most important features of the deflection of a control surface that is driven by a servo: a "Saturation" block, followed by a "Rate Limiter" block. You set the saturation block to represent the limits of the deflection. You set the rate limiter block to represent the maximum slew rate. Once you have the deflection of the control surface, you can compute everything else from the model of the airplane dynamics.

Pilot links

 * Pilot links

Usenet post1
https://groups.google.com/group/uavdevboard/browse_frm/thread/cb766781b7bb757b

There are a series of technical discussions here relating to UDB and

Dealing with white noise
MatrixPilot. By using oversampling at 8000 samples per second, we are able to achieve 14 bit resolution for gyro and accelerometer signals. Regarding in-flight autocalibration of the gyros, you might want to read this posting 

Absolute accuracy camera aiming
With regard to absolute accuracy for camera aiming, the limiting effects are errors in the reference vectors used for drift compensation. Accuracy is rather good (sorry, but I cannot give you hard numbers on that, but probably within a couple of degrees) if the plane is flying straight and level at constant speed. But if it is turning a lot or changing speed, the error could be more than that, because of centrifugal effects. I am presently working on a method, described here http://diydrones.com/forum/topics/an-improved-method-for-accounting-for-acceleration-in-gyro-roll

to reduce the error due to acceleration. There are other things to consider in estimating the performance of camera aiming. I consider Peter Hollands to be the expert on that subject, perhaps he will comment. Best regards, Bill Premerlani

Electric motor calibration
https://groups.google.com/group/uavdevboard/browse_frm/thread/8fdbccd17b9f2a5d

In my work with VFD AC Motor Drives during the installation of a new motor we run the controller through an automated test that determines the varous response characteristics/dynamics of the motor to calibrate the Drive. Would it be unreasonable to bring the flying craft to a safe hover with some type of default PID settings then have the controler make micro bursts of throttle inputs to the various motors allowing the sensors on board to measure the torque and various rational offsets needed? This could make it easy for us to be able make adjustments for changing the dynamics of our crafts (changing battery size or type, adding or removing equipment/cameras or such, unballanced payloads) with out the painful experimentation of readjusting PID's. Is this something you see being able to incorporate in the future?

---

I have taken the first steps in the direction of what you are suggesting. I am able to measure the LaPlace transform of the tilt dynamics from the available data, without having to disturb the controls in any way. Attached is the result for my draganflier.

download https://groups.google.com/group/uavdevboard/attach/f1262cbb41e41da5/draganFlierTiltImpulseFunction.pdf?part=4

Loitering
https://groups.google.com/group/uavdevboard/browse_frm/thread/4a39758ad7783616

Rudder steering
https://groups.google.com/group/uavdevboard/browse_frm/thread/9dc86580cb9aaeed

Your issue could well be due to wind gain adjustment. Are you flying in windy conditions ? In this case I could bet that turning into the wind the plane turns too much. Why don't you use rudder navigation / stabilization, which for those planes is definitely better working than ailerons ? I mean combined with ailerons :) You use yaw stabilization with ailerons, wich could let some more problems (e.g. adverse yaw, so if the plane yaws left, the left aileron goes down to counteract and increase even more the drag on the left).
 * I would suggest as a starting point to disable wind gain adjustment. Then try to implement rudder, which in a high wing plane is really effective.

Solution in last post was to use only rudder steering, usisg teh ailerons for leveling the plane. Use the correct such as Inverted_v-tail

Cub landing
short landing with flaps cub peter hollands. Use large flaps to land plane in very short space. Same idea as Israel uavs, plane comes in low flares flaps.
 * http://diydrones.com/forum/topics/landing-on-a-forest-clearing-or-on-a-short-field-in-general
 * http://www.diydrones.com/profiles/blogs/openrelief-uses-apm-raspberry-pi-to-build-disaster-imaging-uav openrelief people detection

Stabilization channel bug
https://groups.google.com/group/uavdevboard/browse_frm/thread/7a6f38105cc523e7 solution at post 22

Flexifunctions
https://groups.google.com/group/uavdevboard/browse_frm/thread/40435c933c47ff55/18da45fc9c29c0f5#18da45fc9c29c0f5 flexifunctions

https://groups.google.com/group/uavdevboard/browse_frm/thread/dcdae50ce234576a#

https://groups.google.com/forum/?fr***roups#!topic/uavdevboard/3NrlDOI0V2o%5B1-25%5D

Wind vector and magnetometer
https://groups.google.com/forum/#!topic/uavdevboard/YGKHoadfsNM

My view is as follows:- 1) Absolute Position: is largely down to the accuracy of the GPS, which can be as good as +/- 2 meters in the horizontal dimension. In the vertical dimension GPS accuracy is much worse, anywhere between +/ 10m through to +/- 100 meters depending on reflections and atmosphere. relative Position: I note generally that products like "Air Dog" have found that for Quads that follow and film moving people, that GPS has not proved satisfactory, and so they are building other devices to broadcast relative positioning.

2) Orientation: The primary method of horizontal yaw orientation for MatrixPilot has been to use the GPS Course Over the Ground (COG), adjusted for the wind vector (when flying), to then calibrate the yaw gyros (or to me more accurate the yaw of the Direction Cosine Matrix). That relies on a good COG which requires descent horizontal movement. You may not have good COG on a boat if it is moving very slowly. Our accuracy when flying is largely down to the accuracy of the estimation of the wind vector, as the COG is accurate to better than 1 degree, but the wind vector estimation may not be that accurate.

We do also support a magnetometer (3 dimensional compass). However in practice it is only required on planes for situations like initial take off (before the GPS is moving and so we have no COG at that stage). The magnetometer so far has proved to be inaccurate. It is hard to get it to be consistently as good as + / 20 degrees in orientation in the earth yaw reference for all orientations of the plane. So you see the GPS COG approach, combined with wind estimation, has been much better for us (and simpler).

The standard frame rate of the IMU is 40Hz. All positions and orientation are calculated 40 times / second. The GPS may only be updating at 1, 2 or 4Hz, but the IMU uses a technique of dead reckoning to integrate the accelerometers (twice) to create a dead reckoning position between GPS updates. If you use MAVLINK (the binary protocol) you will be able to push more telemetry / second down the wire (or wireless), and should be able to easily get to 8 updates per second. For some application Mark Whitehon, on his special mw4 branch with updated OpenLog firmware, records telemetry at 200Hz. (e.g. accleeromter and gyro information). I have seen that in practice, Ascii telemetry, compared to binary telemetry, is about half as efficient on bandwidth.

The summary is that Bill Premerlani has primarily designed the IMU for aircraft use and he was determined to find the simplest hardware solution. So the result is that the IMU is probably most suitable for aircraft use at the moment (and rockets where he has helped some enthusiasts).

Set failsafe
Another thing I did wrong with the autopilot but this time a possible cause for the Cularis to crash. I had updated the options file but forgotten to set the failsafe minimum correctly.

Links
Robotics and drones landing page

http://diydrones.com/profiles/blogs/matlabsimulinkavl-simulator?id=705844%3ABlogPost%3A140105&page=9#comments  Matlab issues

http://rusdrones.ru Catapult launching pitch errors.

Gentlenav forums