Recently did a calibration of the robot and was looking to change the AHRS_ORIENTATION parameter. Our board is positioned in a YAW180 orientation and the altimeter and compass are now correctly showing values. In addition, our vehicle is moving around with joystick commands correctly.
However, when we set depth hold, the robot does a 180 degree roll and holds its depth upside down.
As a test, we changed the AHRS_ORIENTATION to roll90 when the board was kept in the same position (yaw180), and the robot held its depth with its nose directly pointing downwards.
It seems like changing the AHRS_ORIENTATION does not propagate to the different modes(depth mode stabilise etc.)
When we switch the AHRS_ORIENTATION back to “none”, the depth hold works as expected however the compass and altimeter readings are incorrect as the board is currently mounted in a yaw180 position.
Do we need to update our frame/thruster configuration when changing AHRS_ORIENTATION. I didn’t think we would as the joystick commands are behaving correctly.
Did you re-level the horizon after the new orientation was applied? I’m unsure whether you’ll also need to recalibrate the sensors, but it’s worth a try if you haven’t already.
I’m not sure how altimeter readings would come up “incorrectly” based on a software-defined vehicle orientation - the readings for vehicle altitude/depth should be independent of which way the vehicle is facing.
Or did you mean the attitude widget is showing correct pitch and roll orientation values?
Are you certain it’s actually in a Yaw180 orientation (lying flat, facing backwards) in the vehicle?
You shouldn’t need to, no - avoiding that is the main point of having an AHRS orientation abstraction
If the questions above aren’t helpful/fruitful we can try to replicate your situation and/or go digging in the source code for potential causes, but it would be rather surprising if this turns out to be a bug with ArduPilot’s AHRS_ORIENTATION implementation, given there are definitely other vehicles in the ArduPilot ecosystem that don’t all use Roll90 like the BlueROV2.
sorry for the confusion, I did mean the attitude widget showing the pitch and roll. It is correct when using the yaw180 setting.
“Did you re-level the horizon” I did not yet as it seemed quite level. But I could try that next and see how it behaves but I don’t see why this would be the cause of the problem.
What do you mean by “given there are definitely other vehicles in the ArduPilot ecosystem that don’t all use Roll90 like the BlueROV2.”
In particular what is mean by “don’t all use Roll90”?
When doing the accelerometer calibration should I orient/rotate/pitch the vehicle based on the direction in which the arrow is pointing or from the frame of reference of the board being in “yaw180”?
For example a left roll in the “none” orientation would be a right roll in the “yaw180” orientation.
Currently I did the accelerometer calibration based on the board being in an “yaw180” orientation.
The AHRS_ORIENTATION description mentions needing to level horizon after changing it, and the calibration tabs in QGroundControl that allow specifying the orientation also specify to make sure the rotation is set correctly prior to calibrating.
There are many ArduPilot vehicles, and not all of them use the Roll90 orientation for the flight controller, so I imagine if this is a general issue with the firmware (rather than a calibration problem or something) it would have been found a while ago when someone tried a different orientation.
That doesn’t mean it’s impossible for it to be a firmware issue, it’s just a potential option that I thought was worth mentioning, but also quite low likelihood (so not worth looking into as the first step).
Are you using our recommended software versions? Calibrating the accelerometer for me (in QGroundControl) shows an aeroplane model, not just an arrow:
Regardless, the calibration alignment should be for the vehicle, not the flight controller. You shouldn’t need to do your own manual/mental compensation for the flight controller’s orientation within the vehicle
That seems like a likely cause for your vehicle’s behaviour. Please try calibrating again, but use the dropdown to select your flight controller’s orientation within the vehicle, and from there align just the vehicle with the indications during the calibration process
That seems odd, and I’m not sure what would cause it. That said, it doesn’t seem to necessarily be an issue, since the pressure should generally be calibrated at the start of each dive anyway, to account for the local air pressure.
