mag fixes #7434
mag fixes #7434
Conversation
A recent change removed the command forwarding required for VTOL transitions. This change brings this back. Partially reverts #7249
Problem: _mag_device_id is used to get the correct rotation matrix for each mag. But on POSIX, _mag_device_id was always 0, leading to invalid rotation matrices. This resulted in stale mag error messages (rot matrix=0 ==> mag data=0). _mag_device_id was 0 because there are no /dev/magX devices (eg. on RPi), thus the mag driver could not be opened. This patch does: get the device id from the uorb topic instead. We still need the device handle on certain platforms to apply the calibration params and to check if the mag is internal or external. Problem left: on POSIX, the check for external mag does not work.
With this we don't have to use the ioctl MAGIOCGEXTERNAL, which does not work on POSIX (eg. RPi).
Because it's a baro driver, not a mag.
fixes a wrong index for _mag_device_id: previously, driver_index was used (the CAL_MAG param index), but the correct index is the uorb topic instance.
the 'continue' continues with the inner loop, whereas the outer loop is responsible for opening the handle. Thus the inner loop needs to keep it open.
|
These are mag fixes that should go into stable. |
|
@PX4TestFlights, please make sure you test at-least these configurations :
You must recalibrate and reboot before and between these tests. |
|
Something's not right even with these fixes. Tested on a Pixhawk 2 with 4 mags (3 internal, 1 external), and the internal/external detection seems janky. One of the internal ones is detected as external. @bkueng Do you have access to Pixhawk 2.1 hardware? |
No. I guess it's wrong in the driver then. |
|
It used to work fine before (when I tested my last PR), so I will have to check again. |
|
@mhkabir Should we hold on testing? |
|
@d3z0rian Don't let this gate testing. Please go ahead and test. |
|
flight with pixhawk mini (v3), flight controller rotated 180 degrees and external compass 90 degrees; good flight no issues. flight with pixracer (v4) no external compass; issues maintaining orientation; heavy drift when using position mode and AUTO/RTL" |
|
Check out the mag params from the bad flight : The third mag (MAG2) doesn't seem to be correct. It has offsets and scaling, however no device ID. Not sure that this is the smoking gun, but it still shouldn't happen. Calibration should reset all those params. |
|
already recalibrate and these are the parameters; |
|
Here is our Param Dump. 1 1 CAL_MAG0_ID 73225 6 The Mag3 was not visible in the parameters in QGC. I see here it stayed empty. We made a mag calibration before the test. The hardware is AUAV X2.1. It has a 3 internal compasses in a chip. So there should be numbers after the calibration in the mag3 parameters. We checked if the magnetometer mag0 is the main one and is working. We separated the gps from the stand and rotated only the gps+mag. As expected the arrow in the compas slowily started diverging. So everithing was ok as expected. Strangely we could not change CAL_MAG0_ROT to 4. it stayed at -1. |
|
@Tubme A few things :
|
|
@mhkabir Thanks for the reply.
|
This is a completely misguided line of thought. The MPU9250's AK8963 enumerates as 1 magnetometer. From a quick glance at your params, I see that MAG2 is the AK8963. So the question is - what is MAG0 and MAG1. Can you please share Also @pkocmoud, would you be able to confirm what mag chips you have onboard the X2.1? The product page (which looks incomplete) suggests that the MPU9250's mag is the only one onboard the autopilot board. |
|
Here is a dump from the same GPS but with X2: CAL_MAG0_ID 0 73225 So the 73225 is the ID of the external mag. |
|
The X2.1 does not have second magnetometer. It uses only the one from MPU9250. It is confirmed by Mr.Arsov. Will confirm the sensor status later. |
|
Another pointer that might help: Before the bootloader changes the X2.1 was recognized as ID:9. We were able to flash the regular FMUv2 firmware and then the external mag had a 90 degrees offset. We were able to correct this with CAL_MAG0_ROT = 2 (yaw 90) and we flew without a problem. After the bootloader changed and the X2.1 is recognized as ID:33 we flash the new auav-x21_default.px4 and we have 180 degrees offset without the option to change the CAL_MAG0_ROT. Is there some initialization dependent on the board ID? that is done once when you flash a new firmware... |
|
Status without the external magnetometer: Status WITH external magnetometer: |
|
Thanks! I will have a look tomorrow. |
|
#0 and #1 both seem to be from the external mag driver, and the values in the validator are exactly the same. |
|
@tubeme I suspect that the driver config for the X2 was just never finished as it looks very different from Pixhawk but supposedly is more or less the same board. @pkocmoud Could you comment on this? I don't have a board so I can't really test it, but maybe @davids5 and @pkocmoud can look at this together. |
|
@LorenzMeier @mhkabir I think it is something to do with the initialization during flash. Lorenz you mention X2, while I'm talking about X2.1. Before the bootloader changed I explained that the board was accepted as FMUv2, we flashed regular FMUv2 FW and with the same magnetometer and GPS we flew missions etc. The only thing we had done is give the CAL_MAG0_ROT = 2 (yaw 90). After the calibration the QGC asks for this offset. When the bootloader changed and we flash the AUAV X2.1 FW version after the calibration QGC did not ask us for the CAL_MAG0_ROT offset. The hardware is performing perfectly well with the FMUv2 version. Now it is impossible to flash FMUv2. QGC does not allow this. |
|
After the boot loader change you are now flashing effectively different software and I can tell from the code that its behaving differently than FMUv2 - which makes no sense, because you said it worked with the FMUv2 software just fine. @pkocmoud Can you chime in here? |
|
@LorenzMeier I don't understand what you mean by differently but here are the specs of the two boards: X2 STM32F427VI ARM microcontroller ST Micro L3GD20 X2.1 Processors: Next Generation Sensors: Invensense MPU9250 9DOF By this specs it is obvious that the CPUs are the same (another revision does not mean new CPU). This in its term means that OSwise (nuttx) the boards are identical. They have a different sensors which in its term means they have a different drivers they load during start up and that is the only difference I see. It is a FACT that we managed to fly the board perfectly well with the FMU v2 version of the firmware with the only condition that we changed the direction of the external mag to 90deg. And it is logical because the MPU9250 drivers are in the main tree so they are loaded with the FMU v2 firmware as well. And if they are loaded then the board is working. I don't understand what is the difference really. We can fly the board now as well with the condition that we physically rotate the GPS 180deg. But it is not good at all, because the external mag is registering two times as mag #0 and #1. I'm not sure what is going to happen if the external mag fails? Is it going to switch to mag #2 or is it going to stay headless? It is for sure the board is not functioning correctly under the new bootloader with the AUAV-X2.1 version of the firmware, but it is most likely very simple thing that has to be changed in the initialization of probably the MPU9250 driver. Registering the external mag as internal in the nuttx gives me the lead towards the MPU9250 driver. The HMC5883L is a very old device with a very old driver so I doubt there is the problem with it. We will make a test with another external compass + GPS to make sure we tried this combination as well. |
|
The bootloader change list the board id as that requiring FW for the auav-x21 build. That is The |
|
@davids5 Exactly my point. And a little correction. The external sensor is registering as internal and not only this but it is registered 2 times as mag #0 and #1. So it might be the script. Here is the AUAV script: if ver hwcmp AUAV_X21
First there is no MPU6000 on this board. It is MPU9250 so the two ifs with the MPU6000 are not necessary. Also there is no other magnetometer to the X2.1 except the one in the MPU9250 that is confirmed as I mentioned above. Second for the HMC5883 I see a substantial difference with the FMUv2 version: FMUv2 version: AUAVX2.1 version: You see for the FMUv2 version you presume there is External and Internal option for the hmc5883 I presume that if you change in the AUAVX2.1 the line to it will run perfectly well like in the FMUv2 scenario we had. |
|
Something else to add. The PixRacer is accepted as FMUv4. From my knowledge it is 99% the same as X2.1 with the only difference of a mag sensor it has more than X2.1 Here is the FMUv4 script: if ver hwcmp PX4FMU_V4 fi and I see the exact same line I'm taliking about: Also I don't understand what is External and Internal I2C, when there is I2C1 and I2C2 buses on the board. From my knowledge there shouldn't be any difference between connecting devices to the C1 or C2 buses. They are interchangeable. |
|
Superseded by fixes on master, which will come in to stable now. |
|
|
@Avysuarez Did you recalibrate before doing the second test? I don't see how that can happen unless you don't recalibrate after disconnecting the externl mag. |
|
|
@Avysuarez Thanks! |
No description provided.