Servers by jDrones

Arduplane sitl output stops at validate_structures:401 when I connect with Mavproxy

(Robin Hilliard) #1

Hi all,

I’m trying to get SITL working with XPlane. I start arduplane like this:

build/sitl/bin/arduplane --model XPlane
Creating model XPlane at speed 1.0 
Home: -35.363261 149.165230 alt=584.000000m hdg=353.000000
Waiting for XPlane data on UDP port 49001 and sending to port 49000
Starting sketch 'ArduPlane'
Starting SITL input
Using Irlock at port : 9005
bind port 5760 for 0
Serial port 0 on TCP port 5760
Waiting for connection ....

XPlane (10) says it is successfully sending to 49001. I then start mavproxy like this:

mavproxy.py --master=tcp:127.0.0.1:5760
Connect tcp:127.0.0.1:5760 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from tcp:127.0.0.1:5760
MAV> link 1 down

Which connects because arduplane then continues in response:

Connection on serial port 0
bind port 5762 for 2
Serial port 2 on TCP port 5762
bind port 5763 for 3
Serial port 3 on TCP port 5763
validate_structures:401: Validating structures

Arduplane never gets past this, and mavproxy never gets a link. I don’t know if the problem is in AP_Logger or later than that. Does anyone have any idea what I’m doing incorrectly? All based on a fresh build of ardupilot master on OSX 10.14.5 following “Using SITL with your own GCS” instructions at http://ardupilot.org/dev/docs/sitl-with-xplane.html

Thanks in advance,
Robin

(Robin Hilliard) #2

For completeness here is the data tab in XPlane 10:

(peterbarker) #3

build/sitl/bin/arduplane --model XPlane

Which version of ArduPlane?

Are you running custom patches?

Do those custom patches include custom onboard logging?

I recently merged some fixes into master which will give you the output of
the logging validation which is failing. Try updating/rebasing?

Robin

Peter

(Robin Hilliard) #4

Hi Peter,

Thanks for the response. On master ArduPlane/version.h defines THISFIRMWARE as ArduPlane V3.10.0-dev. I didn’t realise I was on the bleeding edge, I should probably go back to a stable tag and try again with that, or if you have a suggestion for a version I’ll try that out and report what I get.

Cheers,
Robin

(Robin Hilliard) #5

Hi Peter,

Also to answer your question, no custom patches, just a fresh master from ardupilot - therefore it should contain your fixes. Where would I find the output of the logging validation (sorry it has been a long time since I worked with ardupilot and I remember very little).

Just so you know, so far I have only been able to build master which contains the firmware version above. Any Arduplane-3.9.x tag I’ve tried checking out, doing all sorts of cleaning out before the build up to and including:

./waf distclean
git submodule deinit -f . 
git clean -f -x -d 
git pull 
git submodule update --init --recursive 

per @ddomit in https://github.com/ArduPilot/ardupilot/issues/10541 followed by

modules/waf/waf-light configure --board sitl
modules/waf/waf-light plane

results in the compile error:

Waf: Leaving directory `/workspaces/ardupilot/build/sitl'
Build failed
-> task in 'objs/AP_HAL_SITL' failed (exit status 1):
{task 4574325488: cxx system.cpp -> system.cpp.0.o}
`/usr/bin/clang++ -std=gnu++11 -fdata-sections -ffunction-sections -fno-exceptions -fsigned-char -Wall -Wextra -Wformat -Wshadow -Wpointer-arith -Wcast-align -Wundef -Wno-unused-parameter -Wno-missing-field-initializers -Wno-reorder -Wno-redundant-decls -Wno-unknown-pragmas -Werror=format-security -Werror=array-bounds -Werror=uninitialized -Werror=init-self -Werror=switch -Werror=sign-compare -Wfatal-errors -Wno-trigraphs -fcolor-diagnostics -Wno-gnu-designator -Wno-inconsistent-missing-override -Wno-mismatched-tags -Wno-gnu-variable-sized-type-not-at-end -Wno-c++11-narrowing -O3 -fno-slp-vectorize -MMD -include ap_config.h -Ilibraries -Ilibraries/GCS_MAVLink -I. -I../../libraries -I../../libraries/AP_Common/missing -DSKETCHBOOK="/workspaces/ardupilot" -DCONFIG_HAL_BOARD=HAL_BOARD_SITL -DCONFIG_HAL_BOARD_SUBTYPE=HAL_BOARD_SUBTYPE_NONE ../../libraries/AP_HAL_SIT`L/system.cpp -c -olibraries/AP_HAL_SITL/system.cpp.0.o`

That’s a separate issue, just wanted to explain how I wound up trying to run the dev version on master.

(Robin Hilliard) #6

Running the failed clang++ command from the sitl directory gives a reason for the failure:

SITL/system.cpp -c -olibraries/AP_HAL_SITL/system.cpp.0.o
In file included from ../../libraries/AP_HAL_SITL/system.cpp:7:
../../libraries/AP_HAL_SITL/Scheduler.h:81:5: fatal error: unknown type name 'pthread_t'
    pthread_t _main_ctx;
    ^

I probably have some dependency that I missed, trying to find what it is.

(Robin Hilliard) #7

Hi Peter,

I found your commit https://github.com/ArduPilot/ardupilot/pull/8950/commits/370529d102dee0c287ed46ce2bc814ae73097545# from July last year to fix Mac SITL builds, checked out ArduPlane-stable, added the second #include <pthread.h> to Scheduler.h (it wasn’t there in stable/3.9.8) and it compiled. Now that I’m using a stable build my original problem has gone. Thankyou for having the precience to fix my problem a year ago :-).

Robin

(peterbarker) #8

I found your commithttps://github.com/ArduPilot/ardupilot/pull/8950/commits/370529d102dee0c287
ed46ce2bc814ae73097545# from July last year to fix Mac SITL builds, checked
out ArduPlane-stable, added the second #include <pthread.h> to Scheduler.h
(it wasn¢t there in stable/3.9.8) and it compiled. Now that I¢m using a
stable build my original problem has gone. Thankyou for having the precience
to fix my problem a year ago :-).

Fantastic!

Could you create a Pull Request against Plane stable, perhaps?

Robin

Peter