Improve IMU responsiveness, refactor #13373

ctzsnooze · 2024-02-17T01:59:54Z

Has been tested, and works well. Rebased to master on 24th March 2024.

The goal is for the arrow to be quicker in responding and to respond properly to roll-dominant turns. This applies to both wings and quads.

@limonspb noted that on his Wing, the 'Heading' arrow in the OSD was very slow to respond. After some investigation, and after simple changes to increase the rate of adaptation for IMU to GPS values, a small improvement was made.

However further testing with quads revealed that while the IMU code responded very quickly, and correctly, to 'pure' yaw inputs, it responded very slowly, and incorrectly, when the inputs were primarily roll type inputs, and also seemed to go wrong when a pitch input was applied after a roll input. I then confirmed the same issues in quads.

Note that this PR:

Includes PR13379, to use heading error calculated from the quad's X axis orientation, not the Z axis orientation.
Should make the arrow / heading estimate change more quickly and more accurately
Should not change GPS Rescue behaviour.

Test by flashing and flying with a known good GPS setup. Log to ATTITUDE debug. While watching the arrow, test the following:

sudden yaw only inputs
sudden coordinated roll/pitch turns
snap 180 degree heading reversal, while travelling fast forward, then go flat and drift backwards
intentionally flying 'sideways', with persistent roll input
intentionally flying 'backwards' (pitched back).
Ideally the arrow should be OK.
Also try inverted slow pitch or roll loops and check the arrow behaviour when inverted. Wing pilots can evaluate arrow behaviour in sustained inverted flight.
Compare to 4.5 Master and to 4.4 if you have it.

Changes to date:

modifies the ATTITUDE debug so that we can investigate the Roll/Pitch problem more effectively; use it when testing this issue.
increases the primary Gyro/IMU <--> GPS ez_eg gain modifier, groundspeedGain , to a max of 10x (up from 2x) at a max of 10m/s, see graph below. It uses an exponential curve to reject GPS data at very low groundspeed more strongly.
introduces three more ez_ef gain factors, suppressing ez_ef in situations where we know the GPS course over ground heading will not likely reflect the heading of the craft:
(1) Suppress ez_ef during, and soon after, fast yaw stick inputs. A very fast yaw input will rotate the quad, changing heading immediately, but the craft will still drift on its original path for some time. This factor stops the heading being incorrectly modified by GPS heading for about 2-3s after a fast yaw input
(2) Suppress ez_efwhen the quad is not flat on the roll axis. If the user adds roll angle to a quad, it will start to fly 'sideways', and the GPS heading will track a course over ground that will not be consistent with the heading of the quad. So we suppress the GPS adaptation completely when Roll exceeds 12 degrees, so that you only get a GPS heading correction when Roll angle is essentially flat to the horizon. The allowed angle for wings is 25 degrees because they can't drift like a quad.
(3) Suppress ez_ef when the quad's pitch attitude is flat, or pitched backwards, so that the quad will only adapt it's heading to GPS heading when pitched forward, which typically suggests that the quad is flying nose forward. This stops errors arising from drift from wind or prior non-forward flight when the quad is flat, and stops errors developing when a quad is flown with negative pitch angle (backwards). Note this pitch factor is not used for wings, since they fly forwards very nicely at a zero pitch angle.
All three of these gain factors are multiplied together, so that we get a kind of overall assessment of the likelihood that the GPS heading is likely to be useful. At times, ez_ef will be zero, and the gps data will not be considered, until such time as we assess that the quad is likely to be flying 'nose forward' at some decent speed.
fixes an issue where an integer division resulted in abrupt steps in cogYawGain.
changes and simplifies the logic relating to the one-off inflight re-calibration of the quaternion, so that in-flight re-calibration won't happen until there is at least 1m/s forward speed, previously even a transient speed of 1m/s would trigger this, and that could happen while carrying the quad around before takeoff. Not sure what that code achieves, but we can now more readily find out.
Holds ez_ef at zero - GPS heading ignored - until there is at least 1m/s forward speed. Once that threshold is reached, the code considers any GPS heading value. At very low speeds, the gpsGroundspeedGain factor is very close to zero and acts like a lowpass filter on ez_ef. This works well.

With this PR, this image shows a quick coordinated turn while pitched forward. Note that IMU heading changes immediately we start the yaw+roll on gyro, and stay nearly constant once the roll and yaw gyros settle. The IMU heading changes way ahead of GPS. Once we complete the turn, the IMU heading is stable, and after a few seconds, the two heading readings become similar....

Notes about the IMU heading error with roll inputs

This image is without the PR. It again is a coordinated turn. However, notice that the IMU estimate lags both the GPS data and lags the gyro changes a lot.

This image shows two pure yaw inputs, with rapid, accurate, and immediate IMU heading changes, but then with a coordinated, primarily roll turn, we see a lot of IMU heading lag, IMU heading overshoot, and a biphasic ez_ef trace, none of which should be happening:

This image shows a pure yaw input followed by pitch forward to fly back along the same path. Note that the IMU heading changes perfectly with the Yaw input, but as soon as we pitch forward, we get a big ez_ef error and the 'correct' heading change is kind of taken away transiently, only being restored later on by an opposite ex_ef value:

These issues are fixed by changing the heading error value from the craft's X axis heading, and by modifying ez_ef gain parameters.

In PR#12792 the change was made to get heading error from Z axis (thrust vector) and I think that caused the roll/pitch heading issues. I regret not picking it up during GPS Rescue testing; with GPS Rescue, the majority of the heading changes are yaw dominant, and pitch/roll inputs are either minimal, constant, or transient.

Congratulations @limonspb for identifying the issue, testing extensively, and providing the logs that helped us identify the cause.

The PR has been tested quite a bit now, but still needs further review for coding and user edge cases.

github-actions · 2024-02-17T02:00:05Z

Do you want to test this code? You can flash it directly from Betaflight Configurator:

Simply put #13373 (this pull request number) in the Select commit field of the Configurator firmware flasher tab (you need to Enable expert mode, Show release candidates and Development).

WARNING: It may be unstable. Use only for testing!

ctzsnooze · 2024-02-17T06:16:51Z

Revision of the yawCogGain, renamed to groundspeedGain makes for a very soft gain around centre, so that at low GPS speeds, the IMU will not react very much at all to GPS heading information. At higher speeds, groundspeedGain will rise to a max of 10, allowing much faster GPS scaling to GPS values.

Changing the value of GPS_COG_MIN_GROUNDSPEED alters inflexion point. Graph is shown with current value of 100 (1m/s). Unit gain is at about 3.3m/s. Max gain of 10x is reached at 10m/s.

freasy · 2024-02-17T07:44:56Z

@ledvinap I think you was working on this right? Any thoughts from you?

ledvinap · 2024-02-18T19:53:44Z

(on phone, quick reply only)

imu was changed to use thrust vector (projected to ground plane) as cog input. But only quadcopter is considered(it was relevant for RTH), so thrust is assumed up
Old code did use 'forward' vector.

it should be easy to adapt IMU code for airplane (use forward instead of up)

ctzsnooze · 2024-02-19T05:32:39Z

I'll put this PR aside as a refactor and for testing for 4.6, because @limonspb found that by using the non-thrust vector option, the arrow worked properly when roll inputs were significant. His PR is #13379.

I'll do testing of that change with quads on his PR. Since I also had issues with roll-only inputs in thrust mode, I anticipate that the body oriented mode will probably work better on quads also.

ctzsnooze · 2024-02-20T01:33:12Z

I included the fix for the the IMU attitude issue from #13379, and tested it (see 13379). Works really, really well.

ledvinap

There are useful ideas, but overall it is in 'layer heuristic over heuristic until it works in my case' direction.

ledvinap · 2024-02-21T11:40:49Z

src/main/flight/imu.c

@@ -215,51 +213,79 @@ static float invSqrt(float x)
 STATIC_UNIT_TESTED void imuMahonyAHRSupdate(float dt, float gx, float gy, float gz,
                                bool useAcc, float ax, float ay, float az,
                                bool useMag,
-                                float cogYawGain, float courseOverGround, const float dcmKpGain)
+                                float gpsGroundspeedGain, float courseOverGround, const float dcmKpGain)


Old code kept non-imu factors outside of IMU code.

?? not clear what you mean ??

The old code always had courseOverGround as an input, the sole source of which was GPS.

The old code named the primary (and only) ez_ef gain modifier as cogYawGain. In reality, this parameter depended only on GPS groundspeed. All I did here was to re-name that parameter in a way that explain what it does better; this is important if we introduce other ez_ef gain modifiers from different sources.

