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

[Ben Laurie]

On 20 February 2017 at 15:50, Gautier Hattenberger
<address@hidden> wrote:
> Hi,
>
> I also run into this problem today (after removing the dust from our
> ARDrones). So the arm-linux toolchain of ubuntu 16.04 is definitely too
> recent. Here is an other option (a bit less intrusive) to solve this:

I am curious what you fly now?

I confess: I would also have to remove the dust from my ARDrone and my
paparazzi knowledge, so feel free to ignore this idle query. :-)

>
> - go to the Parrot Developer Gihub account and get their toolchain:
> https://github.com/Parrot-Developers/toolchains/raw/master/parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb
> (as a side, this one works for their older products, there is an other one
> for recent ones like bebop2 or disco).
>
> - install it with 'sudo dpkg -i
> parrot-tools-linuxgnutools-2012.03_1.0.0-1_i386.deb', the code will end up
> in /opt/arm-2012.03
>
> - add proper compiler PREFIX as an airframe configure option <configure
> name="PREFIX" value="/opt/arm-2012.03/bin/arm-none-linux-gnueabi"/>
>
> It should be enough. You can check when compiling that the correct toolchain
> is used: 'arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2012.03-57)
> 4.6.3'.
>
> Gautier
>
>
> Le 11/08/2016 à 00:33, Riccardo Paolo Bestetti a écrit :
>
> Hi everyone.
>
> Good news: I got it to work on Ubuntu 16.04!
> Kinda bad-ish news: I took a shortcut.
>
> To make it work, I installed an older version of the cross-compiler from the
> Ubuntu Trusy repository, which contains an older version of the
> cross-compiler setup. The method should work on pretty much any apt-based
> distribution that presents my same problem.
> I'm writing it as a tutorial, so it can readily be used by people coming
> from e.g. Google.
>
> This is how I did it:
>
> 1 - Removed the installed g++-arm-linux-gnueabi and g++-arm-linux-gnueabi
> packages, autoremoved all the dependencies, updated & upgraded everything
> (this is useful for the last step):
>
> $ sudo apt-get remove g++-arm-linux-gnueabi g++-arm-linux-gnueabi
> $ sudo apt-get autoremove
> $ sudo apt-get update
> $ sudo apt-get upgrade
>
> 2 - Added main and universe repo components from Ubuntu Trusty to the end
> (very important unless you want to screw up your distro) of my sources.list
> & updated the package lists:
>
> $ sudo sh -c "echo 'deb http://archive.ubuntu.com/ubuntu trusty main
> universe' >> /etc/apt/sources.list"
> $ sudo apt-get update
>
> 3 - Reinstalled g++-arm-linux-gnueabi and g++-arm-linux-gnueabi, this time
> by pinning the trusty repo with the -t option:
>
> $ sudo apt-get install -t trusty g++-arm-linux-gnueabi g++-arm-linux-gnueabi
>
> 4 - Noted the packages that apt tries to upgrade to the last version from
> the list given by this command (I omitted sudo on purpose, the flag -s
> launches a simulation which doesn't need a lock):
>
> $ apt-get upgrade -s
>
> 5 - Marked the aforementioned packages to be held back, to avoid them being
> upgraded again to the last version by apt-get upgrade:
>
> $ sudo apt-mark hold binutils-arm-linux-gnueabi cpp-4.7-arm-linux-gnueabi
> cpp-arm-linux-gnueabi g++-4.7-arm-linux-gnueabi g++-arm-linux-gnueabi
> gcc-4.7-arm-linux-gnueabi gcc-4.7-arm-linux-gnueabi-base
> gcc-arm-linux-gnueabi libc6-armel-cross libc6-dev-armel-cross libcloog-ppl1
> libgcc-4.7-dev-armel-cross libgcc1-armel-cross libgomp1-armel-cross
> libppl-c4 libstdc++6-4.7-dev-armel-cross libstdc++6-armel-cross
> linux-libc-dev-armel-cross
>
> Note that the package list could be slightly different for other distros
> than mine, or even for the same one, so don't just blindly copy this last
> command! Always take the package list from the 4th step.
>
> 6 - Optional but suggested, you can now remove the trusty repo from your
> sources.list, as it's never good to have repos for different releases on the
> same system (execute the following command only once, as it deletes the last
> line of the file):
>
> $ sudo sed -i '$ d' /etc/apt/source.list
>
> These steps should install the cross-compiler from the trusty repos, which
> contains a version of the cross-compiled glibc that supports Linux >= 2.6.32
> (hence, the Ar.Drone 2 with software version v2.4.8).
>
> After doing this, I launched Paparazzi, selected the appropriate xml files
> for the Ar.Drone 2, cleaned, built the autopilot, uploaded it and it worked.
>
> Executing the file command on the ap.elf executable confirms that it
> supports Linux 2.6.32.
>
> Hope this will help someone in the future.
>
> Regards,
> --- Riccardo Paolo Bestetti
>
> Il 10/08/2016 02:02, Riccardo Paolo Bestetti ha scritto:
>
> 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
> 2.6.32.9-g980dab2
>
> 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
> http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
> 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.
>
> Regards,
> --- Riccardo Paolo Bestetti
>
> Notes:
>
> https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
>
>
> 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?
>>
>> Regards,
>> 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:
>>
>> https://github.com/paparazzi/paparazzi/blob/v5.8/conf/firmwares/subsystems/shared/telemetry_transparent_udp.makefile
>> You can override those defaults in your airframe file, e.g.:
>> <module name="telemetry" type="transparent_udp">
>>   <configure name="MODEM_DEV" value="UDP0"/>
>> </module>
>> The default MODEM_HOST (IP to which the packets are sent is defined in
>>
>> https://github.com/paparazzi/paparazzi/blob/v5.8/conf/boards/ardrone2.makefile#L36
>>
>> 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?
>>>
>>> Regards,
>>> --- Riccardo Paolo Bestetti
>>>
>>>
>>> Il 09/08/2016 17:15, Riccardo Paolo Bestetti ha scritto:
>>>
>>> Hello,
>>> 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.
>>>
>>> Regards,
>>> --- Riccardo Paolo Bestetti
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>> _______________________________________________ Paparazzi-devel mailing
>>> list address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________ Paparazzi-devel mailing
>> list address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________ Paparazzi-devel mailing
>> list address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>