Beaglebone blue , arduplane reading MPU-9250 problem

General Discussion
1

Sometime before I used beaglebone blue for arducopter and worked ok.
For arduplane I have following debug info:
Aug 24 08:32:23 beaglebone arduplane[1038]: MPU: temp reset IMU[0] 5431 -150
Aug 24 08:32:23 beaglebone arduplane[1038]: MPU: temp reset IMU[0] 8747 6932
Aug 24 08:32:23 beaglebone arduplane[1038]: MPU: temp reset IMU[0] 7600 -153

In the source code at ~/ardupilot/libraries/AP_InertialSensor/AP_InertialSensor_Invensense.cpp
there is a line that generate the above erroor:
debug(“temp reset IMU[%u] %d %d”, _accel_instance, _raw_temp, t2);
first impression was that the temperature is not correct read. Later in same file is function that check temperature:
bool AP_InertialSensor_Invensense::_check_raw_temp(int16_t t2)
I bypassed this verification and the arduplane worked except inertial measurements. My conclusion was that all readings from MPU9250 are wrong (acceleration gyroscope and magnetometer ) not only temperature.
Because arducopter work ok , perhaps some functions allocations are inappropriate.
Please tell me if this forum is appropriate or I must go to the ardupilot.org.

2

Hi @eugen

since arducopter 4.1 the imu reading has changed and the linux load average increased a lot.
Try to disable the parameter INS_FAST_SAMPLE

3

Hi,

Not worked.The GPS and an lidar VL53L0X are ok.

Readings constantly wrong and not depend on position or movement.

The load (w linux command ) is:

root@beaglebone:~# w
05:35:46 up 16 min, 1 user, load average: 2.11, 2.14, 1.50
similar with arducopter.

I will send an video.

Eugen

4

Sorry the video.

5

Why the board is upside down?
It’s possible to send the messages of the messsges tab?

6

The board are not moving and is in the normal position , but the readings are random. Also the compass is not reading correctly as you can see in the attached movie.

From message tab:
8/30/2023 8:18:30 AM : PreArm: Compass not healthy
8/30/2023 8:18:30 AM : PreArm: 3D Accel calibration needed
8/30/2023 8:17:59 AM : PreArm: Q_ASSIST_SPEED is not set
8/30/2023 8:17:59 AM : PreArm: Waiting for RC
8/30/2023 8:17:59 AM : PreArm: GPS 1: Bad fix
8/30/2023 8:17:59 AM : PreArm: Compass not healthy
8/30/2023 8:17:59 AM : PreArm: 3D Accel calibration needed
8/30/2023 8:17:28 AM : PreArm: Q_ASSIST_SPEED is not set
8/30/2023 8:17:28 AM : PreArm: Waiting for RC
8/30/2023 8:17:28 AM : PreArm: GPS 1: Bad fix
8/30/2023 8:17:28 AM : PreArm: Compass not healthy
8/30/2023 8:17:28 AM : PreArm: 3D Accel calibration needed
8/30/2023 8:17:24 AM : e9b05460fd2c33d136e7e9e163d41bf3
8/30/2023 8:17:24 AM : ArduPlane V4.5.0-dev (7d264f17)
8/30/2023 8:17:24 AM : e9b05460fd2c33d136e7e9e163d41bf3
8/30/2023 8:17:24 AM : ArduPlane V4.5.0-dev (7d264f17)
8/30/2023 8:17:23 AM : e9b05460fd2c33d136e7e9e163d41bf3
8/30/2023 8:17:23 AM : ArduPlane V4.5.0-dev (7d264f17)

7

I also mention that the IMU chips are correct identified in HW ID tab. Picture attached.

HWID
HWID864×493 68.1 KB

8

Hi,

fisrt, what is the board orientation ? the arrow is pointing to front ?
Can you send a picture of your vehicle ? This compass message can be related to magnetic interference.

9

And same board in same condition runig arducopter

For this reasons I suspect that in the flow of inertial data ( initialization , read , fusion and/or filtering ) is something wrong on the arduplane software. This in spite that routines are common.

10

In attach a movie runing arduplane

11

Hi ,

The board is oriented as in picture board.jpg (top view)

Eugen

board
board1536×2048 312 KB

12

Ok,

some infos first.

what is the load average you are having ?
Because I can see a latency between the beaglebone and the mission planner.
It’s possible to download a log - using the mission planner and attach here ?
Another question, your linux is running from the emmc or sd card ? In case of the sd card, what is the card are you using ?

