RPM Limiter #12054

Tdogb · 2022-12-15T17:41:40Z

RPM Limiter
Hey all, this pull request contains rpm limiter code which I have written in order to make spec racing more fair. The RPM limiter attempts to limit the average RPM using a pid controller.

Motivation:  In spec racing, limiting RPMs through software instead of through hardware saves money, keeps components competitive for longer, and allows quads with different hardware setups to race competitively.

Standard RPM Limiter:

Limits to a max average rpm set by set rpm_limit = 130 means 13000 rpm. Average was chosen for better feel in the turns
When rpm goes above the setpoint (rpm limit), two things happen
- PID controller is activated, which pulls the mixer throttle down
- A continuously “learned” scaled throttle limit is regulated down
When rpm goes below the set point (rpm limit)
- A continuously “learned” scaled throttle limit is regulated up if the throttle is high (above 1950 does anyone know a better way of testing for high throttle?)
I term is never allowed to go below 0 because I term should never be raising the rpms

Standard RPM Limiter Problems:

If user sets an rpm limit far below the max rpm of the motors, the throttle will have a deadzone on launch until the throttle limit is quickly learned. This effect can be reduced if the user sets an appropriate throttle limit.

Standard RPM Limiter Throttle Limit Learning:

Throttle limit is slowly ramped up/down based on the output of the pid controller. Therefore the longer the pid controller spends pushing down the throttle the more throttle limit is added and vice versa.
If there are saturated motors, this means that the rpm limit may be too high, so there is no reason to up the throttle limit

RPM Linearization
While experimenting with the rpm limit, I decided to try setting the rpm limit proportional to the current throttle. I then kept the PID controller turned on the entire rpm range. This would attempt to control the RPM such that it is proportional to the throttle. This essentially turns rpm linearization into a sort of closed loop vbat sag compensation. Making the throttle response feel more consistent and independent of the battery voltage. It also made the throttle more consistent on a high throttle launch since the pid controller was proactively controlling the rpms to the setpoint.

RPM Linearized Limiter

Rc command controls the rpm limit, starting at rpm_limiter_idle_throttle at 0 throttle and going to ‘rpm_limit’ at full throttle
PID controller is continuously ran
If the throttle is below 0, the I term will be ramped down in order to avoid windup

Benefits of RPM Linearization

Throttle response is quicker. With a critically damped controller, the throttle can be brought up to full for a few ms in order to reach the setpoint as fast as possible
Throttle feels more consistent regardless of the state of the battery
Potentially better throttle feel on 5” toothpicks and tiny whoops? (Have not tested)

Downsides of RPM Linearization

Throttle response feels more linear and some people might not like this
- Potential solution: Also include a way to customize the throttle curve in the rate profile instead of forcing a linear relationship

The acceleration limit

Limits the maximum change in setpoint of the rpms
A spec can choose an acceleration limit close to the max acceleration of the weakest motor allowed by the spec. This further reduces the difference between motors in actual racing

—————————————————————————————
What I think still needs to be improved

Code readability and optimization? Should I add comments?
Play nicer with air mode (remove the hacky fix)

What needs to be discussed

Is there a simpler way of accomplishing this?
RPM linearization provides some benefits/downsides outside of limiting rpm. Should this be called an rpm limiter anymore? Should this be a separate feature? I hope people give it a try and comment on it.
- Should the rpm thrust curve to be a part of the rate profile and set it similarly to how you would set a rate curve

RPM Limiter is being beta tested for spec racing in Street League, and community feedback is going to be gathered. I believe this has great potential outside of just the spec racing community, so I am making this pull request.

Tested on:

7” Street League Spec
5” 2070kv 6s
5” 2070kv 3s

Not tested on:

Whoops
3”

Media:
DVR Dump: https://drive.google.com/drive/folders/1PEOfvd8uQwPa_J3lpeEmDEtxwCNh0rn6?usp=share_link
Street League Announcement Video (Includes blackbox of measured average RPM overplayed on video): https://www.youtube.com/watch?v=wF7rOV6DJGA