This (https://github.com/betaflight/betaflight/blob/master/src/main/flight/imu.c#L545-L557) does not depend 'only on GPS groundspeed' ...

What about courseOverGroundGain?

However in those lines, it is clear that cogYawGain, other than in a rescue, is only determined by groundspeed:

const float imuYawGroundspeed = fminf (gpsSol.groundSpeed / GPS_COG_MAX_GROUNDSPEED, 2.0f); cogYawGain = (FLIGHT_MODE(GPS_RESCUE_MODE)) ? gpsRescueGetImuYawCogGain() : imuYawGroundspeed;

That's why I said that the cogYawGain factor is only a groundspeed factor.
It's not a bad thing to use groundspeed as a factor in the gain factor ez_ef, since GPS heading data is very noisy and inaccurate at low speeds, and higher speeds are typically in the direction of the nose of the quad and less influenced by wind.
This factor is is zero at zero groundspeed, rises as groundspeed increases, and has no input other than groundspeed.
We refer to these factors as:

sol->groundSpeed = data->speed; sol->groundCourse = data->ground_course;

where groundCourse and Course Over Ground refer to angle or heading.
Hence some indication, in the name, that this is a groundspeed factor, will make its purpose more clear, especially if we use other factors to modulate ez_ef as well as groundspeed.

especially if we use other factors to modulate ez_ef as well as groundspeed

But those factors can be simply multiplied into courseOverGroundGain. IMU code does not care, is is just external gain factor.

Good idea to separate the gain factors clearly.

ledvinap · 2024-02-21T11:42:54Z

src/main/flight/imu.c


-        // Compute heading vector in EF from scalar CoG. CoG is clockwise from North


It wasn't easy to get these comments mostly correct. Please don't remove math-related ones. But explaining/augmenting is very welcome

I'll put back any that you recommend returning. Apologies if some were inappropriately removed.

I think we should split some commentary into separate section/file. Repeating elementary vector math here takes too much space and makes code harder to follow.

ledvinap · 2024-02-21T11:45:18Z

src/main/flight/imu.c


-        // Compute heading vector in EF from scalar CoG. CoG is clockwise from North
-        // Note that Earth frame X is pointing north and sin/cos argument is anticlockwise
+    // *** Calculate and correct IMU heading from GPS values once min groundspeed exceeded ***


From IMU perspective, CoG source is irrelevant. IMU code is alreagy quite hard to follow, don't pull in another code unless necessary

Currently the only alternative source of heading vector is Mag, and it is handled very differently, in a different part of this function.
From what I could see, this part of the code compares the existing IMU heading to the GPS heading; there is no other heading information to consider, here, other than GPS heading.

It is easier to reason about GPS heading and its gain factor in GPS code.

gps.c code doesn't know or care about IMU heading. It just returns the simple heading information as supplied by the GPS module. There is no gain factor required in the GPS code?

ledvinap · 2024-02-21T11:45:59Z

src/main/flight/imu.c

-        // cross product = 1 * |heading| * sin(angle) (magnitude of Z vector in 3D)
-        // order operands so that rotation is in direction of zero error
+
+        // Compute IMU / craft heading vector and magnitude in body X axis


Suggested change

// Compute IMU / craft heading vector and magnitude in body X axis

// Compute IMU / craft heading vector and magnitude from body X axis

@ledvinap Can I clarify that this is the earth referenced heading vector of the X axis of the quad, the magnitude of which will be attenuated by increasing pitch angle?

ledvinap · 2024-02-21T11:49:02Z

src/main/flight/imu.c

+
+        // cross (product) = heading * cogHeading * sin error angle, ie, reflects error angle of quad X axis vs GPS groundspeed
+        // cross value sign depends on the rotation change from input to output vectors by right hand rule
+        // operand order is such that rotation is in direction of zero error


Order is rearranged to make this work. In classic IMU math, error would be opposite

ledvinap · 2024-02-21T12:10:02Z

src/main/flight/imu.c

+        // for error angles less than 90 degrees (dot > 0), use cross value to compute ez_ef
+        // above 90 degrees error, use heading vector magnitude, but give it sign from cross product
+        // heading vector magnitude is 1.0 when flat, and is attenuated when pitch angle is large
+        // when error exceeds 90 degrees, and pitch angle is high, a transient step may occur in ez_ef


There should be no transient (see above). Is is a bug otherwise

My interpretation was that heading magnitude is 1.0 * pitch angle, but cross, after this refactoring, doesn't care about pitch angle. The transition between the two happens at 90 degree heading difference. So I was concerned that at this point, we swap between two quite different values, which could lead to a sudden change in ez_ef. I guess I am not understanding the code quite well enough.

At 90deg it changes from sin(90) to sign(90) -> 1 to 1. No discontinuity here

Even when the quad is, say, pitched forward at 45 degrees when we make this transition?
You previously made a note that headingMagnitude is reduced towards zero in the presence of a non-zero pitch angle. Wouldn't headingMagnitude be around 0.7 when pitch angle is 45 degrees? Meaning an abrupt transition from 1.0 to 0.7?
Maybe the note:
// Important: vector magnitude is reduced as pitch increases
Does not apply because we are now calculating heading in body X axis?
// Compute IMU / craft heading vector and magnitude in body X axis

cross product already has headingMagnitude factored in, it will be around .7 at 90 deg ( [1 0] cross [0 0.7] == 0.7 )

This is very confusing. How can we use the cross value as an effective measure of the angular error of the heading, if it changes with pitch? The current code sets ez_ef to cross. But if cross changes just with a pitch input, and nothing else, and we know that a pure pitch change does not change heading - how can that work?

But ez_ef is error estimate. Normally, it is zero and pitch has no influence.
It is similar to changing P factor of PID - when you halve it, error of smaller, but PID still works.

ledvinap · 2024-02-21T12:11:02Z

src/main/flight/imu.c

+        // Compute IMU / craft heading vector and magnitude in body X axis
+        // Important:  vector magnitude is reduced as pitch increases
+        const fpVector2_t heading_ef = {.x = rMat[0][0], .y = rMat[1][0]};
+        const float headingMagnitude = vector2Mag(&heading_ef);


(it was close to it's use intentionally)

ledvinap · 2024-02-21T12:15:28Z

src/main/flight/imu.c

+
+        const fpVector2_t thrustVectorEF = {.x = rMat[X][Z], .y = rMat[Y][Z]};
+        // body Z axis (up) - direction of thrust vector - 0-1
+        // magnitude is closer to 1 when thrust is 'forward', closer to 0 when thrust is 'backward'


zero when level, 1 at +-90 pitch.

I was hoping for a value that would be positive when the thrust vector would cause acceleration of the craft in the earth frame, decreasing to zero when there is no contribution (quad is flat to earth frame), and that does not increase above zero when the thrust vector would cause deceleration of the quad in its forward earth frame direction.

It sounds like thrustVectorEF needs a way to stop it rising when thrust is 'backward'.

You can project earth-frame Up vector into body coordinates and then on X axis.
IIRC Z axis projection is {.x = rMat[Z][X], .y = rMat[Z][Y], .z = rMat[Z][Z] } and you only want X component, so rMat[Z][X]. But I did not test it

My problem is that these abstraction levels are over my head. I do understand the flight requirements, very well, but matrix maths is something I never grasp properly.

This ChatGPT answer is quite useful. I did not check, maybe rows/columns are swapped in BF:

Understanding the Rotation Matrix

The rotation matrix (R) is a square matrix used to rotate vectors in a three-dimensional space. It is composed of elements that directly correspond to the axes of the two coordinate systems involved: the body frame (local frame attached to a moving body, for example, an aircraft or a drone) and the Earth frame (a fixed, global frame, often aligned with the North, East, and Down directions).

In a rotation matrix (R), each column represents the unit vectors of the body frame axes expressed in the Earth frame. Conversely, each row represents the unit vectors of the Earth frame axes expressed in the body frame. This duality is key to understanding how the rotation matrix facilitates the transformation between the two frames.

Practical Implications

Column Interpretation:

First Column: Represents the orientation of the body's x-axis in Earth coordinates. Essentially, it tells you how much of the body's x-axis aligns with the Earth's x, y, and z axes.

Second Column: Represents the orientation of the body's y-axis in Earth coordinates, similarly describing its alignment with the Earth's axes.

Third Column: Represents the orientation of the body's z-axis in Earth coordinates, again describing its alignment.

Row Interpretation:

First Row: Tells you how the Earth's x-axis is represented in the body frame, indicating the projection of the Earth's x-axis onto the body's axes.

Second Row: Similar to the first, but for the Earth's y-axis.

Third Row: For the Earth's z-axis.

Practical Use

Vector Transformation: If you have a vector expressed in the body frame and you want to know its coordinates in the Earth frame, you multiply the rotation matrix (R) by this vector. This operation essentially sums up the contributions of each body axis to the Earth frame axes.

Understanding Orientation: By examining the rotation matrix, you can deduce the orientation of the body relative to the Earth. For example, if one of the columns is primarily aligned with one of the Earth's axes, the body is mainly oriented along that Earth axis.

Sensor Data Interpretation: For sensors fixed on a body (like a drone), their readings (acceleration, magnetic field, etc.) are in the body frame. To interpret these readings correctly in a global context (e.g., for navigation), you need to transform them into the Earth frame using the rotation matrix.

ledvinap · 2024-02-21T12:21:18Z

src/main/flight/imu.c

+                // - heavily average GPS heading values at low speed, since they are random, almost
+                // - respond more quickly at higher speeds.
+                // GPS typically returns quite good heading estimates at or above 0.5- 1.0 m/s, quite solid by 2m/s
+                // gpsGroundspeedGain will be 0 at 0.0m/s, rising slowly towards 1.0 at 1.0 m/s, and reaching max of 10.0 at 10m/s


It is easier to reason about IMU when gain is between 0 and 1.

Yes, however this factor requires stronger relative weighting than the others, since in flat stable forward flight, when the other factors are both 1.0, GPS groundspeed is a crucial parameter for the accuracy of the GPS heading value.

Ok.

Guessing a bit, for reference only:

Ideally, overall IMU gain would be close to 1 (and possibly removed completely) - minimizing (small, linear region) error in single step. Then different error sources would use gain associated with desired time constants. Then it would be a bit easier to reason about gain used.

Yes it is very complex. Each axis must, I think, have different weighting.

ledvinap · 2024-02-21T12:25:44Z

src/main/flight/imu.c

+                gpsGroundspeedGain = speedRatio > 1.0f ? fminf(speedRatio, 10.0f) : speedRatio * speedRatio;
+            }
+        } else if (gpsSol.groundSpeed > GPS_COG_MIN_GROUNDSPEED) {
+            // Reset the reference and reinitialize quaternion factors when GPS groundspeed > 2.0 m/s
            imuComputeQuaternionFromRPY(&qP, attitude.values.roll, attitude.values.pitch, gpsSol.groundCourse);


This will cause large jump in heading, possibly confusing code that depends on heading. But ramping heading by big gain may be even worse, so keep it for now

I noticed this and wondered why it was there. In early logs there was no change in ez_ef or indeed anything I could see when this re-initialisation took place. It seemed strange but I just left it there. I figured it needed to be performed when the quad was moving, but in the previous code it was possible that it would have been performed while the quad was still, or while moving, and that doesn't seem right.

old code did protect it by gpsSol.groundSpeed >= GPS_COG_MIN_GROUNDSPEED

Ah yes you are right, it did. Apologies.
@ledvinap Could I ask you more about this 'reset the reference' idea?
Currently the quad's IMU heading defaults to North (0).
If the pilot arms and then takes off and flies due North, the IMU heading, and arrow, are already 'correct' from the moment of takeoff, and there is little or no GPS adjustment required.
But if they arm and fly South, then the IMU heading is initially 180 degrees different from the flightpath South. It then takes quite a long time, at least several seconds, as a result of the IMU lag and the slow initial speed, for the IMU code to rotate the heading from North to South, to align correctly with the flightpath over ground.
It occurred to me that it would be quicker if we could use this once-only 'reset the reference' function to force IMU heading to match the GPS heading. Then when we take off, our heading will be wrong until we get some groundspeed, then jump to the initial flightpath, directly.
I wonder if you could perhaps explain how we might do that, at this point in the code?

IMO we should remove it. The jump may affect control loops, in very unpredictable way (quad is armed, the change can happen any time).

It is possible to increase groundspeedGain in place of gpsHeadingInitialized and bleed it over some time. Bleeding factor can be based on calculated groundspeedGain (similar to complementary filters).

ledvinap · 2024-02-21T14:34:12Z

As for unrelated code in IMU - that part is not negotiable on my end. I used far too much F-words when making at least partial sense of IMU ...

ctzsnooze · 2024-02-22T02:08:19Z

@ledvinap
I think that from a 'thrust vector' perspective, in the earth frame, we need the following:

for the Pitch axis, a pitch thrust vector value that becomes 1.0 when pitched maximally 'nose forward', falling (slowly, if possible) to become 0.0 when flat, and that returns a negative value when pitched backwards (or, if it returns a positive value, some way to detect the situation where we are pitched backwards). We then limit this value to the 0-1 range. With a 1->0 value like this, what is really important is the 0.0 when flat or pushing backwards, because when flat on pitch, or backwards, we absolutely need ez_ef to be zero. In contrast, almost any forwards vector value is acceptable for normal ez_ef.
for the Roll axis, we need a value that is 0 when fully rolled, and 1.0 when flat. We can focus the Roll value, maybe using exponentials, eg Roll_Value^5, so that the presence of even a little bit of roll angle will quickly push this factor, to zero, and subsequently push ez_ef, to zero.

It's important to note that the presence of even a tiny bit of sideways thrust should suppress ez_ef, whereas even a small amount of pitch forward is good, and should allow ez_ef accumulation. They are totally different in this regard. For our purposes any pitch angle in excess of 10-20 degrees, in the absence of roll, will quickly generate a significant nose-forward speed and generally result in the GPS course over ground being a useful value.

If we multiply the pitch and roll factors, as derived above, we have a final value that will positive when pitched forward, and very low when there is almost any sideways element in the thrust vector.

For yaw, we want to inhibit ez_ef while yawing. Sustained yaw requires sustained stick position, so stick position, or yaw rate, can be used used reasonably effectively. We can forget about yaw if we have a factor of that kind.

An earth frame thrust vector analysis which tells us what proportion of the thrust is 'forwards' in the earth frame is helpful, but insufficient. Let me try to explain why. Any meaningful sustained roll angle will inevitably cause a quad to travel sideways at some decent velocity, and then we cannot use the GPS heading information to correct the IMU. We will just set the IMU heading incorrectly.

We could have a situation, for example, where we apply 10 degrees forward angle and 25 degrees sideways angle. The outcome, after a short time, would be a predominantly sideways course over ground. If no yaw was applied, there would be no heading change; the nose of the quad would point the same way all the time. We would not want the IMU to adapt to the GPS course over ground in this case.

If we suppressed ez_ef using strong inhibition in the presence of any Roll element, we would be OK. ez_ef should then be close to zero, and hopefully we won't fly sideways forever. In contrast, if we just looked for the presence of a forward component in the earth referenced thrust vector, we would find that we were angled forward 10 degrees, giving us a non-trivial forward thrust element, and we may conclude that ez_ef should not be driven to zero; this would not be OK, since we would reasonably soon falsely indicate a heading equal to the sideways travel direction, even when the nose was not pointing in that direction.

Hence we need to consider the roll / Y thrust element differently from the Pitch / X element. With Roll almost any roll thrust element we must quickly and strongly suppress the GPS heading contribution to the IMU whenever there is almost any roll input. We should only accept a Pitch forward element when the Roll element is basically flat.

ledvinap · 2024-02-22T10:16:53Z

An earth frame thrust vector analysis which tells us what proportion of the thrust is 'forwards' in the earth frame is helpful, but insufficient. Let me try to explain why. Any meaningful sustained roll angle will inevitably cause a quad to travel sideways at some decent velocity, and then we cannot use the GPS heading information to correct the IMU. We will just set the IMU heading incorrectly.

We could have a situation, for example, where we apply 10 degrees forward angle and 25 degrees sideways angle. The outcome, after a short time, would be a predominantly sideways course over ground. If no yaw was applied, there would be no heading change; the nose of the quad would point the same way all the time. We would not want the IMU to adapt to the GPS course over ground in this case.

That is why THRUST_COG was implemented.

It uses thrust to estimate (immediate) direction where quad is moving. There is no explicit 'forward', all directions are treated equally. Applying 'roll only' means that estimated direction is sideways. Applying roll + pitch in combination is resoled to correct direction (assuming symmetrical quad), this is done using quaternions/rotation matrix, so there is no Euler angle singularities.
This estimated direction is compared against CoG and if there is difference, IMU estimate is updated.
Yaw does not interfere with this calculation.

Problem with this mode is the 'immediate' estimate. When you fly forward fast, then set roll to zero and apply pitch, the code assumes that quad is immediately flying sideways. But actually, it will take some time to change course due to inertia, and incorrect heading update is performed during this time.

This is problematic when flying style makes this situation happens a lot. Using old 'forward' mode may work much better in that situation.

Rest is about THRUST_COG==0 mode. Is sounds like reasonable heuristic to avoid problems with this mode.

There is also 'airplane' mode. THRUST_COG==0 should work great for it without additional heuristics and should be enables when airplane mode is active.

tbolin · 2024-02-23T13:13:25Z

some thoughts I had from reading through the description and comments:

introduces a third ez_ef gain multiplier, based on stick movement: smoothedStickMovement. This gets absRcDeflection, a 0-1 value, on Roll and Yaw, and returns a value that quickly moves towards zero as stick deflection increases. A 'negative peak detector' is used with a sample and hold method with time constant of 2s to 'hold onto' significant stick inputs, to help suppress GPS integration for a second or so after a stick movement. This works faster than the thrust vector suppression but doesn't last as long. It helps deal with drift early on after high speed rapid stick inputs.

Why not use gyro rates instead of stick inputs?

I also think this could work even better with THRUST_COG == 1:
If the quad has recently been turning quickly the new direction of the quad will not be representative of the direction that it is moving.
Without any recent turning the quad will begin moving in the direction of the COG vector projected on the plane parallel to the earth.

introduces a second GPS <--> Gyro gain factor, thrustVectorAlignment, based on thrust vector magnitude by @ledvinap. This is a value between 0 and 1, increasing with greater thrust vector coincidence with GPS course over ground. It is also used as an ez_ef gain multiplier.

Now, I haven't looked at the implementation yet, but wouldn't it be easier to limit the magnitude of the error here?
I. e. if the angle between the quad vector (doesn't matter if it's the x or the z axis for this reasoning) and the GPS heading is greater than the limit, the angle error is set to the limit.

The reasoning would be that small errors can be treated as white noise, while large errors are more likely to be outliers and would cause annoying error spikes.

If it's hard to separate the angle from other factors in the error, then just limiting the magnitude of the error could work as well.

I think the idea is very similar, to what this PR is already doing, I just think limiting might be easier to reason around.

ledvinap · 2024-02-23T14:19:07Z

@tbolin:

quad has recently been turning quickly

Yes, but ideally turn rate in EarthFrame should be considered. That would bean using accelerometer data. Maybe just calculate component of ACC vector that is perpendicular to expected flight direction, projected to horizontal plane. And GPS course can be used as flight direction.

Extreme option is to run 'mini-simulator' that integrates thrust (or thrust + acc) measurement in 2D, providing continuous speed vector estimate. Technically simple, but probably overkill ...

ctzsnooze · 2024-02-24T00:01:46Z

@ledvinap @tbolin @limonspb
I've done quite a lot of work now, hopefully addressing most comments, and trying to put an overall structure around the ez_ef gain factors that make sense.

The modifiers are all essentially 'heuristic', no question.
They are needed in the IMU code to maintain the integrity of the IMU heading estimate in normal flight, as best we can.

It works very well in practice, with a quad.

GPS Rescue doesn't use any of the new modifiers so as to not affect what it does.
There are some wing-specific modifications.

I'm sure there are better ways of doing these things, but having reviewed the logs extensively, each gain modifier has its own strengths and weaknesses, so that we do need all of them. Using a multiplicative 'OR' works well, since if any of them is zero, then the gain is zero, and if all of them are weak, the gain gets very low. A Kalman filter tuned to accept these inputs with appropriate weighting would likely be the 'right way' to do it, but for now this code gets the job done.

Please see this video, done yesterday on a VERY hot day... it's very rough flying, with deliberate backwards drifts, some pitch loops and some fast inputs; the speed and accuracy of the arrow changes is very good.
https://www.youtube.com/watch?v=bz2mENnVDOo

limonspb · 2024-02-24T08:42:29Z

@ledvinap @tbolin @limonspb I've done quite a lot of work now, hopefully addressing most comments, and trying to put an overall structure around the ez_ef gain factors that make sense.

The modifiers are all essentially 'heuristic', no question. They are needed in the IMU code to maintain the integrity of the IMU heading estimate in normal flight, as best we can.

It works very well in practice, with a quad.

GPS Rescue doesn't use any of the new modifiers so as to not affect what it does. There are some wing-specific modifications.

I'm sure there are better ways of doing these things, but having reviewed the logs extensively, each gain modifier has its own strengths and weaknesses, so that we do need all of them. Using a multiplicative 'OR' works well, since if any of them is zero, then the gain is zero, and if all of them are weak, the gain gets very low. A Kalman filter tuned to accept these inputs with appropriate weighting would likely be the 'right way' to do it, but for now this code gets the job done.

Please see this video, done yesterday on a VERY hot day... it's very rough flying, with deliberate backwards drifts, some pitch loops and some fast inputs; the speed and accuracy of the arrow changes is very good. https://www.youtube.com/watch?v=bz2mENnVDOo

I will be testing this weekend both on a quad and on a wing. Thanks for all your work.
The question, if we can bring your changes to 4.5.

I think it's kind of a fix, because the current master home arrow can cause problems...

limonspb · 2024-02-24T23:27:02Z

@ctzsnooze this is a bbx with quad + this PR. I noticed flying backwards messes up the home arrow. Other than that it looks good.
ctz_rp_quad.BBL.txt

My wing refuses to record bbx on SD card, shows 0kb files. But on a wing all works as expected.
Launching a wing straight to south makes arrow show wrong at start, but after a second or two it fixes itself.

A side note situation:

You fly straight, lets say home is on your left.
Then you do roll 180, so now you are up side down (but flying same direction).
Now home is on your right relative to what you see.
But home arrow on OSD still points left:

ctzsnooze · 2024-02-26T00:14:58Z

Thanks @limonspb - I made a stupid beginner programming error that prevented the backwards pitch angle inhibition from working. Your test shows that backwards pitch angle inhibition is vital to prevent the arrow going wrong when flying backwards!
Fixed in 5c1c51d
I also had time now to fully flight test this.
Can confirm no adverse effect on GPS rescues.

Thanks for discussing the arrow direction also. That's very tricky.

We know now that the IMU heading is correct, even when inverted, from the testing we've done. We have found something a bit strange.

We see that in a pitch back in a loop, and start with arrow down / nose away from home, at the vertical and nose down points, the arrow reverses. So that while inverted, with the nose pointing to home, the arrow points to home. This is, I think, correct behaviour, because, in this case, while inverted, home is straight ahead. When we flatten out the arrow rotates to downwards once the quad returns to normal orientation. Heading values also reverse when inverted, consistent with the change in heading at the vertical points. All good.

When we roll the quad 360 degrees, heading doesn't change and arrow keeps constant orientation in the OSD. IMU angle says constant. That's all good also.

However... when we look towards home, with home offset say to the right, and roll inverted, the arrow stays right, but the sky is on the bottom, and 'home' is now to the left on the screen. So the arrow points rightwards, since IMU heading has not changed, but home is on the left of the screen. And that's not quite right.

So this is an 'arrow' error, not an IMU error. I'm not sure how to fix that; if we have the intent that the arrow points to home while inverted, we will need to move the arrow depending on vertical orientation of the quad when it is not pointing straight ahead or straight back it will need to be rotated to the opposite direction as we roll. That will require some thinking :-)

ledvinap

At least separate the code into function...

src/main/common/vector.h

ledvinap · 2024-02-26T12:28:34Z

src/main/flight/imu.c

@@ -215,41 +213,96 @@ static float invSqrt(float x)
 STATIC_UNIT_TESTED void imuMahonyAHRSupdate(float dt, float gx, float gy, float gz,
                                bool useAcc, float ax, float ay, float az,
                                bool useMag,
-                                float cogYawGain, float courseOverGround, const float dcmKpGain)
+                                float groundspeedGain, float courseOverGround, const float dcmKpGain)