13

Hi,

  1. Load average:

without load
08:50:11 up 45 min, 1 user, load average: 0.06, 0.05, 0.10

after 15 min of arducopter running:
09:05:28 up 1:01, 1 user, load average: 3.50, 2.66, 1.63

after aprox. 15 min of arduplane running:
09:29:17 up 1:24, 1 user, load average: 1.77, 2.02, 1.62

  1. Linux is running on the on-board emmc.

Clock is set to max. 1000 MHz , and few ram is used (no swap)

  1. I will attach a .log file converted from .bin.

Eugen

4 9-1-2023 10-10-58 AM.log (3.77 MB)

14

Have you had checked magnetic interfecente in the compass ?
these peak of 3.50 it’s not good.
Can you check ardupilot’s sched_loop_rate parameter ?

15

At the arducopter I have :SCHED_LOOP_RATE,400
At the arduplane I have : SCHED_LOOP_RATE,50
Can I assume that rate 400 is good ?

16

I checked the real SCHED_LOOP_RATE was 300 (not 50 as in initial parameter list) , but I checked with 50, 100 , 200 and 400. Same bad behavior. But I observed that in the log at ATT we have:
for copter
ATT, 308028192, 0, -5.6, 0, -5.13, 278.47, 278.26, 0, 0.18, 3
for plane
ATT, 30632264, 0, -0.02, -2, -22.9, 0, 350.82, 1, 0.8, 0
The meaning of this numbers is:
TimeUS, DesRoll, Roll, DesPitch, Pitch, DesYaw, Yaw , ErrRP, ErrYaw, AEKF: active EKF type (Des=Desired)
The last number represent the EKF type and is 3 for copter and 0 for plane. From the ardupilot site I found somewhere : “Current stable versions of ArduPilot use EKF3 as their primary attitude and position estimation”
I checked in the parameter AHRS_EKF_TYPE in the plane and is configured as 3 , but as you see on the logs is 0. In reality I not know with version of EKF is used but I also observe that the correction matrix are almost 0 so is possible that EKF is not use correctly.
An question : The IMU in the logs are raw data as read from sensors or corrected by EKF (fusion) ? The meaning and values are:
IMU, TimeUS, I, GyrX, GyrY, GyrZ, AccX, AccY, AccZ, EG, EG, T, GH, AH, GHz, AHz

arduplane:
IMU, 100715520, 0, 6.538393, 0.01491968, 15.56979, 1.10134, 0.5410922, 73.54984, 0, 0, 41.24303, 1, 1, 908, 908

arducopter:
IMU, 320342176, 0, -0.0009362625, 0.001176661, -0.0005683674, -0.265948, 0.5125741, -9.559977, 0, 0, 48.05517, 1, 1, 1000, 1000

As you can see on the plane there are permanent rotation on the GyrX= 6.538393 and GyrZ=15.56979 which is incorrect for a not moving board. Also the AccZ=73.54984 is unrealistic big , usually is gravitational acceleration and must be negative somewhere around -9,81.
The temperatures here look realistic approx 41.24 at copter and 48.05 at plane.

17

hi @eugen ,

the sched_loop, in my boards, when I increase, the load increase too.
One thing you can try - better than the logs, is compiling ardupilot with ./waf examples
This will generate in the folder build//examples you will find a INS_generic - this will test the ins using the ardupilot libs.
it’s strange because the libs are shared between all the vehicles.
In plane the dedault schedule value is 50 meanwhile in copter is 350 - there is another detail, there is a parameter - sched_debug - and run with 1 and after 2 - in one you will have if there is some task with delay - related to load cpu and to show the tasks that is demanding more time than the task limit.

18

I compiled the examples an I transferred INS_generic to the beaglebone blue board. I had “Segmentation fault” for all combinations (requested in by ./INS_generic --help) for example:

root@beaglebone:/home/debian# ./INS_generic --serial0 /dev/ttyS1 --serial1 /dev/ttyS2
SBUS FD -1 115200 FD -1
Segmentation fault
root@beaglebone:/home/debian#

19

I checked all examples and almost all finish with “Segmentation fault” , except RC_Channel , where work 5 of 6 channels.(But in Mission Planner work all)

20

The INS_generic doesn’t have parameters, just run ./INS_generic