thank for your Job. I made the IMU temperature calibration just time ago over two FC: Pixhawk 6C (2 IMUs) and Pixhack V3x (3 IMUs). I want to share my results in order to know your opinion about the results:
Pixhawk 6C
In this case my doubt is about the Accel curves (all IMUs); it shows a slope in the “uncorrected Y” and “corrected Y” (point by red arrow). I don’t know if it is a sign of movement during the calibration period.
Thank you for your time, and whoever wants to comments
I’ve been using your Annotation script and it’s working really well. Do you have (or know of) a script that will pull all the non-default parameters from a full parameter file? I know MP has an option to show non-default parameters but it won’t extract just those to a file.
@amilcarlucas Hey i saw there is something like.
Z vibrations are caused by the downwash of each blade hitting the arm and the forward traveling propeller hitting the oncoming air when moving.
how i could fix that?
I installed bluejay then went to install the bd firmware and discovered there isnt a bdshot fimware for hte speedybeef405mini or the JHEMCU-GSF405A that I have. Is there a reason those boards dont support it?
I don’t really know whether the answer is right, but it seems from experience that Bluejay understands options 2 and 4 for SERVO_DSHOT_ESC (that is, both related to blheli_s).
At least they work well in flight, and option 4 enables extended telemetry. There is not really much coming via extended telemetry in the case of typical hardware running Bluejay, but I am working on supporting Extended DShot Telemetry v2 in Ardupilot, which will bring some status information about how much an ESC struggles to keep it going.
2 or 4. The reason the settings are different is because BLHeli_S/BlueJay use MCUs that are not able to leverage some of the newer features of 32-bit MCUs (e.g. DMA) and thus are quite timing sensitive (they use bit-banging instead). The settings change the calculation of the high/low period for dshot in a way that these firmware’s seem happier with. Why don’t they follow the standard you might reasonably ask? Well first off there isn’t really a “standard” for dshot timing. The output bitrates are fixed, but the duty cycle within that is not. Second off, blame BetaFlight - my suspicion is that many ESC manufacturers only test against BetaFlight in development - so if it works in BetaFlight they assume “job done” and move on. But BetaFlight itself also has some variability in timing because it also uses bit-banging in many instances. So what this boils down to is us trying to replicate BetaFlight timings on a very different platform, without a standard - and surprise, surprise, not everything works as expected.