blckmn · 2022-12-15T19:17:09Z

AUTOMERGE: (FAIL)

github identifies PR as mergeable -> FAIL
assigned to a milestone -> PASS
cooling off period lapsed -> PASS
commit count less or equal to three -> FAIL
Don't merge label NOT found -> PASS
at least one RN: label found -> PASS
Tested label found -> FAIL
assigned to an approver -> FAIL
approver count at least three -> FAIL

Quick-Flash · 2022-12-15T19:33:24Z

src/main/flight/mixer.c

+            if (mixerConfig()->rpm_limiter_rpm_linearization) {
+                throttle = constrainf(-pidOutput, 0.01f, 1.0f);
+            } else {
+                throttle = constrainf(throttle-pidOutput, 0.01f, 1.0f);


really, throttle should be allowed to go all the way down to 0.0, otherwise it is just like adding more idle.

This was supposed to fix an issue headsup was having with two of his motors stopping completely when arming and rolling while still on the launch blocks. I can't reproduce it now though so I'll assume his dshot_idle_rpm is set wrong.
This is something that dynamic idle does on line 648 as well
throttle = MAX(throttle, 0.01f);

src/main/flight/mixer.c

Quick-Flash · 2022-12-15T19:38:55Z

src/main/flight/mixer.c

+                motorsSaturated = true;
+            }
+        }
+        averageRPM = 100 * averageRPM / (getMotorCount() * motorConfig()->motorPoleCount / 2.0f);


This line of code is a good reminder that we should just have one place in the code where RPM is calculated, and then just pass it around to all the other parts of code that need it.

Would this also be the opportunity to read that value is as a UINT16 so we can end-run around the identified overflow at 32767, and sanity check that behavior?

src/main/flight/mixer.c

Quick-Flash · 2022-12-15T19:54:09Z

src/main/flight/mixer.c

+            float acceleration = scaledRPMLimit - mixerRuntime.rpmLimiterPreviousRPMLimit;
+            if (acceleration > 0) {
+                acceleration = MIN(acceleration, mixerRuntime.rpmLimiterAccelerationLimit);
+                scaledRPMLimit = mixerRuntime.rpmLimiterPreviousRPMLimit + acceleration;


This line of code look just like the sort of FF that BF uses for the rate controller. You may consider adding a FF gain to this acceleration.
This bit of code will also act different if you are running a different pidloop rate. IE faster pidloops will have less of the acceleration effect, while slower pidloops will have more of an acceleration effect.

Also why don't you allow negative acceleration? wouldn't we want to slow the motors down faster?

Could you elaborate what you mean with the feedforward? This is just the code which limits the acceleration of the rpm setpoint.
Looptime is taken into account in mixer_init.c on line 340
mixerRuntime.rpmLimiterAccelerationLimit = mixerConfig()->rpm_limiter_acceleration_limit * 1000.0f * pidGetDT();
Acceleration limit is only applied when positive because otherwise this would apply a deceleration limit limiting how fast the motors could spin down. I tested this, and in my opinion it feels weird and unsafe especially with low limits.

oh, i was reading this bit of code wrong, I thought that this was adding an acceleration to the new scaledRPMLimit, not adding a slew filter on the acceleration limit. Ahh so this is just s slew limit filter, i see now.

Quick-Flash · 2022-12-15T19:56:10Z

src/main/flight/mixer_init.c

@@ -322,6 +331,19 @@ void mixerInitProfile(void)
        }
    }
 #endif
+
+#ifdef USE_RPM_LIMITER
+    mixerRuntime.rpmLimiterExpectedThrottleLimit = 1.0f;


You should try and figure out how to store the value of this once you disarm. That way the learned limit won't have to be relearned every time you plug in a new battery.

Tdogb · 2022-12-15T20:30:34Z

src/main/flight/mixer.c

