Code base Edit

Sections Edit

Matrix pilot features Edit

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#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

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 Edit!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 Edit!topic/drones-discuss/2KGOMKFZKUQ Yaw

Andrew Tridgell Edit

Attitude problems Edit

Construction details Edit

Configuring hardware, udb imu, servo's etc.

Quad test frame Edit Test frame used for quads

Dead reckoning Edit

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 Edit Raven 3d plane in strong winds!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.

Best regards, Phil

Logo flight plans Edit

Fixed wing , Matrix pilot best solution Edit

  • 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 Edit

Sustained rotationsEdit

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.

Mavlink Edit

Temperature effects Edit

Temperature gyro

Calibration Edit

Channel reversing Edit

Losing GPS lock Edit

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 Edit GPS orientation and installation of boards

Asymmetric elevator response Edit

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 Edit In flight PID tuning and 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 are those (0.068 at 60° / 6V). . 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 Edit

Usenet post1 Edit

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

Dealing with white noise Edit

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 Edit

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

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 Edit

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.


Loitering Edit

Rudder steering Edit

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 Edit

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.

Stabilization channel bug Edit solution at post 22

Flexifunctions Edit flexifunctions***roups#!topic/uavdevboard/3NrlDOI0V2o%5B1-25%5D

Wind vector and magnetometer Edit!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 Edit

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 Edit Matlab issues Catapult launching pitch errors.

Gentlenav forums

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.