Beaglebone blue , arduplane reading MPU-9250 problem

General Discussion
21

I tried also , same result:

./INS_generic
SBUS FD -1 115200 FD -1
AP_InertialSensor startup…
Segmentation fault

Eugen

22

That’s an unusual behavior - I never saw this before.

23

I took an superficial look at the arducopter and arduplane , seems that the IMU way of reading differ.

As for INS_generic , I made few “digs” and as I see , thins are lost somewhere in the ADD_BACKEND() macro ( AP_InertialSensor.cpp ).

My operating system info are:

uname -a
Linux beaglebone 4.19.232-bone-rt-r75 #1buster SMP PREEMPT RT Tue Mar 8 08:07:50 UTC 2022 armv7l GNU/Linux

less /etc/os-release :

PRETTY_NAME=“Debian GNU/Linux 10 (buster)”
NAME=“Debian GNU/Linux”
VERSION_ID=“10”
VERSION=“10 (buster)”
VERSION_CODENAME=buster
ID=debian
HOME_URL=“https://www.debian.org/”
SUPPORT_URL=“https://www.debian.org/support”
BUG_REPORT_URL=“https://bugs.debian.org/”

24

I remember one thing

Try to change the version doing a checkou to version 4.0
On the 4,1 the imu reading change to fifo and before that was a simple reading

25

Another thing,

I saw today a pull request related to imu reset errors:

26

I tried with the semaphores use priority-inheritance … not work , but behavior is different.
The oldest version with beaglebone blue is 4.1.6 , I checked and IMU work !
Work also 4.1.7 , but 4.2.0 , 4.2.1 and probably further not work.
There is a possibility to access source code of older versions ? Or a method to find differences in order to correct actual version ?

27

The major difference is the way the imu is read.
Prior 4.2 the way of reading imu has changed - as the speed of imu data is needed.
After 4.2 is related to fifo reading - what I could see is something about the amount of data read at once - and after several discussions, the ardupilot dev team is believe the problem of imu reset is bad sensors - what I don’t believe - and all my analysis the problem is in the spi bus and the night load average - but in bbblue the imu is using the i2c bus and 400 kHz speed while in thr spi bus is 10mhz

28

There are two problems , I not know if are related or not:

  1. examples INS_generic , and others as AHRS_Test , AP_Compass_test, BARO_generic , Scheduler_test , location …

with debug (gdb) all finished as :

SBUS FD -1 115200 FD -1
AP_InertialSensor startup…

Thread 4 “ap-rcin” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb66ff450 (LWP 1928)]
RC_Channels::option_is_enabled (this=0x0, option=RC_Channels::Option::USE_CRSF_LQ_AS_RSSI) at …/…/libraries/RC_Channel/RC_Channel.h:527
527 return _options & uint32_t(option);

I suppose that is a common bug somewhere. Also most of the example not need remote control.

  1. IMU measurements. The MPU 9250 has 1k samples/sec for gyro. and 4 k samples/sec for acc. , on 16 bits . In theory can work at I2C 400k , and beaglebone blue is a valuable board and maybe worth to be keept compatible with new versions of arduplane , (with arducopter is ) .
29

I took a look at the common problem of examples. I found that _singleton is called before to be initialized and I in
libraries/AP_RCProtocol/AP_RCProtocol_CRSF.cpp , I modified as follow
linia 311
#if AP_RC_CHANNEL_ENABLED
//e
if (RC_Channels::get_singleton() != nullptr) //e line added
//Check if LQ is to be reported in place of RSSI
_use_lq_for_rssi = rc().option_is_enabled(RC_Channels::Option::USE_CRSF_LQ_A
#endif
}

With this I was able to run INS_generic and values look good:
0 - Accel (h) : X: 0.36 Y: 0.54 Z: -9.52 norm: 9.55 Gyro (h) : X: -0.00 Y: -0.00 Z: 0.00 t: 48.06
0 - Accel (h) : X: 0.36 Y: 0.55 Z: -9.48 norm: 9.50 Gyro (h) : X: -0.00 Y: 0.00 Z: 0.00 t: 48.07
0 - Accel (h) : X: 0.36 Y: 0.56 Z: -9.50 norm: 9.52 Gyro (h) : X: -0.00 Y: 0.00 Z: 0.00 t: 48.06
As you can see also temp is realistic , t:48.06
With same modification run also AHRS_Test with the following output:
root@beaglebone:/home/debian# ./AHRS_Test
SBUS FD -1 115200 FD -1
MPU: temp reset IMU[0] 9191 0
Init Gyro**MPU: temp reset IMU[0] 9300 6932
MPU: temp reset IMU[0] 8113 2
MPU: temp reset IMU[0] 9300 1799
MPU: temp reset IMU[0] 8903 5848
MPU: temp reset IMU[0] 9293 6932
MPU: temp reset IMU[0] 5852 -2

Seems that is at least one bug.

30

This message - temp reset is throwed when the code try to read info from the imu and the fifo returned is invalid.
That is, like I said before, the change from 4.1 to 4.2

31

Refer to IMU , I took a look at the code , and totally agree with you. My filling is that this code can be done to work good. I observed in the code some comments about nondeterministic behaviors.

In the MPU-9250 datasheet , for pin 11 FSYNC si writing “Frame synchronization digital input. Connect to GND if unused”

In beaglebone blue the FSYNC is not used , but left unconnected. I assume that is a high impedance CMOS input that can receive noise. But this can be avoid by taking care to disable all events related to FSYNC input in the programming registers. But can be also other issues.

So there are one problem with examples (Segmentation falult) , for that I found an improvisation , but in my opinion must be solved by someone that know the logic behind, and a second problem with the IMU readings. (I will took a look but is more difficult to be solved by outsiders as me. ).

Is possible for this problems to be solved in future versions ?

1 Like
32

I’m using the mpu with spi instead i2c, and with more powerful boards - bbai for instance, I don’t have problems - really any and ardupilot is running fine, but with bbb i have the same problems as you with blue - and digging a lot I cannot find any explanation about the spi problems - and testing with an icm20948 I’m having the same problems, so I don’t think the problem is related to sensor but in my tests and opinion I was thinking a problem with spibus - but how are you having problems with i2c, this is showing the bus is not the real problem