At least separate new code into function and call it from imuCalculateEstimatedAttitude. Mahony input may be ez_ef.

I'll try but I'm not good at that sort of thing.

see ctzsnooze#22

src/main/flight/imu.c

ledvinap · 2024-02-26T12:44:39Z

src/main/flight/imu.c

+                gpsGroundspeedGain = speedRatio > 1.0f ? fminf(speedRatio, 10.0f) : speedRatio * speedRatio;
+            }
+        } else if (gpsSol.groundSpeed > GPS_COG_MIN_GROUNDSPEED) {
+            // Reset the reference and reinitialize quaternion factors when GPS groundspeed > 2.0 m/s
            imuComputeQuaternionFromRPY(&qP, attitude.values.roll, attitude.values.pitch, gpsSol.groundCourse);


old code did protect it by gpsSol.groundSpeed >= GPS_COG_MIN_GROUNDSPEED

src/main/flight/imu.c

limonspb · 2024-02-28T00:11:06Z

@ctzsnooze a new bbx from a quad with the current PR state
ctz PR quad 2 - gps rescue.BBL.txt

Everything works good. Flying backwards, sideways, arrow OK
GPS rescue OK

ctzsnooze · 2024-03-26T00:11:04Z

Thanks @BrandonsBakedBeans @limonspb for testing and confirming the improved behaviour.

My apologies about being slow to rebase to master. It's done now - thanks @nerdCopter for the heads up about arming lock issue. If that's now resolved now it's rebased, I think the PR is ready for merging. It's a definite improvement.

@ledvinap @haslinghuis pls confirm that it's good to go, thanks.

KarateBrot · 2024-03-26T11:53:45Z

src/main/flight/imu.c

@@ -258,8 +308,8 @@ STATIC_UNIT_TESTED void imuMahonyAHRSupdate(float dt, float gx, float gy, float
        DEBUG_SET(DEBUG_ATTITUDE, 3, (ez_ef * 100));
    }

-    DEBUG_SET(DEBUG_ATTITUDE, 2, cogYawGain * 100.0f);
-    DEBUG_SET(DEBUG_ATTITUDE, 7, (dcmKpGain * 100));
+    DEBUG_SET(DEBUG_ATTITUDE, 2, lrintf(groundspeedGain * 100.0f));


Oh, my bad. I have mistaken index number 1 with index number 2

ledvinap · 2024-03-26T15:34:32Z

@ctzsnooze : Can you look at ctzsnooze#22

It's mostly refactoring, but I did change some comments and parts of code. DEBUG is probably affected, with some values logged only when actually used.

src/main/flight/imu.c

ledvinap · 2024-03-26T15:38:40Z

src/main/flight/imu.c

@@ -215,41 +213,96 @@ static float invSqrt(float x)
 STATIC_UNIT_TESTED void imuMahonyAHRSupdate(float dt, float gx, float gy, float gz,
                                bool useAcc, float ax, float ay, float az,
                                bool useMag,
-                                float cogYawGain, float courseOverGround, const float dcmKpGain)
+                                float groundspeedGain, float courseOverGround, const float dcmKpGain)


see ctzsnooze#22

ledvinap · 2024-03-26T15:41:23Z

src/main/flight/imu.c


-        // Compute heading vector in EF from scalar CoG. CoG is clockwise from North


I think we should split some commentary into separate section/file. Repeating elementary vector math here takes too much space and makes code harder to follow.

ledvinap · 2024-03-26T15:44:01Z

src/main/flight/imu.c

+                gpsGroundspeedGain = speedRatio > 1.0f ? fminf(speedRatio, 10.0f) : speedRatio * speedRatio;
+            }
+        } else if (gpsSol.groundSpeed > GPS_COG_MIN_GROUNDSPEED) {
+            // Reset the reference and reinitialize quaternion factors when GPS groundspeed > 2.0 m/s
            imuComputeQuaternionFromRPY(&qP, attitude.values.roll, attitude.values.pitch, gpsSol.groundCourse);


IMO we should remove it. The jump may affect control loops, in very unpredictable way (quad is armed, the change can happen any time).

It is possible to increase groundspeedGain in place of gpsHeadingInitialized and bleed it over some time. Bleeding factor can be based on calculated groundspeedGain (similar to complementary filters).

BrandonsBakedBeans · 2024-03-26T22:35:01Z

Produces a LOAD arming prevention flag on a skystars f405 at 3.2khz and also at 1.6khz. f722 and f745 seem fine just looking at flags, but the f405 was what I grabbed to go to the field with so its all I have tried so far.

I think that's might be cuz PR is not up to date with latest 4.5. there was a PR for this fix.

What you think, @ctzsnooze ?

Arming now on the f405 with the rebase pr. I triggered rescue in all sorts of orientations and heading was correct or within 15-20 degrees of correct instantly. Seems pretty reliable so far.

ctzsnooze · 2024-03-27T00:22:08Z

@ledvinap - thank you, your PR22 is very welcome.

The refactoring results in much tidier code, for sure. There are a LOT of changes, though!

I had intended that this PR could perhaps be merged within the next few days, without the extensive refactoring from PR22, since it has been flight tested, fixes the 'bug' for wings, and is ready to go. If that happens I can get wider testing and feedback on the functional changes of this PR, using the debugs and so on that I know well, and without concern that refactoring may have changed something.

If we did hold off on applying PR22, I will definitely make a refactoring PR with all the changes in PR22.

Would you be OK with that approach? It gives us plenty of time to test this very substantial refactoring very carefully.

Or should I go ahead and refactor now, and see if we can get that additional testing done for a subsequent 4.5 RC?

ledvinap · 2024-03-27T09:11:07Z

src/main/flight/imu.c

+            const bool isWing = isFixedWing();
+
+            // 2. suppress ez_ef during and after yaw inputs, down to zero at 100% yaw
+            const float yawStickDeflectionInv = 1.0f - getRcDeflectionAbs(FD_YAW);
+            float stickDeflectionFactor = power5(yawStickDeflectionInv);
+            // negative peak detector with decay over a 2.5s time constant, to sustain the suppression
+            static float prev = 0.0f;
+            const float k = 0.4f * dt; // k = 0.004 at 100Hz, dt in seconds, 2.5s time constant
+            const float stickSuppression = prev + k * (stickDeflectionFactor - prev);
+            prev = fminf(stickSuppression, stickDeflectionFactor);
+
+            // 3. suppress ez_ef unless roll is centered, from 1.0 to zero if Roll is more than 12 degrees from flat
+            // this is to prevent adaptation to GPS while flying sideways, or with a significant sideways element
+            const float rollAngle = (float)attitude.values.roll;  // decidegrees
+            const float absRollAngle = fabsf(rollAngle);
+            float rollMax = isWing ? 250.0f : 120.0f; // 25 degrees for wing, 12 degrees for quad
+            // note: these value are 'educated guesses' - for quads it must be very tight
+            // for wings, which can't fly sideways, it can be wider
+            const float rollSuppression = (absRollAngle < rollMax) ? (rollMax - absRollAngle) / rollMax : 0.0f;
+
+            // 4. attenuate ez_ef by pitch angle, will be zero if flat or negative (ie flying tail first)
+            // allow faster adaptation for quads at higher pitch angles; returns 1.0 at 45 degrees
+            // but not if a wing, because they typically are flat when flying.
+            // need to test if anything special is needed for pitch with wings, for now do nothing.
+            float pitchSuppression = 1.0f;
+            if (!isWing) {
+                const float pitchAngle = (float)attitude.values.pitch; // decidegrees, negative is backwards
+                pitchSuppression = pitchAngle / 450.0f; // 1.0 at 45 degrees, 2.0 at 90 degrees
+                pitchSuppression = (pitchSuppression >= 0) ? pitchSuppression : 0.0f; // zero if flat or pitched backwards
+            }
+
+            ez_ef *= stickSuppression * rollSuppression * pitchSuppression;
+
+            // NOTE : these suppressions make sense with normal pilot inputs and normal flight
+            // They are not used in GPS Rescue, and probably should be bypassed in position hold, etc, 
+        }


