Hi!
We are currently trying to accomplish a task where we use our sub in normal, flying mode, in one setting, but then in another mode, we dock it to a ship hull and drive around on the hull. I.e. 90 degrees on the flying mode. Due to the gimbal lock, one of these modes will have problems steering using roll, yaw and pitch values.
Is there a way to auto calibrate the vehicle between these modes?
Can I store the calibration values and then apply them to our vehicle when needed?
Hi @Guri, welcome to the forum 
I’m not aware of a way to do either of these, so I’ve asked internally and hopefully one of the engineers who’s done more work with ArduSub’s attitude control will be able to help, but it’s quite possible such a feature doesn’t exist in which case you’d need to develop it yourself if you wanted to use it.
Hi @EliotBR, thank you for your kind answer! 
I did look into programming this myself, but couldn’t figure out how to do it as it looks like the sub collects its calibration data without exposing them to the ArduSub program?
In the end I found that my gimbal lock problem is solved by calibrating our vehicle with Pitch315 calibration settings. That way, neither horizontal plan nor vertical plan are in gimbal lock and I can navigate nicely in both directions.
I would love to hear the result from the engineers when they get back, though. Our solution is a bit hacky, so a recalibration with predefined settings would be a better solution for us.
Cheers!
Smart thinking to solve the issue at hand
Also, are you using a Blue Robotics electronics enclosure? We have it so that the Pixhawk is on its side normally (Roll90 - base vertical, and flat against the raspberry pi on the electronics tray), so if you’ve got something similar it may be better to use Roll90Pitch315 instead of just Pitch315.
QGroundControl sends mavlink commands to ArduSub telling it what to do, and ArduSub reports back sensor data (telemetry) and status updates. It’s not possible for ArduSub to not have access to the calibration data because otherwise it wouldn’t be able to use it when reporting sensor values or controlling the vehicle.
I did a quick search in the GitHub repo and found that ArduSub palms off calibration to the more general GCS Mavlink library (shared by all the ArduPilot vehicle firmwares), which handles calibration messages here (there’s even a message there for forcing a set of parameters, which could be a good starting point for you to look into, if you want to take this approach).
Note that that’s on the master branch, which I believe is what’s loaded when updating ArduSub with the ‘Development’ button from the companion web interface. The ‘Beta’ button currently uses the Sub-4.1 branch, and ‘Stable’ uses the Sub-4.0 branch. It seems like the ‘force accept’ parameter input is new, because Sub-4.1 doesn’t have it.