DEV-922 Upstream gen-2 default alignment into SensorLSM6DSV - #282
Merged
Conversation
Replace the identity default-alignment placeholder with the real sensor->ASM matrices, making the driver the single source of truth for gen-2 (LSM6DSV/LIS2MDL) default calibration and letting the parser-side applyGen2DefaultAlignment override in ASM_PC/VerisenseDriver be deleted rather than corrected in two places. The literals are stored in APPLIED form (physical = applied . (raw-bias)/sens), reading exactly as verisense-device-console displays them and as the web SDK declares them (calibrationDefaults.ts, CALIBRATION_SENSORS_GEN2); the driver-form AM handed to the calibration blocks is derived from them by a true matrix inverse, since UtilCalibration applies AM^-1. Accel/gyro share the chip mounting (det +1); the LIS2MDL frame is left-handed (det -1). No hardware-revision gate: only 2nd-generation revisions (SR61>=5, SR68>=9) carry this IMU, so any device instantiating this sensor class is gen-2 by construction. Verisense-only: com.shimmerresearch.sensors .lsm6dsv.SensorLSM6DSV (Shimmer3R) is a separate class and untouched. Builds on the DEV-922 mag-sensitivity fix (PR #281): stacked so the 667 LSB/Gauss change and this land together with one reference-CSV regeneration pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the gen-2 Verisense IMU driver (SensorLSM6DSV) to be the single source of truth for default calibration (alignment + magnetometer sensitivity), aligning the driver with the web SDK/device-console defaults and eliminating the need for a parser-time override downstream.
Changes:
- Switches gen-2 magnetometer sensitivity to the shared LIS2MDL constant (667 LSB/Gauss) instead of a local 6.666667 LSB/µT copy.
- Replaces the identity default alignment with the real sensor→ASM applied alignment matrices and derives the driver-form alignment via inversion.
- Updates accel/gyro/mag
CalibDetailsKinematicdefaults to use the new alignment matrices.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+262
to
+265
| public static final double[][] DEFAULT_ALIGNMENT_LSM6DSV_ACCEL_GYRO = | ||
| UtilCalibration.matrixInverse3x3(APPLIED_ALIGNMENT_LSM6DSV_ACCEL_GYRO); | ||
| public static final double[][] DEFAULT_ALIGNMENT_LIS2MDL_MAG = | ||
| UtilCalibration.matrixInverse3x3(APPLIED_ALIGNMENT_LIS2MDL_MAG); |
Member
Author
There was a problem hiding this comment.
Fixed in 74119a1 — the mag driver-form matrix is now written as a literal (it is its own inverse), with a comment explaining the -0.0 hazard; the accel/gyro inverse (det +1) computes canonical 0.0 entries and stays derived. ASM_PC_00032's Test_04 round-trip guards that the literal really is the inverse of the applied form. Full ASM_PC suite re-run green (70/70 + 7/7) with no reference changes, confirming the stored matrix never leaked into CSV output.
matrixInverse3x3 on the mag applied matrix (determinant -1) stamps -0.0 into all six zero entries, which survives serialization and fails Arrays.deepEquals against 0.0. The matrix is its own inverse, so write the driver-form literal directly; ASM_PC_00032 guards that it really is the inverse of the applied form. The accel/gyro inverse (det +1) computes canonical 0.0 entries and stays derived. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ment The four CAL regression-lock assertions in test001 still expected identity alignment and fail against the upstreamed gen-2 defaults: calibrated accel/gyro X/Y/Z now come from raw Y/Z/X. Recompute the literals for the applied alignment, extend the lock to all three axes of accel and gyro, and add mag CAL assertions so the 667 LSB/Gauss sensitivity and the left-handed mag alignment (X/Z/Y) are pinned at the data level for the first time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WaUPkLZVnndWPEixyHcbVy
…view-78o8nq DEV-922 Update API_00008 CAL expectations for the gen-2 default alignment
Review of the web SDK (calibrationDefaults.ts, commit 687a31d) and the firmware seed (asm_calibration.c) against these constants surfaced three comment-level corrections: - Document the applied-form trap on the alignment block: the device and console store/write alignment in APPLIED form, but the existing per-unit load paths copy bytes into the AM slot without inverting. Harmless today (neither path serves this sensor) but calibration would be applied backwards if gen-2 per-unit loading is enabled without inverting first. - The no-hardware-gate rationale cited hardware revisions, but the actual gate is the firmware payload-design check in VerisenseDevice.sensorAndConfigMapsCreate(); reword to match the real mechanism. - Note that 667 LSB/Gauss is the established rounding of the exact 666.67 (1.5 mGauss/LSB) rather than the datasheet value itself. Comment-only change; ShimmerDriver test suite green (51 tests). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WaUPkLZVnndWPEixyHcbVy
jyong15
changed the title
- The applied-form WARNING now covers both directions: the write path (generateCalParamByteArray) also skips inversion, so writing calibration to a gen-2 device would send driver-form matrices where the firmware and console expect applied form. - The no-hardware-gate javadoc no longer implies the FW/HW pairing is enforced; a gen-1 board flashed with gen-2 firmware would get this frame too. - 666.67 LSB/Gauss is itself a rounding of 2000/3, not an exact value. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WaUPkLZVnndWPEixyHcbVy
jyong15
approved these changes
Aug 4, 2026
jyong15
left a comment
jyong15
left a comment
Collaborator
There was a problem hiding this comment.
Looks good, proceeding to merge
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Makes the driver the single source of truth for gen-2 (LSM6DSV / LIS2MDL) default calibration, so the parse-time
applyGen2DefaultAlignmentoverride in ASM_PC/VerisenseDriver can be deleted before customer deployment instead of living on as a second copy of the same values.DEFAULT_ALIGNMENT_MATRIX_LSM6DSVplaceholder is replaced by the real sensor→ASM matrices, stored in APPLIED form (reading exactly as verisense-device-console displays them and as the web SDK declares them inCALIBRATION_SENSORS_GEN2), with the driver-formAMderived by a true matrix inverse sinceUtilCalibrationappliesAM⁻¹. Accel/gyro share the chip mounting (det +1); the LIS2MDL frame is left-handed (det −1). Note: removing the old public constant is a binary-incompatible change for anything compiled against the previous jar.SENS_MAGreferences the sharedSensorLIS2MDLconstant (667 LSB/Gauss) rather than a local 6.666667 LSB/µT copy — JC's fix, merged separately as DEV-922 Mag sensitivity fix #281 and included in this branch's history. Gen-2 mag output rescales by ×100.05 (≈÷100: both constants are roundings of the chip's 1/0.15) and is now labelled consistently with every other Shimmer magnetometer.API_00008CAL expectations updated for the new alignment, extended to all three axes, plus first data-level mag CAL coverage (667 LSB/Gauss + left-handed alignment) — merged via DEV-922 Update API_00008 CAL expectations for the gen-2 default alignment #283.7b83b81,316df2d): documented the applied-form trap for per-unit calibration in both directions (load paths don't invert;generateCalParamByteArraydoesn't invert on write either); the no-hardware-gate rationale now cites the real mechanism (the FW payload-design-v13+ instantiation gate inVerisenseDevice.sensorAndConfigMapsCreate()) and no longer implies the FW/HW pairing is enforced; 667 noted as the established rounding of 2000/3 LSB/Gauss.Cross-repo verification
calibrationDefaults.tsCALIBRATION_SENSORS_GEN2element-for-element (as corrected by shimmer-web-sdk687a31d"update alignment matrix", 2026-07-29).asm_calibration.c: "ST-confirmed"). The specific mag axis permutation currently rests on the web SDK correction alone — the firmware seed disagrees (90° about Y) and no recording-based validation of the mag frame exists yet; flagged to the calibration owner.asm_calibration.cSC_LSM6DSV_ALIGN/SC_LIS2MDL_ALIGN) still carries the pre-687a31dmatrices and needs its own ticket; the driver's accel default sensitivity (32768/FS·g form) differs ~0.058% from the ST-nominal values used by the firmware, the web SDK, and this repo's ownSensorLSM6DS3/SensorLIS2DW12.Validation
API_00008_VerisenseLsm6dsvTaggedFifoParsing4/4 and full:ShimmerDriversuite green (51 tests, 6 classes).ASM_PC_00032_Gen2DefaultAlignment(rewritten on the companion branch to guard the shipped defaults): 7/7 green against this branch.ASM_PC_00005_VerisenseFileParserPC(70 tests) against this branch + the companion override-removal: only the 14 Mag_CAL reference CSVs changed (the deliberate mag Gauss rescale, refs regenerated); every accel/gyro/GSR/light/skin-temp comparison stayed byte-identical — proving the alignment upstreaming itself changes no parsed output.Sequencing
version = '0.11.7_beta'inShimmerDriver/build.gradleand publish a new artifact. The repo itself has no publish automation (the GitHub workflow only builds) — if the team's Jenkins handles publishing, use that; otherwise rungradle publishmanually.maven.pkg.github.com/ShimmerEngineering/Shimmer-Java-Android-API— the ShimmerEngineering org, not ShimmerResearch — confirm target/credentials before publishing. (ShimmerDriverPC/build.gradlecarries its own0.11.7_betastring; bump it too if the PC artifact is released.)com.shimmersensing:shimmerdriverpins (VerisenseDriver/build.gradleandVerisenseFileParser/build.gradle), mergeDEV-922_remove_gen2_alignment_override(#362) into theDEV-922branch, then #360 tomain. (Separately:VerisenseHealthCheck/build.gradlepins a staleshimmerdriverpcdev:ASM-2168_v0.4artifact no current build publishes — pre-existing, worth its own cleanup.)Jira: DEV-922
🤖 Generated with Claude Code