Accelerometer value failures on 1.9.2 stable only #12929
Comments
|
So for good measure I went and formatted the SD card (read some old issues about this), flashed 1.8 then back to stable (1.9.2) tried again and all the same. Not same exact numbers but way off. After calibrating on sensors on 1.8: CAL_ACC0_EN 1 Then on 1.9.2: So it seems to be only effecting Accel1 but Accel0 is the one failing the sensor tests... @dagar Weird as just changing firmwares (back) and calibrating fixes it. Also, didnt load old params in a few tests, flashed stable, hit airframe and redid all params from scratch just to try. Still no go. |
|
I hate to say this, but the likely reason the are way off now might be less due to the fact that they are wrong now than it was to the fact that they were wrong in the past... The drivers have had sooooooooooooooooooooooooooo many errors, (not anyone's fault, just the way it is), that correcting them is literally never-ending. Let's do some work to prove the current trustworthiness between now/then and determine which is right, (given all that we understand at this present moment...). But, let me assure you... this is going to be some work on your part! -Mark |
|
The ever present nature of driver errors and changes seems logical at a high level as has been understandably and expectedly been the case with anything going under constant involvement since the inception of the codebase but how something can differ so greatly and on such magnitude (given what that means from an operability standpoint) strikes me as odd if not hardware related. A mere hardware issue would be more palatable short of just a PR that “broke” the reporting output and this not be situational to my tests. I haven’t looked at what was changed between the version variants but having accel and gyro fail tests on 192 and not on 180 seems like logically (at least from my view) that the problem isn’t on the older firmware. Two different sensors reporting fails only on a newer software variant. That would seem like this is either something in my specific setup or on the newer software only. Or simply something in the test So, to get some further evidence on that I took a Pixhawk 4 sitting here (never flown, never crashed, etc - the last test was on a Pixhawk 1 [with 2mb of flash running fmu_v3]) and did the same tests as before. The same thing occurred. See attached. So now that accel and gyro is failing on a new Pixhawk 4 and Pixhawk 2 under 1.9.2 means I would like to think it is not hardware and is either something I have set inadvertently (although I reset all parameters) or something, like you said is driving this haywire. The big differing thing that is really important here which may make it hardware related is between the two sets of tests, the magnitude of differences in sensor offsets (they are actually quite close on the Pixhawk 4 under both firmware versions, but then still failing the sensor tests only on 1.92). Pixhawk 4 on 192 stable Pixhawk 4 on 180 CAL_ACC0_EN 1
|
|
Can you check |
|
|
|
Do you need to see them on 192? |
|
A lot of the output is missing (accel section, etc). Can you try again? |
|
@ryanjAA , I'll try to get some time into this tomorrow. Thanks for your work so far! |
|
@dagar redid it (same unit). Here:
|
|
Hi @ryanjAA , it somehow looks like the values you have shown in bold above are additive, meaning the value of Unfortunately, when I check my flying airframe with v1.8.2 downloaded here, v1.9.2 downloaded here, and with current master branch, I'm not seeing the same issue you are seeing. From my autopilot after calibrating with v1.8.2, then again with v1.9.2, and finally with master, these are my calibration values, (they all seem to agree very well): Could you try loading v1.8.2 from the release binaries, calibrate, then v1.9.2 from the release binaries, and recalibrate and post the values reported back for each from |
|
So heres a strange thing, I just opened another MRO Pixhawk 1 (wanted to see with a brand new unit). Never put 1.8x on it, just updated to stable 1.9.2 (fmu_v3) and did all the calibration after loading in our used settings for everything. Ran param show CAL_ACC* and get strange offsets:
So the question then probably becomes if this isn't firmware directly, what setting(s) in a param file can mess with this to such an extent? |
|
@ryanjAA , can you try resetting all of your CAL_* values to default, recalibrating, and see if the issue persists? Also, can you look at the param file you are loading onto blank autopilots and see if the CAL_ACC* values are way off zero? |
|
Unfortunately, thats actually what i did before doing the calibration, i figured setting them to default would be the best thing. Interestingly, even though the offset is incredibly different on the two sensors (ACC0 and ACC1 and maybe that is actually within what is acceptable), the error is sporadic. For instance, i was able to arm it just now but there doesn't seem to be a rhyme or reason to it for when and when not. As to the CAL_ACC* in the canned config file, they are as follows: CAL_ACC0_XOFF -0.040366649627685547 |
|
Well... this is a real pickle... I knew when I told you it would be work for you it would be work for me too... ;) I'll have a bit of time to dig into the code in the next few days. Learn what you can and I will do the same! I will report back as I make progress. |
|
@ryanjAA , can you test again to see if this is present in the current master branch? So far I am unable to reproduce... I don't understand what's going on here. :/ |
|
@ryanjAA , any updates? Nothing to report from my end. |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
Accel 0 and 1 differ greatly when running (1.9.2) stable from 1.8.0 . Can't arm since offsets are so high.
Have done multiple calibrations for good measure, all end up similar, close on 1.8, far on 1.92
Same exact plane used but with firmware 1.8.0 and works fine, same hardware, same everything.
Quick look at the tests sensors and see attached images.
Nothing has moved, even the time when done were right after each other except the firmware.
The text was updated successfully, but these errors were encountered: