Possible plane 3.9 incompatibility with Disco

Hello, a few days ago, I tried installing Ardupilot to a Parrot Disco. This was one of a pair of identical Discos, bought years ago from the same place. I had originally installed Ardupilot (no idea which version, whatever was around at the time) following the instructions of this video. The take home message from the video was that I did not transfer the rcS_mode_default file but only the arduplane binary and start_ardupilot.sh. This had worked great the first time I tried and I could switch between the originan Parrot firmware and Arduplane by triple clicking the button, as opposed to immediately booting into Arduplane.

Now, I tried the same but, after triple clicking the button, the LED flashed red (indicating possible loading of Ardpuplane) but neither Mission Planner nor QGroundControl would connect to the vehicle. I got wireshark to listen to my wifi interface and, as far as I could tell, no incoming UDP packets were detected.

To dig a little deeper, I connected to the Disco over telnet and manually fed the terminal the commands of start_ardupilot.sh. Here are the outputs:

/data/ftp/internal_000 # cd /data/ftp/internal_000/ardupilot
/data/ftp/internal_000/ardupilot # /bin/date
Thu Jan 1 00:06:03 UTC 1970
/data/ftp/internal_000/ardupilot # /bin/ls
arduplane start_ardupilot.sh
/data/ftp/internal_000/ardupilot # /bin/dragon_ipc.sh dragon_shutdown
POMPCLI: event_cb : event=0(CONNECTED) conn=0x284918 msg=(nil)
POMPCLI: event_cb : event=1(DISCONNECTED) conn=0x284918 msg=(nil)
/data/ftp/internal_000/ardupilot # /usr/bin/killall -KILL dragon-prog
killall: dragon-prog: no process killed
/data/ftp/internal_000/ardupilot # /usr/bin/pstop ledd
/data/ftp/internal_000/ardupilot # echo 1 > /sys/devices/platform/user_gpio/FAN/
value
/data/ftp/internal_000/ardupilot #
/data/ftp/internal_000/ardupilot # echo 1 > /sys/devices/platform/user_gpio/RESE
T_GNSS/value
/data/ftp/internal_000/ardupilot # echo 0 > /sys/devices/platform/user_gpio/RESE
T_GNSS/value
/data/ftp/internal_000/ardupilot # echo “$(date) Starting arduplane”
Thu Jan 1 00:07:51 UTC 1970 Starting arduplane
/data/ftp/internal_000/ardupilot # ./arduplane -A udp:192.168.42.255:14550:bcast
-B /dev/ttyPA1 -C udp:192.168.43.255:14550:bcast --module-directory modules
./arduplane: /lib/libm.so.6: version GLIBC_2.27' not found (required by ./arduplane) /data/ftp/internal_000/ardupilot # ./arduplane: /lib/libm.so.6: version GLIBC_2
.27’ not found (required by ./arduplane)

It appears the arduplane binary is choking on libm.so.6
I checked for the filename and it exists but I have no idea how to examine its version:

/lib # ls /lib/libm*
/lib/libm-2.19-2014.08-1-git.so /lib/libmount.so.1
/lib/libm.so.6 /lib/libmount.so.1.1.0
/lib/libmount.so

Does Plane 3.9 need a more recent version than whatever is in the original CHUCK installation? If so, any idea how to install it?

Edit to add that the firmware version in the Disco is 1.7.1, which is up-to-date as of today (link to Parrot Disco support) so no joy by trying to update via that channel.

Lucas De Marchi & Tridge did some great improvements for Disco AFAIK, only testing/documentation/publishing remains.
There is support for SkyController & Video.

It may be that one of those changes broke the “old” way it worked. (some more files need to be changed now)

So… The problem is that you have a newer toolchain with libc with some symbols that we don’t have on the Disco board. The usual hack of linking statically don’t work for Disco because when you link statically you lose the ability to use dlopen(), which is how modules are implemented.

Some solutions/workarounds:

  1. use an older toolchain… I doubt we are really not compatible with older toolchains. You can probably use one for older versions of rpi. I’ll check that.

  2. don’t use modules, then you can link statically. Probably the easiest to try. Just pass --static while configuring

  3. side-load any binary you want to run and set LD_LIBRARY_PATH accordingly. Then what you do is to copy the relevant libraries to Disco, too. I use this more to load binaries on the skycontroller, but it’s applicable to Disco as well. I blogged about doing this and I think it’s the more future-proof solution:
    https://politreco.com/2019/09/side-load-on-embedded-linux-with-buildroot/

It needs to update docs IMO.
Same issue here :

Whoa, Lucas, you seem to believe I am way more competent than I actually am :slight_smile:

I have not touched anything on the Disco’s firmware and wouldn’t know what a toolchain was if I found one eating my dinner. I simply tried the old “copy a couple of files over telnet” approach that had worked in the past and it blew up, apparently because the Disco’s libs are old. Parrot is no help, the current firmware they offer is 1.7.1, which is the same it was when Discos were all the rage.

I am in no particular hurry (or any hurry at all, really, I was just curious to check the new Ardupilot on Disco) so will happily wait till the issue is resolved and docs updated.