+        }
+        float smoothedRPMError = averageRPMSmoothed - scaledRPMLimit;
+        float rpm_limiterP = smoothedRPMError * mixerRuntime.rpmLimiterPGain; //+ when overspped
+        float rpmLimiterD = (smoothedRPMError - mixerRuntime.rpmLimiterPreviousSmoothedRPMError) * mixerRuntime.rpmLimiterDGain; // + when quickly going overspeed


Line 338 and 339 in mixer_init.c account for the loop frequency
mixerRuntime.rpmLimiterIGain = mixerConfig()->rpm_limiter_i * 0.0001f * pidGetDT();
mixerRuntime.rpmLimiterDGain = mixerConfig()->rpm_limiter_d * 0.00000003f * pidGetPidFrequency();

just saw, good job.

src/main/flight/mixer.c

Quick-Flash · 2022-12-15T20:13:14Z

src/main/flight/mixer.c

+        } 
+        else {
+            throttle = throttle * mixerRuntime.rpmLimiterExpectedThrottleLimit;
+            scaledRPMLimit = ((mixerConfig()->rpm_limiter_rpm_limit)) * 100.0f;


I do not understand this line of code, it seems wrong as it will always use the same number here for the scaledRPMLimit, which will create a very weird error when you compare it to the average motor output. Say you are at idle, this would always assume that there is a very large error...

Line 376 is applying the dynamic throttle limit
Line 377:
You are correct that there would be a large error, but I limit the pid output to only be positive on line 406. This is because we only ever want the pid controller to reduce the throttle to bring rpms to the setpoint. The regulation is admittedly not the best, which is why I tested pre-activating the pid controller once the rpms got close to the limit, but this felt really weird. I think the dynamic throttle limit helps hide poor regulation, but this was also why I started experimenting with linearization which doesn't have this issue.

I guess I would need to see some logs of that method to see what its doing a bit better.

Quick-Flash · 2022-12-15T21:09:22Z

@Tdogb when looking at the linearization version of the code I am surprised to see that there is just a PID controller. Say for instance that you are at hover throttle, and have nearly no error between the average RPM and what you say the desired average RPM should be, in this case you would only have iterm holding your hover throttle, which would mean that this controller is highly dependent on the iterm to control it. Without the iterm you would never reach the throttle that you want to reach. It would be nice to have some amount of FeedForward taking the rcCommand[Throttle] and multiplying it by some sort of dynamic_throttle_limit to try and be able to mainly rely on the estimated throttle needed (IE the rcCommand[Throttle] * dynamic_throttle_limit) and then use the pids to compensate for the rest. That would likely be the most responsive and the least likely to overshoot one way or another.

If I'm wrong here please correct me, but it seems that in a hover its pretty much just the iterm holding the throttle. Do you have any logs of the rpm pids during flight?

If this is using the linearization version than the first throttle up does show a fair bit of delay along with some overshoot, which can probably be fixed quite nicely.

Quick-Flash · 2022-12-15T21:19:04Z

I have always liked the idea of regulating the rpm on each motor independently to get it to more accurately achieve the requested motor output.

Tdogb · 2022-12-15T23:30:58Z

@Quick-Flash I really like the idea of a feedforward. Maybe worth looking into. Here are some blackbox logs to look at https://drive.google.com/drive/folders/1TmjaugqXaCLQKI3WepCKa-czvUOtbgJF?usp=share_link
In the logs, debug values are as follows. Ignore the first debug value.
DEBUG_SET(DEBUG_RPM_LIMITER, 1, smoothedRPMError);
DEBUG_SET(DEBUG_RPM_LIMITER, 2, mixerRuntime.rpmLimiterI * 100.0f);
DEBUG_SET(DEBUG_RPM_LIMITER, 3, rpmLimiterD * 10000.0f);

Quick-Flash · 2022-12-15T23:47:55Z

rpmLimiterD

Kinda like I expected, you see the motors begin to move once the integral goes low enough (since your using negative pid for your output. Should probably reverse the sign so that you can use a positive pid rather than negative.)

Quick-Flash · 2022-12-15T23:55:19Z

It really seems to be filtering your stick response . An estimated FF would likely help a lot here.

Quick-Flash · 2022-12-15T23:58:01Z

Are these logs all taken on the same drone? if so it seems that the linearized version is adding noise to your motors :( as the nonlinearized log has cleaner motor traces.

Quick-Flash · 2022-12-16T00:02:39Z

to help with logging making sure that the setpoint throttle is logged after you change it would be useful. But yes the non linearized version looks like it doesn't depend much on the pid controller,

Also logging the averaged RPM would be useful to help see whats happening. Thanks for the logs BTW

Tdogb · 2022-12-16T00:09:30Z

Logs are from the same drone, it has a crazy tune on it, so the motors look noisy even with the rpm limiter off, they don't get hot though. I'm wondering, since rpm limiting does not require critical accuracy or response times, might be worth it to move the PT1 cutoff frequency even lower and just ensure we are always getting clean traces. Another thing to note is that the rpm linearization uses much lower pid terms than the non-linearized does. Maybe relying more on FF than the other gains may help with the noise? Definitely want to try it out.

Btw, which log are those screenshots from? Is that linearized or non-linearized?

Quick-Flash · 2022-12-16T00:41:26Z

Btw, which log are those screenshots from? Is that linearized or non-linearized?

First is the hover log, and second is the linearized log.

Tdogb · 2022-12-16T01:24:12Z

It really seems to be filtering your stick response . An estimated FF would likely help a lot here.

Bit confused on what you're referring to here? Since stick command is controlling setpoint, the error instantly increases right

Quick-Flash · 2022-12-16T07:18:09Z

It really seems to be filtering your stick response . An estimated FF would likely help a lot here.

Bit confused on what you're referring to here? Since stick command is controlling setpoint, the error instantly increases right

The rc command throttle isnt instantly showing an increase in motor values. It should, but here it isnt.

Quick-Flash · 2022-12-16T18:56:10Z

@Tdogb

I hope this helps show it better.

Tdogb · 2022-12-16T19:41:18Z

I'll get some blackbox logs with less noisy motors/tune and check. Hard to see through all that noise. I'm sure a FF will help though

Quick-Flash · 2022-12-16T19:45:52Z

I'll get some blackbox logs with less noisy motors/tune and check. Hard to see through all that noise. I'm sure a FF will help though

If you do log the pre throttle and the post throttle. Thatd be super helpful.

Tdogb · 2022-12-16T19:51:51Z

I just found a major issue, on smaller quads with faster motors, there is an overflow at ~32767 rpm, which causes average rpm to go negative. This can be seen at 00:18 in this video: https://drive.google.com/file/d/1PJtOv1aXg0CtlhtxdG7aZf0vEKtOJpfl/view?usp=sharing
This results in a runaway. The first value in the osd debug element is the average rpm. This seems to correspond to the point where a short overflows, yet I'm not using shorts in my code...

Quick-Flash · 2022-12-16T19:56:18Z

32767

Thats a 16 bit signed overflow. for RPM values it makes more sense to read it as a u16 rather than an i16 as that would double the rpm. Only place I can see that could cause it in your code is the RPM telemetry giving you a negative number... but that doesn't make much sense. Unsure where in the code that would break.

Tdogb · 2022-12-16T20:24:38Z

What's weird is that the individual rpms reported on the osd still look good...something to note is that this is my only blujay quad, so maybe that has issues during a crash? I've noticed that on all esc firmwares, the reported rpm during a crash goes crazy

TehllamaFPV · 2022-12-16T20:44:55Z

I'm still trying to work out from a much more naive approach why a simpler scheme wouldn't work - practically from a spec series compliance standpoint, the intention is to ensure that no corner of the quadcopter is producing more thrust than the nominal spec combination (effective battery voltage * KV * propeller advance ratio .:. in whatever air column is present).
Leveraging existing VBatSagCompensation (or making the RPM Limiter functionality require this value to be 100, a pretty simple looptime calculation that dynamically establishes a motor output limit whenever an RPM value exceeds the nominal target should work, and require effectively zero memory functionality. Basically scale it to where 99% of nominal RPM is the calculated target based on current motor output limit, once any input value is provided that exceeds this the motor output limit is calculated as a down-scaled value [newMotorOutputLimit = oldMotorOutputLimit * limitedRPMvalue / received ESC TLM RPM Value], with an option to increment motor output limit anytime throttle value is >90% and highest observed TLM RPM value <0.99x limitedRPMvalue.
As long as there isn't some obvious race condition with dynamically setting the motorOutputLimit value, then it's easy (we'll just see excess torque delivery on motor commands for a matter of microseconds, but that's about 5ms of above-nominal performance at most).

The more elegant answer is just mirroring the existing RPM Dynamic Idle code as a top end limiter, and again structuring that as a hard-cap type limitation where that max RPM is not intended to be exceeded... but my above lazier approach still feels more robust overall (and would tend to fail stupidly, but in a non-flyaway state that would basically result in limping into a perch mode)

limonspb · 2023-04-22T07:06:44Z

Did some testing as well on very diverse setups - I'll need GPS data or something else high quality to pick out differences. 2400KV, 1750KV, 1960KV - the RPM limits make them fly all but identically.

I do want to figure out if we can retain a motor output limit that retains overhead, but doesn't result in gate clips resulting in yaw spins causing pairs of motors to go to 100%, I'm personally OK with giving up a little bit of authority in the default configuration if end users know they won't have full power on error/crash situations... I'm trying to work out if the motor % estimate padded out to 120% is enough for that.

you can try to use the motor output limit to control how much you want during the turns... But that will require re-turning, or at least adjusting the master multiplier.

TehllamaFPV · 2023-04-22T15:30:21Z

you can try to use the motor output limit to control how much you want during the turns... But that will require re-turning, or at least adjusting the master multiplier.

This is precisely what I'm looking to do with testing - basically use the RPM Spec with the LlamaSpec to provide the dynamic tune plus motor output limiting, so that if it's a spec bird, literally zero additional thought is required, it should fly basically the same no matter what battery voltage gets thrown at it. 4S 1800mAh and 5S 1500mAh packs have both worked really well for me.

Tdogb · 2023-04-22T15:40:01Z

I have a branch that does motor output limiting. I’ve tested it and it works. You need to use max rpm instead of average rpm with motor limiting https://github.com/Tdogb/betaflight/tree/rpm-limiter-max-rpm-pr
Using average rpm is more of a carry over from my rpm limiter work I did with street league, where the cornering characteristic of throttle limiting was desired over motor output limiting

TehllamaFPV · 2023-04-22T17:50:56Z

Right, at this point I'm also trying to see if I can build a TinyTrainer preset with the same overall layout, but that carries the motor output limiting with 10% margin for that as well (since those are much more backyard setups), and seeing if that can take the 'battery needs to be high end and fresh' away from that spec class as well.

Tdogb · 2023-04-22T21:47:25Z

I think it’s actually good that the quad had access to all of the motors since it makes it recover from crashes better. Also we’ve done tons of testing with the current rpm limiter and it has seemed to be great

limonspb · 2023-04-23T02:41:55Z

you can try to use the motor output limit to control how much you want during the turns... But that will require re-turning, or at least adjusting the master multiplier.

This is precisely what I'm looking to do with testing - basically use the RPM Spec with the LlamaSpec to provide the dynamic tune plus motor output limiting, so that if it's a spec bird, literally zero additional thought is required, it should fly basically the same no matter what battery voltage gets thrown at it. 4S 1800mAh and 5S 1500mAh packs have both worked really well for me.

i think we can use a dynamic motor limit to cap the RPM. But that should come with an automatic PID multiplier. And that requires more testing... If we ever come up with a limiter like that, we can just add another type. Instead of active yes/no we can have avg/max/off in future.

github-actions · 2023-04-23T03:47:14Z

Do you want to test this code? Here you have an automated build:
Assets
WARNING: It may be unstable. Use only for testing! See: https://www.youtube.com/watch?v=I1uN9CN30gw for instructions for unified targets!

limonspb · 2023-04-23T03:50:00Z

@KarateBrot @Tdogb
based on Jan's suggestions i did some renaming:

USE_RPM_LIMITER -> USE_RPM_LIMIT
rpm_limiter_rpm_limit ->rpm_limit_value
rpm_limiter (ON/OFF) -> rpm_limit
DEBUG_RPM_LIMITER -> DEBUG_RPM_LIMIT
Min/max for rpm_limit_value set to 1 - uint16_max (65535). (it was 0 - 60000)

limonspb · 2023-05-04T06:29:03Z

@Tdogb
noticed a small bug:
when you fly till the battery is dead, it never gives you 100% throttle limit for some reason. Stays 90-96, but never 100%, even when current RPM is almost zero because battery is dead, and throttle stick is 100%
Here is a blackbox, check the end of the big log:
rpm_limiter_to_battery_death.BBL.txt

limonspb · 2023-05-04T06:33:03Z

here you can see this log image.
The on screenshot the battery is dead.
throttle stick is 100%
current RPM is 6k (limit is set to 18k)
But the current calculated throttle limit is 97% instead of 100%:

Tdogb · 2023-05-13T17:01:53Z

here you can see this log image.
The on screenshot the battery is dead.
throttle stick is 100%
current RPM is 6k (limit is set to 18k)
But the current calculated throttle limit is 97% instead of 100%:

The bug is likely due to the check for !motorsaturated() in the condition to raise throttle scale. This is necessary so that the throttle scale doesn’t have the potential to be incorrectly boosted during hard turns. If we remove this check the throttle would feel weird coming out of a sharp turn.

A potential fix would be to slow down the throttle scale learning when a motor is saturated but that doesn’t fully fix the issue. Anyone have an idea for a better solution?

limonspb · 2023-05-14T08:19:05Z

here you can see this log image.
The on screenshot the battery is dead.
throttle stick is 100%
current RPM is 6k (limit is set to 18k)
But the current calculated throttle limit is 97% instead of 100%:

The bug is likely due to the check for !motorsaturated() in the condition to raise throttle scale. This is necessary so that the throttle scale doesn’t have the potential to be incorrectly boosted during hard turns. If we remove this check the throttle would feel weird coming out of a sharp turn.

A potential fix would be to slow down the throttle scale learning when a motor is saturated but that doesn’t fully fix the issue. Anyone have an idea for a better solution?

good catch that one of the motors was actually saturated. I did not notice that. Nothing we can do at this point i think. Even if we increase throttle cap, its not going to change anything. So PR its good to go IMHO

sugaarK · 2023-05-16T05:32:53Z

Need to address or dismiss @KarateBrot reviews

limonspb · 2023-05-16T10:19:39Z

Need to address or dismiss @KarateBrot reviews

yeah, they were addressed already. Just PR author didn't click close conversation.

KarateBrot · 2023-05-16T14:36:32Z

Oh, I see. I'll review again.

This comment has been minimized.

Sign in to view

Quick-Flash reviewed Dec 15, 2022

View reviewed changes

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

Quick-Flash reviewed Dec 15, 2022

View reviewed changes

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

Quick-Flash reviewed Dec 15, 2022

View reviewed changes

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

Quick-Flash reviewed Dec 15, 2022

View reviewed changes

This comment has been minimized.

Sign in to view

renamings

dc77b74

KarateBrot approved these changes May 16, 2023

View reviewed changes

KarateBrot removed For Discussion Testing Required In Development labels May 16, 2023

blckmn approved these changes May 28, 2023

View reviewed changes

blckmn merged commit 26701f0 into betaflight:master May 28, 2023
19 checks passed

AkankshaJjw pushed a commit to AkankshaJjw/betaflight that referenced this pull request May 29, 2023

RPM Limiter (betaflight#12054)

ddfbd82

limonspb pushed a commit to limonspb/betaflight that referenced this pull request May 30, 2023

RPM Limiter (betaflight#12054)

c403cd1

limonspb pushed a commit to limonspb/betaflight that referenced this pull request May 30, 2023

RPM Limiter (betaflight#12054)

0a4abb6

limonspb pushed a commit to limonspb/betaflight that referenced this pull request May 30, 2023

RPM Limiter (betaflight#12054)

099e30c

limonspb pushed a commit to limonspb/betaflight that referenced this pull request Jun 5, 2023

RPM Limiter (betaflight#12054)

821d7f6

limonspb pushed a commit to limonspb/betaflight that referenced this pull request Jun 20, 2023

RPM Limiter (betaflight#12054)

089db9b

limonspb pushed a commit to limonspb/betaflight that referenced this pull request Nov 12, 2023

RPM Limiter (betaflight#12054)

161e798

davidbitton pushed a commit to davidbitton/betaflight that referenced this pull request Feb 5, 2024

RPM Limiter (betaflight#12054)

3cb9b04

RPM Limiter #12054

RPM Limiter #12054

Conversation

Tdogb commented Dec 15, 2022

This comment has been minimized.

blckmn commented Dec 15, 2022 • edited

Quick-Flash Dec 15, 2022 • 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

Quick-Flash Dec 15, 2022 • 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

This comment was marked as resolved.

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

Quick-Flash commented Dec 15, 2022 • edited

Quick-Flash commented Dec 15, 2022

Tdogb commented Dec 15, 2022

Quick-Flash commented Dec 15, 2022

Quick-Flash commented Dec 15, 2022

Quick-Flash commented Dec 15, 2022

Quick-Flash commented Dec 16, 2022

Tdogb commented Dec 16, 2022

Quick-Flash commented Dec 16, 2022

Tdogb commented Dec 16, 2022

Quick-Flash commented Dec 16, 2022

Quick-Flash commented Dec 16, 2022

Tdogb commented Dec 16, 2022

Quick-Flash commented Dec 16, 2022

This comment has been minimized.

Tdogb commented Dec 16, 2022 • edited

Quick-Flash commented Dec 16, 2022 • edited

Tdogb commented Dec 16, 2022

TehllamaFPV commented Dec 16, 2022

limonspb commented Apr 22, 2023

TehllamaFPV commented Apr 22, 2023

Tdogb commented Apr 22, 2023 • edited

TehllamaFPV commented Apr 22, 2023

Tdogb commented Apr 22, 2023 • edited

limonspb commented Apr 23, 2023

github-actions bot commented Apr 23, 2023

limonspb commented Apr 23, 2023

limonspb commented May 4, 2023 • edited

limonspb commented May 4, 2023

Tdogb commented May 13, 2023

limonspb commented May 14, 2023 • edited

sugaarK commented May 16, 2023

limonspb commented May 16, 2023 • edited

KarateBrot commented May 16, 2023

blckmn commented Dec 15, 2022 •

edited

Quick-Flash Dec 15, 2022 •

edited

Quick-Flash Dec 15, 2022 •

edited

Quick-Flash commented Dec 15, 2022 •

edited

Tdogb commented Dec 16, 2022 •

edited

Quick-Flash commented Dec 16, 2022 •

edited

Tdogb commented Apr 22, 2023 •

edited

Tdogb commented Apr 22, 2023 •

edited

limonspb commented May 4, 2023 •

edited

limonspb commented May 14, 2023 •

edited

limonspb commented May 16, 2023 •

edited