[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] Ar.Drone 2 session stuck at "Waiting for telemetry

From: Riccardo Paolo Bestetti
Subject: Re: [Paparazzi-devel] Ar.Drone 2 session stuck at "Waiting for telemetry"
Date: Wed, 10 Aug 2016 02:02:25 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hello Felix.

Compiler version: arm-linux-gnueabi-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.1) 5.4.0 20160609.
Paparazzi version: v5.8.2_stable-0-g6260b7c-dirty.

I think I now have a good grasp on the issue.

As far as I understand, the "kernel too old" error happens when statically linking code to a glibc that was configured not to contain compatibility code.

This can indeed be confirmed with the file command:

address@hidden:~/paparazzi$ file var/aircrafts/ardrone2/ap/ap.elf
ap.ef: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, [...]

On the Ar.Drone 2, software version v2.4.8:

# uname -r

Which is a much older kernel version than 3.2.0.

From what I gather from the glibc documentation [1], the solution would be linking against a glibc version configured and cross-compiled with the following option:

./configure --enable-kernel=2.6.32

Running the following commands (assuming a bare x86_64 Ubuntu 16.04 system with all Paparazzi's dependencies installed) gets me a libc.a that, if I'm not missing something, should be what I need to link against to get a working ap.elf on my Ar.Drone 2 running Linux 2.6.32:

address@hidden:~/glibc_build$ wget
address@hidden:~/glibc_build$ tar -xJf glibc-2.24.tar.xz
address@hidden:~/glibc_build$ mkdir build && cd build
address@hidden:~/glibc_build/build$ sudo apt-get install gawk
address@hidden:~/glibc_build/build$ ../glibc-2.24/configure arm-linux-gnueabi --host=arm-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix= --enable-kernel=2.6.32
address@hidden:~/glibc_build/build$ make

Now I have:

address@hidden:~/glibc_build/build$ ls -la | grep libc.a$
-rw-rw-r--  1 paparazzi paparazzi 16964358 ago 10 01:39 libc.a

How do I feed it to the cross-compiler in the Paparazzi build process? And if that really works, how can this be integrated in the Paparazzi build system?

Note: sorry if the email feels disorganized, when I first started writing it I had a much less specific understanding of the problem.

--- Riccardo Paolo Bestetti


Il 09/08/2016 23:56, Felix Ruess ha scritto:
Hi Riccardo,

the cross compiler from the team-gcc-arm-embedded ppa is only for cross compiling to embedded (bare metal) targets.
The ARDrone runs Linux so arm-linux-gnueabi-gcc from the gcc-arm-linux-gnueabi package is used.

When you compile the ap target for it, it should print the exact version at the beginning...

I think most people using the ARDrone2 are still using Ubuntu 14.04, so I'm not sure if the cross compiler with 16.04 has been tested so far (although I can't think of a reason why it wouldn't work with the new compiler).
Maybe someone who actually has/uses an ARDrone2 (e.g. from TU Delft) can chip in here?

Also what Paparazzi version (output of ./paparazzi_version) are you using?

Cheers, Felix

On Tue, Aug 9, 2016 at 10:24 PM, Riccardo Paolo Bestetti <address@hidden> wrote:
Hello Felix,
Thank you for your help.

I'm using Ubuntu 16.04, "gnome desktop" variant.

The install tutorial instructed to install the compiler from "team-gcc-arm-embedded", which is as far as I understand distro-independent. Doesn't this mean that the Ar.Drone board build should be broken for everyone using the last compiler from that PPA? Or could the problem depend on something else than the cross-compiler?

Riccardo Paolo Bestetti

On 09 ago 2016, at 9:32 PM, Felix Ruess <address@hidden> wrote:

Hi Riccardo,

can you please post some more details on your OS (distribution, version), the cross compiler and paparazzi version you are using?

Regarding the USE_UDPx flags: most of them are set "automatically" depending on which UDP ports you use for telemetry:
You can override those defaults in your airframe file, e.g.:
<module name="telemetry" type="transparent_udp">
  <configure name="MODEM_DEV" value="UDP0"/>
The default MODEM_HOST (IP to which the packets are sent is defined in

Cheers, Felix

On Tue, Aug 9, 2016 at 9:09 PM, Riccardo Paolo Bestetti <address@hidden> wrote:

I have new details: I tried manually running the ap.elf executable in a Telnet shell and it immediately quits with the following error message:

FATAL: kernel too old
Segmentation fault

It makes me think of an issue with the cross-compiler.

Any idea on how to solve this?

--- Riccardo Paolo Bestetti

Il 09/08/2016 17:15, Riccardo Paolo Bestetti ha scritto:
I'm trying to start an Ar.Drone 2 session from the default files.
The only changes I made so far are changing the GPS type to sirf and removing the ublox module from the airframe file.

Build & upload are successful, but when I start the session the software gets stuck at "waiting for telemetry" as if the drone doesn't send any data back.

I really have no idea where to start debugging the problem. Does the ap program on the Drone output error messages somewhere?

Also, I'm trying to understand the build system, and there is something I don't get: where do the various makefiles take the "default" configuration values from? And how can I manually vary them for a particular airframe?
For example, when the ap program for the Ar.Drone is built, the flags "USE_UDP0", "UDP0_HOST", "UDP0_PORT_IN", etc. are correctly set (looking at the compiler flags from the ap_srcs.list file), but I don't see them defined anywhere in the configuration files.

--- Riccardo Paolo Bestetti

Paparazzi-devel mailing list
_______________________________________________ Paparazzi-devel mailing list address@hidden
_______________________________________________ Paparazzi-devel mailing list address@hidden
_______________________________________________ Paparazzi-devel mailing list address@hidden
Paparazzi-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]