Can you at least move this into separate function? It is not dependent on anything in IMU and can be easily multiplied into groundspeedGain

ledvinap · 2024-03-27T09:16:12Z

src/main/flight/imu.c

+                // GPS typically returns quite good heading estimates at or above 0.5- 1.0 m/s, quite solid by 2m/s
+                // groundspeedGain will be 0 at 0.0m/s, rising slowly towards 1.0 at 1.0 m/s, and reaching max of 10.0 at 10m/s
+                const float speedRatio = (float)gpsSol.groundSpeed / GPS_COG_MIN_GROUNDSPEED;
+                groundspeedGain = speedRatio > 1.0f ? fminf(speedRatio, 10.0f) : speedRatio * speedRatio;


(from above - stick factors can be applied here, without testing for GPS_RESCUE_MODE again)

ctzsnooze · 2024-03-29T04:41:14Z

@ledvinap - It is probably better to do the full refactoring, to not at all. Your work in refactoring is really good.

I just bench tested that refactoring - PR22 to my branch - and I can confirm everything works properly.... absolutely normal GPS and Mag behaviour. Haven't flight tested yet to check GPS Rescue but will do that as soon as I can.

Thank you!

Move compass and Cog code into separate functions, separate gain heuristics - imuCalcGroundspeedGain - imuCalcCourseErr - imuCalcMagErr Temporary refactor od imuDebug_GPS_RESCUE_HEADING, to be removed of optimized

ctzsnooze · 2024-03-31T06:55:03Z

@ledvinap I included your commits that refactor and improve the IMU coding generally. I was able to fly them today, and fond no problems at all. Mag and GPS behaviour appeared normal, GPS Rescues all behaved as expected.

I think we will need some further testing from @limonspb with his wings, and I'll do more also.

I think the refactoring is excellent and certainly is necessary. Thank you.

ctzsnooze · 2024-03-31T07:02:59Z

@ledvinap - Tests don't fail locally for me, but I think that the tests are failing where useMag is instantiated in imu.c around 634 but only used if USE_GPS is defined.
I don't know the best solution for it. Had a go... pls check.

=

ledvinap

Some minor improvements

I'll try to compare changes once more tomorrow

src/main/flight/imu.c

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

