If IMU configured for upward facing Z axis (ISO 8855), calibration fails.

[stieg]

Starting with 2.9.0 Race Capture will be completely standardized around the SAE J670E standard. While we don't intend to directly support other standards such as iso885, users may still want to be able to configure their units to record in this manner. This then causes an issue: calibration will fail. The reason is that calibration will expect the Z axis value to be at 1g, not negative 1g. As a result, the unit will try and compensate for this, and will be unable to (because of its expectations, the end result will be 3G). To fix this, let see if we can make the calibration logic a bit more friendly. If we assume that the user has correctly set the axis with the vehicle prior to calibration, then we should be able to tell whether the user wants the Z axis in positive or negative mode based on the value we read (it should be somewhat close to 1 or somewhat close to -1 if done correctly). Based on that, we can calibrate using a smarter methodology, and somewhat support the users who want the ISO 8855 standard. Again, we don't intend to support it fully, rather this is a good compromise.

[brentpicasso]

This may be fully addressed by this app feature: https://github.com/autosportlabs/RaceCapture_App/issues/548

[stieg]

Will it? Calibration is done by the firmware so the firmware would need to handle that case. I'm thinking just looking at what the mapped Z axis is close to. If its < 0, then it should be targed at -1. if its > 0, then it should target 1. That is all

[stieg]

Took a look into this. While I could implement the aforementioned fix in some manner, the chances of it having other undesirable side effects out weighs the benefits gained by implementing this. For this to work properly, we would need to add a parameter to our config that indicates the standard by which we are aligning our axis. Then and only then would we know the expected values for the Z axis when calibrating (so we would end up with the correct value). Also for this to work correctly with the rest of our stack (thinking Podium here) we would need to send this orientation config to RCL so it could know the direction of the forces. This would be a key piece of meta-data since you would need to know this in order to compare against another driver who may be using a different orientation configuration.

At this point, I don't think its worth solving now. There just isn't enough demand for this right now. But that could change and, if so, we may need to implement this at a later date. For now I'm going to mark this specific issue as won't fix. Just not worth it right now. If we notice a demand for ISO 8855 support, we should open another ticket and target it for a Y release.