Servers by jDrones

Bad Parameter Table when running EKF Replay tool

ekf

(Peter Huson) #1

When running the Replay tool I see the following:

./Replay – 2battfs.BIN
Starting
Processing log 2battfs.BIN
Using clock source IMU
Changing clock source to IMT
average_delta=2740.00 smallest_delta=1307 samplecount=1000
Replay counts: 144798 bytes 3417 entries
Replay rates: 5269789 bytes/second 124358 messages/second
check_group_info:206: suffix is too long in _TUBE_ORDER
Bad parameter table
Using an update rate of 400 Hz
Replay counts: 0 bytes 0 entries
Replay rates: 0 bytes/second 0 messages/second

Anyone know why it would be complaining about the _TUBE_ORDER parameter? Isn’t that a default parameter?


(peterbarker) #2

Is this on master?

I do recall this coming up previously…


(Peter Huson) #3

I installed replay as described here: http://ardupilot.org/dev/docs/testing-with-replay.html


(Peter Huson) #4

@peterbarker Would you be able to link where you have seen this before? It might help me figure this out.


(peterbarker) #5

Those instructions don’t cover getting the ardupilot repository.

What’s the output of “git log -n1”?

If you can provide a log I may be able to assist.


(peterbarker) #6

I believe the problem is there’s a parameter name which is too long -
ARSP2_TUBE_ORDER IIRC.

Issue doesn’t seem to have come up in my email. Might have been on
gitter…


(Peter Huson) #7

It looks like it was last updated in April. I will try updating it and running the EKF replay again.

*(master)mitch:ardupilot$ git log -n1
commit c76ff32aa16cb7b7ba0ca38493c1a333f751d77f
Author: Jacob Walser <jwalser90@gmail.com>
Date:   Thu Apr 19 14:53:27 2018 -0400

   Sub: Do not report altitude in GLOBAL_POSITION_INT if there is no depth
   sensor connected
   
   Fix bluerobotics/ardusub#145

(Peter Huson) #8

I just pulled the ardupilot repository and recompiled Replay:

~/ardupilot/build/linux/tools$ git log -n1
commit 2ba6f642813db043887a7eb1e06b82151609ec73
Author: Patrick José Pereira <patrickelectric@gmail.com>
Date:   Mon Jul 16 11:36:09 2018 -0300

Now it looks like it’s running until it says:

Barometer initialised
Segmentation fault (core dumped)

I’ve included the Replay.stg.txt (16 KB) file and did some snooping on where it was dying with valgrind:

...
Barometer initialised
==30502== Invalid read of size 1
==30502==    at 0x453790: AP_BattMonitor::has_current(unsigned char) const (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x453C51: AP_Compass_Backend::correct_field(Vector3<float>&, unsigned char) (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x454CB2: AP_Compass_HIL::read() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x419DA8: Compass::read() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40C8D7: Replay::read_sensors(char const*) (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40CE83: Replay::loop() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x44B614: HAL_Linux::run(int, char* const*, AP_HAL::HAL::Callbacks*) const (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40340D: main (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==  Address 0x114 is not stack'd, malloc'd or (recently) free'd
==30502== 
==30502== 
==30502== Process terminating with default action of signal 11 (SIGSEGV)
==30502==  Access not within mapped region at address 0x114
==30502==    at 0x453790: AP_BattMonitor::has_current(unsigned char) const (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x453C51: AP_Compass_Backend::correct_field(Vector3<float>&, unsigned char) (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x454CB2: AP_Compass_HIL::read() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x419DA8: Compass::read() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40C8D7: Replay::read_sensors(char const*) (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40CE83: Replay::loop() (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x44B614: HAL_Linux::run(int, char* const*, AP_HAL::HAL::Callbacks*) const (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==    by 0x40340D: main (in /home/ubuntu/ardupilot/build/linux/tools/Replay)
==30502==  If you believe this happened as a result of a stack
==30502==  overflow in your program's main thread (unlikely but
==30502==  possible), you can try to increase the size of the
==30502==  main thread stack using the --main-stacksize= flag.
==30502==  The main thread stack size used in this run was 8388608.
==30502==

(peterbarker) #9

Can you supply the log file, please?


(Peter Huson) #10

Here is the file: https://drive.google.com/file/d/1_7Ou68ec1pwklpHQCYYNozqT50af1--2/view?usp=sharing


(Peter Huson) #11

Any thoughts on what it could be?


(Arjun Vinod) #12

Is the problem resolved?