commit 54570328388190eb48900e0db6f2f271192019a7 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Thu Apr 4 09:08:40 2024 +1100 Use PDOP consistently, since it replaces HDOP (#13477) commit fb14365e664c8c4e762f69280728b97aacbbe082 Author: tbolin <tobias_bolin@hotmail.com> Date: Wed Apr 3 22:59:29 2024 +0200 Add ez_landing_speed parameter (#13411) * Add ez_landing_speed parameter The parameter is the speed at which ez_landing will be effectively disabled in tenths of meters per second. Default value 50 (5 m/s). EZLANDING bug field 5 is the contribution from this parameter to the ezlanding throttle cap. * Correct ez_landing_speed logic and scaling * ez_landing_speed should now raise the limit when the speed is above ez_landing_speed (previously only raised the limit if the speed was bellow, and had no effect above the limit) * ez_landing_speed should now be scaled so that EzLanding is effectively disabled when speed >= ez_landing_speed (previously EzLanding would be disabeld when speed was at half of ez_landing_speed) * Add stick input upper limit as EZLANDING debug 4 * Check for gps 3D fix before using gps speed for EzLanding * Prevent division by 0 if ez_landing_threshold is set to 0 * Scale EzLanding speed to m/s from cm/s * Update src/main/flight/mixer.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit ac846f7537f98e5815cccb61887fe842cea08f74 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Thu Apr 4 00:19:33 2024 +1100 mag cal improvements (#13487) * mag cal improvements reduced threshold to start updating the previous cal LED0 goes 'solid' only when the calibration start threshold is met Don't zero previous Cal values until the update threshold is met Mag_calib debug shows cal values at zero unltil they start being updated. * beep ready, acc_calibration, and gyro_calibrated, for audio feedback s * improvements, thanks to feedback from PL * change magCalEndTimeUs to magCalProcessEndTimeUs * make process names more obvious * use static boolean for initation and termination * magCalProcessEndTimeUs to magCalEndTime * LED ON, not toggle commit cd8b6aa5210bcb2907b8c09ca5580ce471b309e1 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Tue Apr 2 06:42:06 2024 +1100 Improve IMU responsiveness, refactor (#13373) * ensure that division is a float * change logging, improve logic for recalibration * Increase sensitivity, smooth center, higher max cogYawGain, renaming * use non thrust vector maths, revise and add comments * three factors to reduce ez_ef - speed, thrust vector, stick movement re-naming and comments * fix unittest, update comment * normalize heading magnitude, add pitch and roll suppression factors * ignore pitch factor on wings because they 'normally' have forward velocity while flat and their path while rolled usually does not change abruptly * fix unit test * fix dumb mistake blocking pitch suppression for non-wings * fixes from review thanks PL * refactor vector2normalize - thanks to karate * Use X and Y for 0 and 1 in rMat * Revert debugs, update comments from review * lrintf for floats in debugs * vector.h - implement some vector2* code as vector* * Refactor IMU code Move compass and Cog code into separate functions, separate gain heuristics - imuCalcGroundspeedGain - imuCalcCourseErr - imuCalcMagErr Temporary refactor od imuDebug_GPS_RESCUE_HEADING, to be removed of optimized * Simplify simulator build conditional compilation * Adapt unittests to IMU after refactoring * Maybe fix the test? = * Update src/main/flight/imu.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> * Update src/main/flight/imu.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> * Update src/main/flight/imu.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> * Update src/main/flight/imu.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> * Update src/main/flight/imu.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz> Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit 90841282b03339c7361db306d280f4bdd96de1e4 Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Mar 27 09:57:02 2024 +0100 Add resource for LPUART (#13306) * Add resource for LPUART * Fix per review * Fix per review 2 commit 52af623bcb30865ceec168794865fdae35ff6dbc Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Mar 27 00:07:14 2024 +0100 Add support for SPL07_003 barometer - based on DPS310 (#13427) * Add support for GoerTek SPA006_003 barometer - based on DPS310 * Fix missing coefficients * Fix tabs * Fix per review Ledvinap * Add missing coefs for pressure calculation * Use chunk size of 9 bytes * Fix MIN * Update comment * Be more explicit * Update src/main/drivers/barometer/barometer_dps310.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit 9f36b400c980222eef23cc6d69c75f91d8a0ed11 Author: Károly Kiripolszky <karcsi@ekezet.com> Date: Tue Mar 26 23:18:49 2024 +0100 Fix MSP version comment (#13471) commit 7e0759076fe062785a73f91331c6beab667a7772 Author: nerdCopter <56646290+nerdCopter@users.noreply.github.com> Date: Thu Mar 21 17:57:55 2024 -0500 [github actions] release assets upload fix (#13462) commit 2a6ae06e84de7b395b4cce8ae6536dee5b5612bc Author: Petr Ledvina <ledvinap@gmail.com> Date: Thu Mar 21 22:45:55 2024 +0100 Fix qmc5883l lockup (#13467) Data registers are locked until last/unlock register is read. New data are not stored when locked and DRDY is not set. On bus error, read may finish early (not reading unlock register) and thus cause driver lockup. Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz> commit e359c3687939688da88cc35fa464977e95627bdb Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Mar 21 18:43:55 2024 +0000 Use intptr_t for casting void * to an integer (#13463) * Use intptr_t for casting void * to an integer * Update src/main/cms/cms.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit dc00d34bfd59db04c7791812bf15713332708bdd Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Mar 21 17:59:18 2024 +0000 Render spec screen over normal OSD (#13460) commit 9dfa09a07eb8be0eb3124db06f69efe1987c1ec5 Author: Károly Kiripolszky <karcsi@ekezet.com> Date: Thu Mar 21 18:29:22 2024 +0100 Extend build info with defined flags (#13333) * Extend build info with defined flags * Fix CI * Formatting * Update license header * Build options (WIP) * Review fixes * Add MSP build info generator * Review fixes * Add input hash * Fix for PascalCase * Add comment about MSP version commit b9b4b77e3b0a94fd65754c28aa194f6e50c85fea Author: tbolin <tobias_bolin@hotmail.com> Date: Wed Mar 20 00:10:28 2024 +0100 Fix #13452 Write gps altitude to blackbox as signed value (was unsigned) (#13453) Write gps altitude to blackbox as signed value (was unsigned) commit d3a4ea6d9a75d30f7229aece59cb6e294084c197 Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Mar 19 11:14:53 2024 +0100 Fix spektrum define (#13459) * Fix spektrum define * Fixes per review - thanks ledvinap commit 0f109c8d0b125720d44d5c80ec153b5291a7400f Author: Petr Ledvina <ledvinap@gmail.com> Date: Tue Mar 19 11:11:53 2024 +0100 Fix bmp388 spi (and add BMP390) (#13458) * Fix BMP388-SPI SPI read returns dummy byte first when reading. Discard this byte on SPI reads * BMP388 - add supprot for BMP390 * fixup! Fix BMP388-SPI --------- Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz> commit 84d54051f17171a13d509c1e7e4bfedeb2884b35 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Tue Mar 19 07:00:47 2024 +1100 In GPS Rescue current altitude mode, ensure that return height is not less than climb height (#13276) * ensure that return altitude is not negative with current height mode * Update src/main/flight/gps_rescue.c * Update src/main/flight/gps_rescue.c * Update src/main/flight/gps_rescue.c --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit 3aabaf365d79b4035ba3813a3621a84078d72fe8 Author: Petr Ledvina <ledvinap@gmail.com> Date: Fri Mar 15 21:48:15 2024 +0100 Fix rx spi processing required (#13454) * fix RX_SPI_PROCESSING_REQUIRED - fix typo - remove unreachable 'return false;' in rxSpiProcessFrame * Simplify auxiliaryProcessingRequired rxRuntimeState.rcProcessFrameFn never returns false * fixup! fix RX_SPI_PROCESSING_REQUIRED --------- Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz> commit d22ea477369bb9602fe321c57640790f03d9d814 Author: Mark Haslinghuis <mark@numloq.nl> Date: Fri Mar 15 21:45:27 2024 +0100 Fix gating and mk cleanup (#13440) Fix gating and cleanup commit 55a607d46d6ca3ce99912298b4a7e4b6abbf8aac Author: Mark Haslinghuis <mark@numloq.nl> Date: Fri Mar 15 21:42:44 2024 +0100 Fix typo (#13400) Update target.h commit 5bf45a2fae8d6d4a76d0cac442f10d000a7df136 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Mar 14 23:26:55 2024 +0100 Fix missing gyro defines for USE_SPI_GYRO (#13449) commit 413d05d6c48e5ac1aac92789feb40d02b2aa64ce Author: StNekroman <StNekroman@gmail.com> Date: Thu Mar 14 21:50:16 2024 +0200 Make servos great again (#13451) * Make services great again * Make servos great again * Changes according comments commit ecef09fdd7922cfa41b6e6d64a30c589a156bf4a Author: Dominic Clifton <dominic.clifton@cleanflight.com> Date: Tue Mar 12 17:26:42 2024 +0100 Include a target's `config.h` before `common_pre.h`. (#13439) Some gating in `common_pre.h` requires the target's `#define`s to be present, such as `#if defined(USE_LED_STRIP)`... commit af51e00773d69965d7e1004ab506d8ae45081f8b Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Mar 11 17:46:06 2024 +0000 Fix OSD task timing when using MSP (#13388) Add uartWriteBuf() to improve performance Optimised transmit buffer space check Tidy up group duration calculations Add uartBeginWrite, uartEndWrite and serialWriteBufNoFlush Remove OSD grouping and check on the fly. Implement multi-pass artificial horizon rendering. Fix rendering of camera frame Fix stick overlay background rendering Fix channel rendering Fix ESC information rendering Make Spec Prearm Display deterministic Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit 915caae88d166c1fd8f931016f98558bab138490 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Mar 11 14:34:18 2024 +0100 Fix code style (#13429) Fix GPS arming flag when BOXGPSRESCUE is enabled but procedure is not set to GPS_RECUE commit 94be8f067310189b318641763e1b83bec2a00d58 Author: Thomas Stibor <tstibor@users.noreply.github.com> Date: Fri Mar 8 11:14:26 2024 +0100 Fix openocd makefile target by using TARGET_MCU_FAMILY (#13410) * Fix openocd makefile target by using TARGET_MCU_FAMILY The condition before this commit in mk/openocd.mk ifeq ($(TARGET_MCU),STM32F4) OPENOCD_CFG := target/stm32f4x.cfg else ifeq ($(TARGET_MCU),STM32F7) OPENOCD_CFG := target/stm32f7x.cfg else endif ifneq ($(OPENOCD_CFG),) OPENOCD_COMMAND = $(OPENOCD) -f $(OPENOCD_IF) -f $(OPENOCD_CFG) endif resulted in a not defined OPENOCD_COMMAND, because TARGET_MCU does not contain the MCU family such as STM32F4, but e.g. STM32F411xE. Thus executing e.g (note: CONFIG=BLACKPILL411 is a custom config I created for the Blackpill Board) $ make DEBUG=GDB CONFIG=BLACKPILL411 openocd-gdb make: *** No rule to make target 'openocd-gdb'. Stop. whereas after the patch: $ make DEBUG=GDB CONFIG=BLACKPILL411 openocd-gdb ... ... Linking STM32F411_BLACKPILL411 Memory region Used Size Region Size %age Used FLASH: 7680 B 16 KB 46.88% FLASH_CONFIG: 0 GB 16 KB 0.00% FLASH1: 329297 B 480 KB 67.00% SYSTEM_MEMORY: 0 GB 29 KB 0.00% RAM: 62612 B 128 KB 47.77% MEMORY_B1: 0 GB 0 GB text data bss dec hex filename 331757 5220 56980 393957 602e5 ./obj/main/betaflight_STM32F411_BLACKPILL411.elf openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg & ./tools/gcc-arm-none-eabi-10.3-2021.10/bin/arm-none-eabi-gdb ./obj/main/betaflight_STM32F411_BLACKPILL411.elf -ex "target remote localhost:3333" -ex "load" Open On-Chip Debugger 0.12.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 2000 kHz ... ... [stm32f4x.cpu] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08009014 msp: 0x2001fff0 Start address 0x08009014, load size 336977 Transfer rate: 37 KB/sec, 11232 bytes/write. (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x08021a1c in scheduler () at ./src/main/scheduler/scheduler.c:695 695 task->taskAgePeriods = (cmpTimeUs(currentTimeUs, task->lastExecutedAtUs) / task->attribute->desiredPeriodUs); (gdb) quit works as expected. In addition add also G4 and H7 TARGET_MCU_FAMILY support. When installing openocd the config files for G4 and H7, should be provided in directory: /usr/share/openocd/scripts/target $ grep -r TARGET_MCU_FAMILY | awk '/ STM32/{print $3}' | sort | uniq && find /usr/share/openocd/scripts/target -type f | grep "stm32f4x.cfg\|stm32f7x.cfg\|stm32g4x.cfg\|stm32h7x.cfg" STM32F4 STM32F7 STM32G4 STM32H7 /usr/share/openocd/scripts/target/stm32g4x.cfg /usr/share/openocd/scripts/target/stm32h7x.cfg /usr/share/openocd/scripts/target/stm32f4x.cfg /usr/share/openocd/scripts/target/stm32f7x.cfg * Remove useless else commit 6d98dbb7424693d52785ac48f098b447049d80b0 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Mar 7 12:09:42 2024 +0100 Fix space in status output when gps version is unknown (#13423) * Fix space in status output when gps version is unknown * Refactor per review commit a0c0e191e1d50168a445f4cd200bc79e22abe97d Author: Yura Kriachko <iurii.kriachko@gmail.com> Date: Tue Mar 5 09:59:34 2024 +0100 Do not go into failsafe when the correct roll/pitch/yaw/throttle are sent via MSP_OVERRIDE (#13380) * Override failsafe when MSP_OVERRIDE active Fixes #13374 Set `rxSignalReceived = true` If MSP_OVERRIDE is active, so that it can be checked later. Otherwise, MSP controls are not considered in failsafe checks. * Do override only if BOXMOODEOVERRIDE box is active as well * Update msp.h * Update msp.c * Make sure that failsafe works when there is no signal from MSP * Introduce rxMspOverrideFrameStatus to make a clear separation from rxMspFrameStatus * Update src/main/rx/msp.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * add msp_override_failsafe * Update src/main/pg/rx.h Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/rx/rx.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit ddc81cb4faf4f2eb4de19e342f438beda53224a3 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Mar 4 13:29:38 2024 +0100 Fix timer interval for battery and RSSI LED indication (#13412) commit 47f3c31f54b5fe729db4a6c4cdc2030f2ffdf3d1 Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Feb 27 16:13:23 2024 +0100 Limit STM32F411 to use 32 leds only. (#13249) * Add USE_LIMITED_LED_STRIP_OUTPUTS to limit certain MCUs to use maximum 32 outputs * Fixes per review from Steve * Use target.h gate commit 37d27ad3e3d888f3cc9dd958ba970cdf5ff4238b Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Feb 27 15:58:39 2024 +0100 Fix Galileo toggling (#13384) * Fix Galileo toggling * try something else * cleanup * Fix per review from ledvinap * Prevent buffer overflow on invalid numConfigBlocks commit 79d031b8b620d5f3e71b0a3cf041df6599fc5d89 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Feb 26 23:21:20 2024 +0100 Ensure consistent openssl behaviour with version 3.2.x and 3.3.x (#13385) Ensure consistent openssl behaviour with verion 3.2.x and 3.3.x commit 4f1b36fb30ce426f8a25eba4ede85ba1025b1043 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Feb 26 22:29:09 2024 +0100 Log the standard deviation of gyro cycle time in SCHEDULER_DETERMINISM and TIMING_ACCURACY (#13377) * Log the standard deviation of gyro cycle time in SCHEDULER_DETERMINISM and TIMING_ACCURACY * Update src/main/scheduler/scheduler.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> * Update src/main/scheduler/scheduler.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit 8a506d219f330ec982005a20ba1d2a549b07abb9 Author: tbolin <tobias_bolin@hotmail.com> Date: Mon Feb 26 12:19:51 2024 +0100 Increase ez_landing_limit default to 15 (was 5) (#13375) commit d31daca2ff330751b78286aaa8185fe8b04beba0 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Feb 26 12:17:26 2024 +0100 Replace tabs with spaces (#13390) commit c6250fee6e5e9833cfcc4f6e8f8541ff67ca203a Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Feb 22 20:50:02 2024 +0100 Add autocomplete for hydrating configuration (#13378) commit 92d5460b92b7a26f15ea9709c13444858009bdbd Author: SpektrumRC <mfalvarez@horizonhobby.com> Date: Thu Feb 22 11:13:42 2024 -0600 Spektrum telemetry minor fix to address false Fastboot alerts on radios with latest update (#13383) Extended description of STRU_TELE_RPM, and changed fill values from 0xFF's to 0x00 to account for new fastbootUptime variable commit 0daed9f7dc42612ac862394ae41977f57c8fedc2 Author: Mark Haslinghuis <mark@numloq.nl> Date: Fri Feb 16 19:05:05 2024 +0100 Update SERIALRX_PROVIDER default (#13371) Add telemetry for FPORT selection commit afeb6f17c4c11bcfc659988662ea862e2775e51f Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Feb 15 13:47:38 2024 +0100 Bump workflow action (#13355) * Bump workflow action * Address artifact issue commit e3e67b2ecb643d697eda22f343d6564b3748fc26 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Feb 15 11:50:32 2024 +0000 Use cpu_late_10ths_percent_limit to set limit on % of late tasks in 10th of a % (#13330) * Use cpu_late_10ths_percent_limit to set limit on % of late tasks in 10th of a % Set CPU load late limit to 1% based on testing * Update src/main/cli/settings.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> * Update src/main/scheduler/scheduler.h Co-authored-by: Jan Post <Rm2k-Freak@web.de> * Update src/main/fc/core.c * Update src/test/unit/arming_prevention_unittest.cc * Update src/main/scheduler/scheduler.c --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit a190ed98dc674495b8096d369f2e7aa667d754e3 Author: ASDosjani <62965528+ASDosjani@users.noreply.github.com> Date: Wed Feb 14 13:39:18 2024 +0100 Naming LED Strip overlay rates (#13363) Add names to LED Strip overlay rates commit 76e225aec9e4a8ead63d69ce80d4d0f92a442327 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Feb 13 23:14:43 2024 +0000 For now disable 4way-if timeout (#13364) commit 3ef7a188d0dc89e7a42967ad82145de1c8d1df54 Author: Bryan Mayland <bmayland@capnbry.net> Date: Tue Feb 13 18:01:09 2024 -0500 Use fixed LED color table in RACE / BEACON LED profiles (#13339) Use the non-custom color table when requiring fixed colors commit b8d99d7542b904f66701eedb4595fd18b9602db8 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Tue Feb 13 07:30:28 2024 -0600 TPA_LOW tidy up (#13337) commit 435fe2750edce93892671cc694f8d6029f0cc59f Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Feb 11 21:09:21 2024 +0100 Add gate to HD OSD elements (#13347) Update osd_elements.c commit 69999281c460c82a294de4465ca7b92a320663f5 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Feb 8 17:28:57 2024 +0000 Permit 8kHz PID loop on F405 overclocked to 216MHz (#13356) * Permit 8kHz PID loop on F405 overclocked to 216MHz * Update src/main/config/config.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit 3726df1b71ad19e1cc7a5938e078be3d46ab3631 Author: James <james.kingdon@gmail.com> Date: Thu Feb 8 09:17:25 2024 -0500 Allow overriding the spi clock speed for icm42688 (#13346) There was a report of glitches on the raw gyro output of an icm42688 which were resolved by reducing the the SPI clock speed. I don't think a single report justifies changing the default speed or even adding a CLI command to make it configurable, but it's relatively low impact to allow the speed to be set at compile time by passing the value via EXTRA_FLAGS and this will make it easier to see if changing the speed solves any future cases that might turn up. Passing the original macro name caused the cloud builds to fail, so this PR introduces a new, shorter macro for setting the override value; ICM426XX_CLOCK When passing a value for a macro through EXTRA_FLAGS for a manual compile we need to use single quotes, e.g. to set 12MHz we could use -D'ICM426XX_CLOCK=12000000' When using the configurator to start a cloud build the value can be placed in the "Custom Defines" text box as ICM426XX_CLOCK=12000000 (or whatever value is desired) commit 744ab454b1d2ffd6ba5a6d131bc5e92e1aabb28b Author: Eike Ahmels <eike.ahmels@tu-dortmund.de> Date: Wed Feb 7 00:07:42 2024 +0100 Voltage detection method (#13350) change voltage detection method and is voltage stable flag to make it resilient and synced to update battery task Co-authored-by: Eike Ahmels <ea@weslink.de> commit 24e7dabed3174d89db1f9f73a80d8649b40f57cb Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Feb 6 12:43:39 2024 +0000 Ensure MSP channel data is valid (#13352) commit d84ec8da6394b1aab4ea94b53298225a153d79a6 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Feb 4 11:52:52 2024 +0100 Do not return MSP_RESULT_ERROR when succesful (#13328) commit 05eda719ff1e7ac628ee9b5d3566534d32a46e52 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Jan 29 20:37:51 2024 +0000 Install linux tools for appropriate architecture (#13335) commit a4b21d635c52648b5eed380f7549c28c2c59ce10 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Jan 29 20:34:57 2024 +0000 Fix unit test build under aarch64 Linux (#13336) Fix rcData[] type commit 2cd24cf02a13c07b9e2494fbd2fa8a51e336bf2d Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Jan 24 23:55:09 2024 +0100 Set OSD elements to HD defaults if build includes USE_OSD_HD (#13325) Make HD the default option if included in build commit a4356689fa7068aabcaa6eb2396e6a83f5ae88f8 Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Jan 24 01:27:54 2024 +0100 Enable PINIO if PIN defined in config (#13315) * Enable PINIO if PIN defined in config * Fix review from blckmn commit 17e43e33638b0e41adebdf1997a589e2084b722d Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Jan 22 23:56:25 2024 +0000 Fix OSD defaults based on SD/HD (#13320) Fix OSD defaults based on SD/HD and validate changing video_system to/from HD commit 42267349db0c92a0e1063bd1d07633a3322dfb07 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Jan 18 04:34:22 2024 +0000 Do not permit MSP on softserial ports as the load on the CPU is too great (#13303) Do not permit MSP or serial RX, or baud rates above 19200 on softserial ports as the load on the CPU is too great commit 926ef344769af4c15c22e54bbaf6b5354828f97a Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Tue Jan 16 08:03:06 2024 -0700 Make high rate IMU DcmKp change relative to user value (#13304) * make all IMU changes relative to user value * comment above line commit d039124e4436664a1b7a803d6b61eba8a4e9bab9 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Jan 13 22:24:01 2024 +0000 BLHeliSuite32 holds 4wayif code in indefinite loop waiting for ESC so remove timeout (#13287) commit 90ab9f374b706e9c657a650a058144c66bca09de Author: Mark Haslinghuis <mark@numloq.nl> Date: Sat Jan 13 13:42:12 2024 +0100 Fix ESC-Sensor RPM (#13286) * Fix ESC-Sensor RPM * Fixes per review from KarateBrot * Fixes per review from NerdCopter * Forgot to add init.c commit 3e5d96158b5795a9e995d9ce0de98e87625e2cce Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Jan 10 01:10:06 2024 +0100 Migrate hub to gh (#13279) commit f1cbd83f06811c52c805b5deb8d64b55382b8d72 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Jan 8 07:39:51 2024 +0100 Rename USE_QUICK_OSD_MENU (#13273) commit 09a70439be2da8db974cb04aa0940b823379d4e0 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Jan 7 22:05:07 2024 +0100 Fix F7X2 AXIM flash region (#13270) commit 024224d02770ad44aece7c1dbbfb21eee218cae2 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sun Jan 7 20:53:45 2024 +0000 Add timeout to serial four way interface for ESC programming (#13277) commit 70e70c5d7be06ff5656c9787c684a9a5ff2183df Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Jan 6 11:12:03 2024 +0000 Scale heading appropriately (#13269) commit 5fff78136ec1f2abc834641e00888fdfa0c980d1 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Fri Jan 5 04:31:30 2024 +0100 Fix CLI command "bind_rx" for CRSF (#13267) commit 7cb07d8e8e8f055b5a259828ccd42d062e291405 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Jan 4 15:19:09 2024 +0100 Fix missing GPS PG parameter (#13248) commit 39c58823c2caae9f23c4917d4b32a47bd0872aa8 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Jan 4 14:55:21 2024 +0100 Fix missing #undef in common_post.h for GHST (#13264) commit 2caed9b60d29a195bee7602b692bfa4731380360 Author: J Blackman <blckmn@users.noreply.github.com> Date: Thu Jan 4 13:08:49 2024 +1100 Increase EEPROM CONFIG version to force a configuration reset. (#13260) commit 1e093159658d889eec49abf90c2802296b36ba78 Author: J Blackman <blckmn@users.noreply.github.com> Date: Mon Jan 1 14:33:47 2024 +1100 Adding a few more gates in common post to assist in build errors. (#13250) commit 507fc672745fdcb83588021c7b319d5190b659c2 Author: Davide Iafrate <Tuxliri@users.noreply.github.com> Date: Mon Jan 1 01:15:28 2024 +0100 Increasing frequency of MSP protocol in SITL (#13253) Increasing frequency of MSP protocol commit 2ee519e29cd9d0bba8a1b25232223c9a90fc7ed2 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 31 23:37:01 2023 +0100 Fix BMI160 gate and optimize directives (#13237) * Add BMI160 gate and other defines * Fix make test * Remove redundant directives commit c996d5f77b438118384e13b197face50fa4eee96 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Dec 27 23:55:24 2023 +0000 Led task optimistion (#13247) * LED task optimisation * Drop LED task rate from 100Hz to 50Hz to reduce CPU load commit 9b078c0b1f411ba65822b496e968703cd9744b90 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Dec 28 00:14:02 2023 +0100 Fix arming when GPS included in build but no active GNSS device attached + revert msp request for SatInfo (#13244) * Fix arming when GPS included in build but not active * Fixes per review from Chris * Move PG change to new PR * Restore changing GPS PG version commit 22ce586550f532dfe5e37c21d33c91db48394cb9 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Dec 25 00:50:34 2023 +0100 Add MSP request for UBLOX SatInfo and disable SatInfo on ARMING. (#13240) commit b3be3edb0b97d3cf94b8fab7af5cf7e1d3dbe31f Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 24 13:56:14 2023 +0100 Fix builds when PWM motor protocol is used (#13236) * Fix builds when PWM motor protocol is used * Enable useUnsyncedPwm for PWM by default commit a39ae3c89c1f5f06ac93064d7ca1aa41d590c322 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Dec 23 12:01:50 2023 +0000 Revised LPF1+LPF2 filter cutoff bandwidths from STMicro (#13239) Revised LPF1+LPF2 filter cutoff bandwidths from STmicro commit fc7afed28dbd3d4e248d24f1e9739b4c736e52b0 Author: Mark Haslinghuis <mark@numloq.nl> Date: Fri Dec 22 07:59:07 2023 +0100 Change MAX7456 AUTO default to PAL (#13235) commit d3488d1345cfa8f760d0d4821dd9b1f0531d3482 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Dec 20 11:05:30 2023 +0000 Add hardware LPF1 options for lsm6dsv16x gyro (#13234) commit 58933f99724d4e741fcdd721e647af7157a09ece Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Dec 19 13:26:15 2023 +0100 Revive MSP message for mag declination (#13232) Add MSP message for mag declination commit 15246eebab29a229ebd2ffdaa2f04f993352b0e4 Author: Mustafa Cengiz <mustafacengiz98@gmail.com> Date: Mon Dec 18 23:49:50 2023 +0300 Update hardware specification link (#13231) commit 6af1614a5d003cc632ffa0e4fbc22cce55e446e9 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Dec 18 20:11:31 2023 +0000 Fix dma pin <io> list (#13233) commit fe237615207d1d019c7826b838dd2e856fb20848 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Dec 18 11:24:36 2023 +0000 Add gyro jitter analysis to DEBUG_SCHEDULER_DETERMINISM (#13230) commit 7d122c481a64650e99f7f31009ddf657cc983271 Author: Benedikt Kleiner <b.kleiner@str8labs.com> Date: Sun Dec 17 10:04:20 2023 +0100 at32: add mux 3 for tmr9 on port c (#13222) commit 65aaf732f9643465b6c24532bf3a32f3bb37db57 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 17 07:58:15 2023 +0100 Remove custom defaults and enable features on boot (#13216) * Remove custom defaults * Fixes per review * Fixes per review (thanks ledvinap) * Fix copy pasta commit 43c645a0065da3cd010a937b28d75d993108df97 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Dec 16 23:04:30 2023 +0000 Fix error in I2C write operation on AT32 (#13228) commit bc69a92b866d715adbd38ac63a0dd188f6fb78ba Author: Ivan Efimov <gendalf44@yandex.ru> Date: Fri Dec 15 16:00:35 2023 -0600 Added d_min for PID osd elements (#13227) * Added d_min for PID osd elements * Update src/main/osd/osd_elements.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> --------- Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit 3eb776e30d856c757b79e9a998d09b6f822c7acc Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Thu Dec 14 22:29:11 2023 +1100 bugfix compassBiasEstimatorInit initialisation (#13226) commit 03495f9273427c5203d7e6c9761692fcd275877e Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Dec 12 12:15:32 2023 +0000 Break LED_STRIP update into 20us chunks (#13218) commit 477c9801bc5fced05755884cc027246810d9947a Author: Ivan Efimov <gendalf44@yandex.ru> Date: Mon Dec 11 18:41:38 2023 -0600 Changed some defaults for RACE_PRO (#13215) * Changed some defaults for RACE_PRO * Update src/main/flight/imu.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/osd/osd.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/flight/failsafe.c --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit 20b2e9c6655dcfb47aace5e10608d4086195bdae Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Dec 12 01:39:22 2023 +0100 Fix defines for CI and add USE_RACE_PRO feature pack (#13212) * Fix defines for CI and add USE_RACE_PRO feature pack * Add RC_STATS commit 6ac08cdd58c1a17673b19c5065ed9fbaef456959 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Sun Dec 10 17:40:34 2023 -0600 Fix: RPM Limit - reset I-term at arm (#13214) * RPM Limiter - reset I-term at arm * Update src/main/flight/mixer.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> --------- Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit 4f5bb1abc0f3c178a656a1dca308a7b0830b059d Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Dec 11 00:37:29 2023 +0100 Fix jumpy baro debug (#13217) * Fix jumpy baro debug * Remove duplicate debug commit 31c5beaf78b43777bad3b2d251aa82e3a3d52b01 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Sat Dec 9 18:50:31 2023 -0600 OSD spec prearm screen if defined USE_SPEC_PREARM_SCREEN (#13210) * OSD spec prearm screen if defined USE_SPEC_PREARM_SCREEN * osd spec prearm PR suggestions * OSD_SPEC karatebrot logic suggestion * Update src/main/osd/osd.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> --------- Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit a92d87ebca8c78b674a256b4923efe2dce176a2b Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 10 00:30:50 2023 +0100 Fix OSD Quick Menu (#13211) commit ae71256da701a44e063fae28a2306972748b0622 Author: tbolin <tobias_bolin@hotmail.com> Date: Sat Dec 9 02:36:41 2023 +0100 Throttlebased EzLanding (#12094) * ezLanding * Add ez_landing throttle mode * Correct EzLanding scaling of motorMixRange * Correct mixer_type switch bracing style * Remove motor value cliping ez landing mode - rename mixer type cli setting to EZLANDING from EZLANDING_THROTTLE - remove EZLANDING_CLIP cli setting - double default ez_landing_threshold - halve default ez_landing_limit - check and limits in cli settings - remove mixer type dependent settings in mixer_init - remove clip based code in mixer.c * Change ez_landing setting values and refactoring - Halve defaul ez_landing_threshold setting and double in init instead. Now stick deflection equal to ez_landing_threshold should give approimately full authority. Previously it was the point where the mixer was allowed to raise the throttle to 100 % (which wouuld never be required) - Increase ez_landing_threshold maximum to 200 (from 100) to allow settings that increase authority by a little at full stick deflection - Increase ez_landing_limit maximum to 75 which is the point where EzLanding should act identical to the Legacy mixer with airmode on - remove throttle percent from - simplify calculation of , since throttle stick deflection is no longer involved - update/remove outdated comments * Remove old EZLANDING entries in mixerType enum * Add mixer_type setting to blackbox log header --------- Co-authored-by: ctzsnooze <chris.thompson@sydney.edu.au> Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit d3830b6b347bb2949594e98be1d9942b16266cfe Author: Ivan Efimov <gendalf44@yandex.ru> Date: Fri Dec 8 15:37:33 2023 -0600 Make lookupTableThrottleLimitType an extern variable (#13204) commit 380d39e57001dc759a0f130223a8e2b3559374c8 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Fri Dec 8 13:51:52 2023 -0600 Renamed tpa....lower to tpa_low_..., + tpa_low_always = OFF by default (#13206) Renamed tpa....lower to tpa_low_..., inverted the logic for it being active and renamed to a simple tpa_low_always which is OFF by default now commit b2ce402635c9278b839b13bd87294dcf96e99c6e Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Fri Dec 8 05:55:01 2023 +1100 fix iterm bug introduced in PR13127 (#13201) fix iterm bug introduced in 13127 commit a88e8940aaca2d818a3973bba3d965359176b41c Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Thu Dec 7 01:10:29 2023 +0000 Change WHO_AM_I to match datasheet (#13200) commit 2733dadf0218e2caafde6958589b018cc44c7a5c Author: Tanner Beard <tdogbeard@gmail.com> Date: Wed Dec 6 13:51:52 2023 -0800 Rpm limiter initial throttle cap prediction fix (#13039) * initial commit * initial commit * Update src/main/flight/mixer_init.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> * rpm limiter vbat compensation * remove forced define * change to multiply * rpm limiter vbat compensation method 2 * fixes * remove def * test * test * test * cleanup * fix for maxcheck condition not satisfied if set to 2000 * Refactoring / cleanup * Rename averageRpmFilter * missing paren * Move RPM estimation to motor.h * Add macro for deadband --------- Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit 0b0c63a73dcf4b56d94814a7bad88d42dea9c2e2 Author: tbolin <tobias_bolin@hotmail.com> Date: Wed Dec 6 21:38:21 2023 +0100 Add ICM-42605 to list of gyros with overflow protection (#13194) commit 71199b1602420c27c65448298e34a96e8ee2d334 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Wed Dec 6 01:47:18 2023 +0100 Encapsulate LSM6DSV16X driver specific macros (#13196) Cleanup commit 3cfad864a6e9f44245cb908453ca5450e5a137f5 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Wed Dec 6 00:11:45 2023 +0100 Add LPS22DF to core build (#13197) commit 8c5cb52d76517e33ca65148fee4cebaa63097570 Author: tbolin <tobias_bolin@hotmail.com> Date: Tue Dec 5 22:19:50 2023 +0100 Fix # 12991 Change LSM6DSO gyro scaling to 70 mdps/LSB (#13014) Change LSM6DSO gyro scaling to 0.070 dps/lsb commit 240c31e12350b18f8256887eaae3919275bd6c5b Author: Jan Post <post@stud.tu-darmstadt.de> Date: Tue Dec 5 21:17:27 2023 +0100 Add RPM Limiter to baseline build (#13190) * Fix function name * Add RPM Limiter to baseline build commit e9be3400414bc0b76a572a4f6e67990a902cc30e Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Dec 5 20:15:57 2023 +0000 STMicro LPS22DF baro support (#13054) * Add LPS22DF baro support * Update src/main/drivers/barometer/barometer_lps22df.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Jan Post <Rm2k-Freak@web.de> commit 465b05ec0664b57bef88c3dcc986ac0ee8e830f0 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Dec 5 20:14:35 2023 +0000 STMicro LIS2MDL mag support (#13150) * STMicro LIS2MDL mag support * Fix copyright headers * Update PG_COMPASS_CONFIG commit dd198b2cda183b74a5d6d634e188381b92efcbff Author: Ivan Efimov <gendalf44@yandex.ru> Date: Tue Dec 5 04:54:10 2023 -0600 Keep I-terms at zero throttle for fixed wings (#13127) * Keep Iterms at zero throttle for fixed wing mixer * Ctz suggestions * Update src/main/fc/core.c based on ladvinap suggestion Co-authored-by: Petr Ledvina <ledvinap@gmail.com> --------- Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit efe1825afa82ec529920838b5a1777a667112fa7 Author: tbolin <tobias_bolin@hotmail.com> Date: Tue Dec 5 11:44:14 2023 +0100 Fix #12908 Add ICM-42688-P IMU to list of IMUs with overflow protection (#13013) Add ICM-42688-P imu to list of imus with overflow protection commit 4c86e31d1ea4f99ee7b383456a73f2a7f4bfa822 Author: Flavio Pinzarrone <73338417+flaviopinzarrone@users.noreply.github.com> Date: Mon Dec 4 16:50:08 2023 +0100 Fixed incorrect accelerometer scaling in MSP (#13026) commit 13d1dc81ce9560eed1c50a6f482a6d158cd970e8 Author: pichim <93905657+pichim@users.noreply.github.com> Date: Mon Dec 4 16:35:27 2023 +0100 Additional TPA breakpoint for low Throttle (#13006) * Removed white spaces and everything that is not new Rebase on master and update comment Make TPA lower independent from air mode Included tpa_breakpoint_lower_vanish option Changes according to PR comments Corrected comment for API version Bugfix in msp.c Additional TPA breakpoint for low throttle * Changes according to PR comments * Update src/main/cms/cms_menu_imu.c Co-authored-by: Jan Post <Rm2k-Freak@web.de> * Update src/main/flight/pid_init.c commit c41e2f2680c418776fb4171a3cc1298de4cdd1a6 Author: Auster <iAuster@ya.ru> Date: Mon Dec 4 02:28:45 2023 +0000 Allow CRSF RX binding via cli (#13119) commit b199e6500031a380b27f65c04baf6b85e1b9942a Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Dec 4 03:21:17 2023 +0100 Remove unused servos header file (#13182) commit 7dffe25ed108c44f000f0e95787e4d5204190221 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Dec 4 03:02:08 2023 +0100 Fix default PID DENOM (#12509) * Set default PID DENOM * Fixes after Karate review * Fixes after Karate review v2 * Use gyro.sampleRateHz * Fixes after discussion commit e126f1c4a46ba0f5800baa53914cc3eface14041 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Dec 4 01:19:48 2023 +0000 STMicro LSM6DSV16X IMU support (#13046) Add support for LSM6DSV16X commit 010a71820a845d3fd82145993a257e9dbbb9a401 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 3 21:56:55 2023 +0100 Set serial duplex mode (#12909) * Set serial duplex mode * Add add common protocols commit 09b59b76685c5c2d95b9ca6c765db57579b0c515 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Dec 3 10:36:42 2023 +0100 Add default config option for dshot telemetry (#13184) commit 32ccc841ab611fe9ace6b6d3a1abbcf3a59c4100 Author: Benedikt Kleiner <benedikt.kleiner@googlemail.com> Date: Sun Dec 3 10:35:35 2023 +0100 at32: add PA0/PA1 as i2c pins (#13187) commit 5769b3021ead06bb07e54007f8394c5d6f755db5 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Sun Dec 3 05:16:35 2023 +0100 Dshot RPM Telemetry Refactoring (#13012) commit 0c9d7e6c50337584c3ecd29e3819f22ebaa2f79c Author: J Blackman <blckmn@users.noreply.github.com> Date: Sun Dec 3 11:05:57 2023 +1100 Add additional timers for AT32F4 (#12548) commit 65357e51bd85541a2c3fbdc89d228a8856a9a9db Author: Míguel Ángel Mulero Martínez <migmul@gmail.com> Date: Sat Dec 2 10:15:37 2023 +0100 Add OSD Link Quality alarm value to the MSP (#13121) commit 57fbf61331fde601b90af35d29612e7f96c09015 Author: Cru Waller <24904289+cruwaller@users.noreply.github.com> Date: Fri Dec 1 10:49:22 2023 +0200 Fix: ledstrip vtx freq based color selection in RACE mode (#13096) Fix: ledstrip vtx freq handling in race mode commit 6fe81a94459c0ae58c637ee7c6a014e210772791 Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Nov 28 10:42:31 2023 +0100 Fix disabling sensor configuration (when device needs battery power) (#13177) * Fix sensor config * Encapsulate code * Add new message for detectedSensors * Add SENSOR_NOT_AVAILABLE * Move comment * Add gyro commit a8834ad14ba59dfbc6cd1d37c01ff86cf5457100 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Tue Nov 28 11:55:01 2023 +1100 Mag scheduling improvements (#13166) * Improved QMC driver, scheduled silent interval * add ODR to drivers and use it to set the quiet period * add MAG_TASK_RATE debug for testing * don't do a read if the bus is busy - thanks, Petr * refactoring and simplification, thanks to Steve --------- Co-authored-by: Steve Evans <SteveCEvans@users.noreply.github.com> commit cafe727f3ab831b93afea602291cc7787d76aaf6 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Nov 23 22:56:14 2023 +0100 Fix Dshot telemetry (#13140) * Fix Dshot telemetry * Revert check per review commit 89607c699b079ee203a70f625f1eef233b654495 Author: Mark Haslinghuis <mark@numloq.nl> Date: Sun Nov 19 11:18:41 2023 +0100 Increase PG version for rpm_filter (#13172) Update rpm_filter.c Fixes PG version from changed made in #12838 commit ab1559cf207425550b2f2252743e2253c00fa2b8 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Fri Nov 17 22:45:04 2023 +0000 Make AT32 I2C accesses fully interrupt driven (#13171) Make I2C accesses fully interrupt driven commit 84a04db8b973407c00d6d5c2ead787ce3353ec06 Author: pichim <93905657+pichim@users.noreply.github.com> Date: Wed Nov 15 16:12:36 2023 +0100 Improved Magnetometer / Compass Bias Estimator (#12998) * Rebased on master and clean-up (untested), this is still the initial method * Included math.h in compass.c, so checks don't fail * Change comments, compass is still only running at 167 Hz, not worth investing more * Alternative method, using only mag data * Removed unnecessary scaling and fine tuning * Corrected comment * Removed no longer needed debug DEBUG_MAG_TASK_RATE, comments and corrected some typos * Improved readability and update of comment * Rebased on master and resolved conflicts * Included math.h and maths.h so checks don't fail * Update src/main/sensors/compass.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/sensors/compass.h Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/sensors/compass.c Co-authored-by: Petr Ledvina <ledvinap@gmail.com> * Changes according to PR comments --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> Co-authored-by: Petr Ledvina <ledvinap@gmail.com> commit 9618dc845132e0e4eaa22167dea07df225ad43d6 Author: AlexRice13 <50689742+AlexRice13@users.noreply.github.com> Date: Tue Nov 14 09:42:12 2023 +0800 Update esc_sensor.h to support higher esc telemetry voltage display (#13115) commit 4891a55a538346572c459c64d8a7abd088ea732a Author: tbolin <tobias_bolin@hotmail.com> Date: Mon Nov 13 11:42:14 2023 +0100 Remove back-and-forth float to int to float conversion in acceleration calculation (#13158) Remove float to int to float conversion in acceleration calculation commit 6d7bfb9b1e55c49e457328052f1cdf78e1ee94bc Author: Valeriy Van <github@w7software.com> Date: Mon Nov 13 10:53:33 2023 +0200 Fix typo in README.md (#13164) Fix typo commit 96e6b794307e7aab3090ae89f70c219308f33ee8 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Nov 7 05:37:27 2023 +0000 Fix compass loop time (#13125) commit f223b2376e3091b9e4f9dba0b25b91d71ee3fa66 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Tue Oct 31 10:01:41 2023 +0100 Remove Special Chars from eRPM Blackbox Field (#13123) Remove special chars from erpm blackbox field commit 05f70a80da5b500bec6dbee5171cc5d2e20a243d Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Mon Oct 30 02:37:27 2023 +1100 bug fix for DMax Setpoint Factor (#13145) fix too high DMax Setpoint Factor commit 34e7a5ceebb69daa7d730d0c41908385992f3301 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Oct 24 14:12:14 2023 +0100 Check tx on MSP and GPS only (#13100) commit 4f17fe0aacf5b8a7813f93c41784fb0b6c57f120 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Oct 23 08:08:07 2023 +0100 Disable ICM426XX AFSR feature to prevent stalls (#13132) commit eee0cb54677aaf4daae28fd7068460abbffa53c8 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Oct 21 23:40:46 2023 +0100 Fix buffer overflow in JETIEXBUS character reception (#13130) * Fix buffer overflow in jetiexbus character reception * Update src/main/rx/jetiexbus.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit ef34a91aa2f629689b03d97de4dbf4597a55b712 Author: Jan Post <post@stud.tu-darmstadt.de> Date: Fri Oct 20 19:30:30 2023 +0200 Dimmable RPM harmonics (#12838) commit fe0e0cb5b85784a7407970beaa91714948427a71 Author: Jacopo Panerati <jacopo.panerati@utoronto.ca> Date: Fri Oct 13 22:39:01 2023 +0400 Removed SITL hardcoded state port number (#13117) * Removed hardcoded state port number * Removal of duplicate extra udpInit commit e805c73eb1828bce5c08c81e646d1bf56d3d57c0 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Thu Oct 12 10:21:10 2023 +1100 rearrange rescue phase enum and keep Mag during landing (#13072) commit 5d16feeb6a2ffc7e2f99393835771dec41a6a4ce Author: BAYCK RC <55321703+BAYCKRC@users.noreply.github.com> Date: Thu Oct 12 01:56:58 2023 +0800 fix ARTERY UART4 pin 'PH2&PH3' (#13108) commit b4ff2ad0f814698c4565c1eaec8150bacfa368ef Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Oct 11 18:49:40 2023 +0100 Fix marking of softserial port usage (#13097) commit 63f5065307bf3243fbe42254f12069fc2a803b44 Author: Mark Haslinghuis <mark@numloq.nl> Date: Fri Sep 29 22:37:17 2023 +0200 Fix clang version (#13099) commit 66bf029edc0f3dbfbaf5eb6891e9d335907202fc Author: Mark Haslinghuis <mark@numloq.nl> Date: Wed Sep 27 06:40:01 2023 +0200 Fix missing target define (#13078) commit d8ed530ceb36c6d6045cf4920e297cdf679f2773 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Sep 27 05:39:31 2023 +0100 Use USE_DSHOT_BITBAND (#13090) commit 696e23fbebee1e14cbba793ca7fbda2e8c822f50 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Wed Sep 27 14:38:41 2023 +1000 Fix circling behaviour during GPS Rescue descent phase (#13091) in descent and landing, attenuate pitch angle unless pointing accurately towards home commit 9ada5638a314c6aa358d90412586cc0af6cf6443 Author: pichim <93905657+pichim@users.noreply.github.com> Date: Wed Sep 27 00:01:22 2023 +0100 Add magnetic heading as debug and magnetic declination for the Mahony filter (#13073) * Add mag heading to GPS Rescue heading debug * Roll and pitch compensated magnetic yaw * Changes according to PR comments * Encapsulate yawMag calculations * Corrected naming * Changes according to PR comments * Changes so that Checks don't fail * Added PARAM_NAME list * Changes so that Checks don't fail * Changes according to PR comments * Update src/main/fc/parameter_names.h Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Changes according to PR comments * 200Hz compass task * fix wait status flag * increase default ODR of HMC5883L to 75Hz * fix spikes in MagYaw debug by re-calc only on new data --------- Co-authored-by: ctzsnooze <chris.thompson@sydney.edu.au> Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit 1856d6f7ef611fe027e6bcbd6532a4b8c5bae5e5 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Sep 18 20:55:41 2023 +0100 Remove dshot_telemetry_start_margin setting and auto-tune instead (#13075) * Remove dshot_telemetry_start_margin setting and auto-tune instead * Add USE_DSHOT_BITBAND commit 99be07729963e4b5e5cb540555450bda28bd2781 Author: SpencerGraffunder <spencergraffunder@cedarville.edu> Date: Mon Sep 11 00:35:19 2023 -0400 GPS Lap Timer: Fix best 3 not being calculated (#13065) Fix best 3 not being calculated due to number of laps not being incremented To calculate the best 3 consecutive laps time, it needs to track the number of laps recorded. This must have been accidentally removed at some point. commit a72ad8b2b678e7819d054918012583ee6e7d81f1 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Sep 9 00:02:09 2023 +0100 Add support for MSP2_SENSOR_GPS message from RemoteID module (#13062) commit 5cd2ab50e4512ed12dd619c7983cc469c4372a14 Author: ASDosjani <62965528+ASDosjani@users.noreply.github.com> Date: Tue Sep 5 17:09:31 2023 +0200 Add LED strip config values to MSP (#12995) * Add LED strip config values to MSP * change hue calculation + higher max frequency * higher rainbow frequency * define LED Strip task rate * msp2 * fix delta size * Update src/main/msp/msp.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> * Update src/main/msp/msp.c Co-authored-by: Mark Haslinghuis <mark@numloq.nl> --------- Co-authored-by: Mark Haslinghuis <mark@numloq.nl> commit 37f119cf4fe0d49f10958cbd37016d15e25db02b Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Sun Sep 3 01:11:04 2023 +1000 minimal NMEA support for 4.5 (#13044) * minimal NMEA * fix a typo thanks Karate commit a35a5af16c917139507c84aa1b9e504a25e060b2 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Fri Sep 1 23:58:26 2023 +1000 Only allow arming when valid Rx signals are received (#13033) * Only allow arming when failsafe criteria are cleared * 500ms RXLOSS period with 100ms minimum commit d1025bd1f534b19ae90cd22af1c6dfcd53456765 Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Thu Aug 31 21:58:41 2023 +1000 Make use of all 8 debug values for the GPS Rescue debugs (#13055) commit 778088013977eb089f8545fb0223c8e355069a00 Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Aug 31 11:50:15 2023 +0200 Fix GPS Rescue parameters confusion (#13047) * Fix GPS Rescue parameters * Fixes per review * more renames * Refactor setReturnAltitude * Change return altitude to 5 - 1000 * Rename return speed * Change groundSpeed to groundSpeedCmS commit b7f98b08e6d6d5b1b1cb6fedb1e5cc1b3d372b8b Author: Mark Haslinghuis <mark@numloq.nl> Date: Thu Aug 31 11:46:05 2023 +0200 Fix missing ACC MPU6050 (#13048) commit 9f816b678d3c99462a5bbbeed70afb65fd99969a Author: pichim <93905657+pichim@users.noreply.github.com> Date: Wed Aug 23 16:46:20 2023 +0100 Added dynamic expo factors to blackbox header (#13004) commit 08570cadce0cc61a9e4c4acf93fb78021a01e1ac Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Fri Aug 18 09:02:00 2023 +0100 Add support for 'make CONFIG_clean' as per 'make TARGET_clean' (#13038) commit 5f2d8da3b97625dfe5b9056c7838c2b9e537de43 Author: Cru Waller <24904289+cruwaller@users.noreply.github.com> Date: Wed Aug 16 12:31:39 2023 +0300 Fix OSD VTX band/channel info when direct frequency is used (#13032) Fix OSD VTX band/channel when direct frequency is used commit 3ab822b66143fa14b771d347b1ef07687fa9a33d Author: ctzsnooze <chris.thompson@sydney.edu.au> Date: Wed Aug 16 15:09:29 2023 +1000 Fix debug_gps_altitude values (#12803) commit 21e3fb608d13a8b10b28728213f14be0069053fd Author: Kevin Plaizier <46289813+Quick-Flash@users.noreply.github.com> Date: Mon Aug 14 12:39:55 2023 -0600 Document where dshot documentation is found (#12997) commit 60a493b374fd8ca16cebf7b0bd77ba430bb498d9 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Aug 14 20:38:45 2023 +0200 Fix AT32 UART 7 and 8 (#13027) commit 958f49c35fba11f96bcd7e6e7da18749d258e056 Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Aug 14 20:38:22 2023 +0200 Fix MAX7456 clock configuration (#13030) commit 632a13b821f0c9180b022b2e05ff835f8c8f0fe6 Author: Cru Waller <24904289+cruwaller@users.noreply.github.com> Date: Mon Aug 14 21:37:12 2023 +0300 AT32F43x: make sure the SRAM configuration is valid (#13031) commit a5791814c03b569361f623a6f3b0058cffac4344 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sat Aug 12 13:31:12 2023 +0100 Allow for F7 UART idle preamble to be sent on startup (#13021) commit 083b5956170466405945501d2da97376eaaa3ba0 Author: Eike Ahmels <eike.ahmels@tu-dortmund.de> Date: Sat Aug 12 04:10:55 2023 +0200 M10 ValSet support, unit connection and reconnect stability (#12799) * WIP * start of implement m10 code * Fetch MON-VER from unit to check for unit version * test nav5 m10 command * missing empty lines * offload detect to config file * copy from hasli and organization * fix platform.h include * fix cli_unittest gps include * fix cli_unittest for gps calls * guard ublox version in gpsData * print human readable hw version * add utc_standard param and transfer with nav5 set add nav5x message for autonomous mode for m10 * fix typo * revert order structure, remove functions and reduce flash size * revert order structure, remove functions and reduce flash size * fix gps init and navx5 message * generalized nav5 message * remove unguarded debug * change ubx version detection, baud rate negotiation fix and save found baud * revert indentation * revert indentation and refactorings * the new code works with faster baud rate changes * remove unguarded debug statement * fix cli commands, major space reduce finished, removed extensions for now * ubx version checks, add valset for M10 * beta of valset, change suggestions from ledvinap and macgivergim * valset helper function and combine set nav rate valsets * more valset refactoring * remove big array and replace with macro * remove assert, as it can stop bf completely * refactoring to offsetof * making reconnect more resilient, reorganize rate setup, so it doesnt get missed on init * improved lost communcation detection, dont rely on ACK/NACK anymore * paket rate debug * adding debug mode, fixing major flight mode bug * revert fake flight "isConfiguratorConnected" * fixed proto detection, fixed reconfigure on too low updaterate * valset doesnt always send ACK, so we dont wait for it * size optimization, debug mode rename, minor fixes * implemented some requested changes * changed wait delay millisecond based * fixes from ctzsnooze and zzXyz * timer fixes * CamelCase new settings names * indent * Fix failure to enter flight model on GPS Fix * remove old commented out debugs * simplify timeouts * Clarify skip_acc and remove development valset code * accept PL's advice to remove >> (8 * 0 * Simplify package counter, remove reconfiguration based on packet count * fix error in package count introduced in previous commit * Fix delay detecting Configurator, ANA disable (for another PR) * address payload comments and fix logical error * indentation edits * delete old enum * log gps and firmware nav interval times * fix payload size, inc Rx buffer to 256, ifDef for sw_proto * remove token parsing (Petr suggestions) * fixes from reviews * Basic NMEA improvements * Address comments from karate * only check platform version - thanks zzyzx * Fix for too many sats problem - thanks zzyzx * tidy up comments, ifdef some ublox definitions * Use Nav packet intervals, NMEA and UBX, for time delta * Resolve comments and flatten conditionals * editorial change * single function for gpsSol.navIntervalMs * adam-ah suggestion for payload optimisation * ACK/NAK & polled message timer fixes * Revert timer fixes - unexpected side effects * Revert adam-ah suggestion for payload optimisation" This reverts commit 42fc8c04fdbc436c9ef196b88f0764ffcbb9239f. Broke the display of sat info when more than 32 sats in view * implement a number of comments * Fast task rate on new data, don't spam at the start thanks adam-ah * include PDOP for M10 via NAV-PVT * Address some of PL's recent comments * don't recalculate millis so many times * tidy up baudrate connect code * Split receiving of GPS bytes from processing by adding GPS_STATE_PROCESS_DATA * Split receiving of GPS bytes from processing by adding GPS_STATE_PROCESS_DATA * Preserve state whilst processing packets * Set gpsData.state directly as gpsSetState() clobbers gpsData.state_position * Restore original read time check * Schedule gpsUpdate() to run immediately again when a packet is received for processing * add debugs to display scheduler valuesl * simpler scheduler solution * minor debug change * FIxes: M10 connection, pDop, NMEA disable; thanks zzyxz NB: Breaks unit's neat reconnection methods M8 need a lot of settling time before using the serial port * ubx parse length sanity + cleanup + dashboard conditional compiles * Address recent comments from PL --------- Co-authored-by: ctzsnooze <chris.thompson@sydney.edu.au> Co-authored-by: ZzyzxTek <zzyzx@zzyzxtek.com> Co-authored-by: Steve Evans <Steve@SCEvans.com> commit 807a7229c9491b490d9fd605f04c5ae19c8de3d2 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Aug 9 12:10:15 2023 +0100 UART enable disable f4 (#13019) Enable/disable the F4/AT32 UART TX before changing the TX pin mode commit a54bc47e1bac6101421d1dfde5fe542d59b3152a Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Tue Aug 8 06:49:51 2023 +0100 Enable/disable the UART TX before changing the TX pin mode (#13017) commit 9bbe2836a47e2b54421bfc21fcdccbd3ab68d502 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Mon Aug 7 17:51:53 2023 -0500 Fix: disable sag compensation if RPM limit is active (#12918) commit 33db70793921fda5e7759e011b7b7e4ddabc0013 Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Aug 8 00:51:22 2023 +0200 Revert 12512 (#12956) commit bcc7c3fe03e9b84f9aed478f7f1458c0f504c99d Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Aug 8 00:50:48 2023 +0200 Rename default configuration macro's for vbat divider and multiplier (#12987) commit 199c0ec99decd33b8f6b083c70a63b73f978b3a8 Author: Dominic Clifton <dominic.clifton@cleanflight.com> Date: Tue Aug 8 00:49:48 2023 +0200 Fix escserial for HAL targets. (#12992) * Fix escserial for HAL targets. * Remove the code disabling ESCSERIAL for F7. * Timer/StdPeriph - Add an implementation of 'timerReconfigureTimebase'. Simply calls the `configTimeBase`, seemed cleaner than adding #ifdef USE_HAL_DRIVER everywhere instead. commit 0eac4df5a42d0dd1bea39292549f684bda71c87c Author: Mark Haslinghuis <mark@numloq.nl> Date: Mon Aug 7 12:32:23 2023 +0200 Remove sdcard include header from usb_io (#13007) commit 48316831554c6269dc605d087d2b899f2ff8b872 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Mon Aug 7 11:30:06 2023 +0100 Remove cs lock device (#12999) Remove csLockDevice as SD card cannot share an SPI bus commit dfef3bfb0e20a5a87e3df63e4425301ce19374d4 Author: Ivan Efimov <gendalf44@yandex.ru> Date: Sun Aug 6 10:32:57 2023 -0500 Added throttle flight statistics (#12978) * Added throttle flight statistics * Changed rc_stats.c/h license header to a modern one * rc_stats.c Style fix commit fb9587b2ec718448be9e6480c7b76da94d4152a4 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Sun Aug 6 09:06:50 2023 +0100 Use coloured fonts if supported (#13005) commit 5d29a0be0656303641b7004edcf8f22c770c5d22 Author: Steve Evans <SteveCEvans@users.noreply.github.com> Date: Wed Aug 2 15:16:58 2023 +0100 Fix MSP_DISPLAYPORT_UART assignment (#13000) commit 438e96c1f0370eef85f0cc72f6581407344c50bb Author: Mark Haslinghuis <mark@numloq.nl> Date: Tue Aug 1 11:24:32 2023 +0200 Rename flight mode (#12983) * Rename flight mode * Remove GND mode commit d5d3ee88beb63ded0f9c632c259cc31b0e9ad58e Author: J Blackman <blckmn@users.noreply.github.com> Date: Thu Jul 27 19:34:28 2023 +1000 Removing STM specific defines f…

ctzsnooze requested review from ledvinap and KarateBrot February 17, 2024 02:02

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch 2 times, most recently from efce723 to 96b7fd7 Compare February 17, 2024 06:09

ctzsnooze changed the title ~~Improve IMU responsiveness, identify and fix issue with Roll and Pitch in IMU code~~ Improve IMU responsiveness, refactor Feb 19, 2024

ctzsnooze added this to the 4.6 milestone Feb 19, 2024

ctzsnooze self-assigned this Feb 19, 2024

haslinghuis added the RN: REFACTORING label Feb 19, 2024

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch from 4f42db0 to a95394c Compare February 19, 2024 10:24

ctzsnooze mentioned this pull request Feb 20, 2024

IMU heading fix #13379

Closed

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch from b10ed42 to 09a0917 Compare February 21, 2024 11:11

ledvinap reviewed Feb 21, 2024

View reviewed changes

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch from ffb7b2c to fc0d115 Compare February 23, 2024 10:50

ledvinap reviewed Feb 26, 2024

View reviewed changes

ctzsnooze added 2 commits March 26, 2024 09:28

Revert debugs, update comments from review

1441173

lrintf for floats in debugs

8782bed

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch from 9609a0b to 8782bed Compare March 26, 2024 00:03

KarateBrot approved these changes Mar 26, 2024

View reviewed changes

haslinghuis approved these changes Mar 26, 2024

View reviewed changes

ledvinap reviewed Mar 26, 2024

View reviewed changes

ledvinap approved these changes Mar 27, 2024

View reviewed changes

Petr Ledvina added 4 commits March 31, 2024 17:28

vector.h - implement some vector2* code as vector*

1c392b8

Refactor IMU code

1125c15

Move compass and Cog code into separate functions, separate gain heuristics - imuCalcGroundspeedGain - imuCalcCourseErr - imuCalcMagErr Temporary refactor od imuDebug_GPS_RESCUE_HEADING, to be removed of optimized

Simplify simulator build conditional compilation

a921d44

Adapt unittests to IMU after refactoring

3054d2b

Maybe fix the test?

a99bd99

=

ctzsnooze force-pushed the fix-float-for-imuYawGroundspeed-at-slow-speeds branch from c7e9103 to a99bd99 Compare March 31, 2024 08:33

ledvinap approved these changes Apr 1, 2024

View reviewed changes

src/main/flight/imu.c Outdated Show resolved Hide resolved

src/main/flight/imu.c Outdated Show resolved Hide resolved

src/main/flight/imu.c Outdated Show resolved Hide resolved

src/main/flight/imu.c Outdated Show resolved Hide resolved

src/main/flight/imu.c Outdated Show resolved Hide resolved

haslinghuis and others added 5 commits April 1, 2024 21:26

Update src/main/flight/imu.c

b3834ad

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

Update src/main/flight/imu.c

9e4c5d2

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

Update src/main/flight/imu.c

6c7fecb

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

Update src/main/flight/imu.c

56385bd

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

Update src/main/flight/imu.c

959f72e

Co-authored-by: Petr Ledvina <ledvinap@gmail.com>

haslinghuis merged commit cd8b6aa into betaflight:master Apr 1, 2024
23 checks passed

ctzsnooze deleted the fix-float-for-imuYawGroundspeed-at-slow-speeds branch April 3, 2024 06:28

nerdCopter mentioned this pull request Apr 22, 2024

Fix debug mode DEBUG_ATTITUDE #13570

Merged


		// Compute heading vector in EF from scalar CoG. CoG is clockwise from North

	// Compute IMU / craft heading vector and magnitude in body X axis
	// Compute IMU / craft heading vector and magnitude from body X axis

Improve IMU responsiveness, refactor #13373

Improve IMU responsiveness, refactor #13373

Conversation

ctzsnooze commented Feb 17, 2024 • edited

github-actions bot commented Feb 17, 2024

ctzsnooze commented Feb 17, 2024 • edited

freasy commented Feb 17, 2024

ledvinap commented Feb 18, 2024

ctzsnooze commented Feb 19, 2024

ctzsnooze commented Feb 20, 2024

ledvinap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ctzsnooze Feb 23, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Understanding the Rotation Matrix

Practical Implications

Practical Use

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ledvinap commented Feb 21, 2024

ctzsnooze commented Feb 22, 2024 • edited

ledvinap commented Feb 22, 2024

tbolin commented Feb 23, 2024

ledvinap commented Feb 23, 2024

ctzsnooze commented Feb 24, 2024 • edited

limonspb commented Feb 24, 2024

limonspb commented Feb 24, 2024 • edited

ctzsnooze commented Feb 26, 2024 • edited

ledvinap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

limonspb commented Feb 28, 2024

ctzsnooze commented Mar 26, 2024

Choose a reason for hiding this comment

ledvinap commented Mar 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BrandonsBakedBeans commented Mar 26, 2024

ctzsnooze commented Mar 27, 2024

Choose a reason for hiding this comment

ctzsnooze commented Feb 17, 2024 •

edited

ctzsnooze commented Feb 17, 2024 •

edited

ctzsnooze Feb 23, 2024 •

edited

ctzsnooze commented Feb 22, 2024 •

edited

ctzsnooze commented Feb 24, 2024 •

edited

limonspb commented Feb 24, 2024 •

edited

ctzsnooze commented Feb 26, 2024 •

edited

ctzsnooze commented Mar 31, 2024 •

edited