Gentlenav

=== Code base ===
https://groups.google.com/forum/#!forum/uavdevboard 
https://groups.google.com/forum/#!forum/uavdevboard-dev 
https://github.com/MatrixPilot/MatrixPilot 
https://octopilot.com/index.php?main_page=product_info&products_id=3 purchase flight controller 
https://github.com/KeesGuijt/MatrixPilot Fork by KeesGuijt 
=== energycontrol ===
Matrix Kalman Airspeed control using potential and kinetic energy as per the journal papers by Robert Mahoney(Gimbal_lock#Robert_Mahoney and Paul G. Savage Uav_coning#paulsavage.(Strapdown Inertial Navigation Integration Algorithm Design) . Ardupilot does automated PID control calibration(hour flight) for each specific fixedwing airframe(integral windup), only Gentlenav potential,kinetic energy control(using PD control) doesn't need to do this. Nick rehm proposes splitting the flight controller cpu from the flight computer cpu. Hackflight and ardupilot are trying to sell single hardware solutions as per their business model .
Use Invertedvtail frame to negate the effects of stormy winds. 
Gentlenav suppliers 
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 
Gentlenav VTOL Avoid Euler angles 
DCM and quaternion rmat.c file 
Ground robot 
Data fusion 
Python integration 
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 X8 flying wing, pitch drift issue. 
options.h for airframe. 
=== 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.
=== 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/fastRotations.pdf 
https://web.archive.org/web/20160410075904/http://gentlenav.googlecode.com/files/fastRotations.pdf backup pdf 
http://gentlenav.googlecode.com/files/WindEstimation.pdf or backup https://web.archive.org/web/20160410075905/http://gentlenav.googlecode.com/files/WindEstimation.pdf 
https://www.coursehero.com/file/59870053/DCMDraft2pdf/ 
* 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<http://gentlenav.googlecode.com/files/MagnetometerRealignment.pdf> . 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#Usenet_post1
* 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
<http://www.diydrones.com/page/uav-devboard>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
<http://www.diydrones.com/profiles/blogs/sustained-rotations-pushing> 
=== 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 ===
* http://diydrones.com/forum/topics/landing-on-a-forest-clearing-or-on-a-short-field-in-general
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://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
Category:Uav airframe
Category:Sasecurity
Category:Uav project
Category:Gentlenav
Category:Gps
Category:Gentlenav magnetometer
Category:Matrix pilot