Using a serial data-link for Ar.Drone 2

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Using a serial data-link for Ar.Drone 2

Riccardo Paolo Bestetti
Hello.

First of all, I apologize if this was already addressed either here or on the Wiki, but I could find the information. So, if it has, please point me to it.

I'm trying to set up a communication link between the computer and the Ar.Drone2 to replace the Wi-Fi link. It consists of a wireless radio that simply bi-directionally relays serial data.
On the computer, if I understand correctly, all I have to do is use a USB-serial session (and change the defaults according to my specific hardware configuration) and I should be set for both the telemetry and the datalink.

Now, I see in the airframe configuration files the "telemetry" and "radio_control" subsystems.

For the telemetry, I should be able to set the type to "transparent" and then set the baudrate appropriately (by the way, is the UART port configured for the Ar.Drone2 board? And if it isn't, how can I do that?).
For the radio_control, I shall leave the "datalink" type. What I don't get, is how to tell the subsystem what link to listen to.

I hope you can help me, I'm really lost in the complexity of this mighty piece of software. :)

Regards,
--- Riccardo Paolo Bestetti


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Using a serial data-link for Ar.Drone 2

Roland Meertens

Dear Riccardo,

For the uart port, assuming you use a USB device that registers as ttyUSB0, the paparazzi define is UART1.

Kind regards,
Roland Meertens


On Sun, Aug 7, 2016, 20:07 Riccardo Paolo Bestetti <[hidden email]> wrote:
Hello.

First of all, I apologize if this was already addressed either here or on the Wiki, but I could find the information. So, if it has, please point me to it.

I'm trying to set up a communication link between the computer and the Ar.Drone2 to replace the Wi-Fi link. It consists of a wireless radio that simply bi-directionally relays serial data.
On the computer, if I understand correctly, all I have to do is use a USB-serial session (and change the defaults according to my specific hardware configuration) and I should be set for both the telemetry and the datalink.

Now, I see in the airframe configuration files the "telemetry" and "radio_control" subsystems.

For the telemetry, I should be able to set the type to "transparent" and then set the baudrate appropriately (by the way, is the UART port configured for the Ar.Drone2 board? And if it isn't, how can I do that?).
For the radio_control, I shall leave the "datalink" type. What I don't get, is how to tell the subsystem what link to listen to.

I hope you can help me, I'm really lost in the complexity of this mighty piece of software. :)

Regards,
--- Riccardo Paolo Bestetti

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Using a serial data-link for Ar.Drone 2

Riccardo Paolo Bestetti
Dear Roland,
Thank you very much for your answer.

I want to use the on-board serial port. It registers as /dev/ttyO3.
I ended up reading the source code and I found the place where the UARTs are defined for the Ar.Drone 2. Apparently, the on-board UART is not defined there.
I'm going to add it and if everything works I'll submit a pull request, and possibly update the Wiki page for the board. A good chance to give back to the project. :)

Can you also confirm that the communication method defined for the telemetry subsystem is also used for the datalink subsystem?

Regards,
Riccardo Paolo Bestetti

On 08 ago 2016, at 8:42 AM, Roland Meertens <[hidden email]> wrote:

Dear Riccardo,

For the uart port, assuming you use a USB device that registers as ttyUSB0, the paparazzi define is UART1.

Kind regards,
Roland Meertens


On Sun, Aug 7, 2016, 20:07 Riccardo Paolo Bestetti <[hidden email]> wrote:
Hello.

First of all, I apologize if this was already addressed either here or on the Wiki, but I could find the information. So, if it has, please point me to it.

I'm trying to set up a communication link between the computer and the Ar.Drone2 to replace the Wi-Fi link. It consists of a wireless radio that simply bi-directionally relays serial data.
On the computer, if I understand correctly, all I have to do is use a USB-serial session (and change the defaults according to my specific hardware configuration) and I should be set for both the telemetry and the datalink.

Now, I see in the airframe configuration files the "telemetry" and "radio_control" subsystems.

For the telemetry, I should be able to set the type to "transparent" and then set the baudrate appropriately (by the way, is the UART port configured for the Ar.Drone2 board? And if it isn't, how can I do that?).
For the radio_control, I shall leave the "datalink" type. What I don't get, is how to tell the subsystem what link to listen to.

I hope you can help me, I'm really lost in the complexity of this mighty piece of software. :)

Regards,
--- Riccardo Paolo Bestetti

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Ar.Drone 2 session stuck at "Waiting for telemetry"

Riccardo Paolo Bestetti
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Riccardo Paolo Bestetti

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

flixr
Administrator
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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Riccardo Paolo Bestetti
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

flixr
Administrator
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Riccardo Paolo Bestetti

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:

[hidden email] 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:

[hidden email] wget http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
[hidden email] tar -xJf glibc-2.24.tar.xz
[hidden email] mkdir build && cd build
[hidden email] sudo apt-get install gawk
[hidden email] ../glibc-2.24/configure arm-linux-gnueabi --host=arm-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix= --enable-kernel=2.6.32
[hidden email] make

Now I have:

[hidden email] 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:
  1. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback from coordinators ~ email or phone.

Dave Stevens
In reply to this post by flixr
On Tue, 9 Aug 2016 17:10:44 -0700
Elizabeth Larsen <[hidden email]> wrote:

> > The instrument lockup needs a lockable hatch from just inside the
> > door through the rear door of the Hall to the back of the Hall
> > stage for equipment transfer. At th


no make that "the rear wall of the Hall..."

d


--
Reporter to Mahatma Ghandi after his tour of east London
"What do you think of western civilization, Mr. Ghandi?"
Ghandi - "I think it would be an excellent idea!"


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback from coordinators ~ email or phone.

Dave Stevens
On Tue, 9 Aug 2016 17:41:37 -0700
Dave Stevens <[hidden email]> wrote:

> On Tue, 9 Aug 2016 17:10:44 -0700
> Elizabeth Larsen <[hidden email]> wrote:
>
> > > The instrument lockup needs a lockable hatch from just inside the
> > > door through the rear door of the Hall to the back of the Hall
> > > stage for equipment transfer. At th  
>
>
> no make that "the rear wall of the Hall..."
>
> d
>
>

don't know how that happened. Ignore please.

d


--
Reporter to Mahatma Ghandi after his tour of east London
"What do you think of western civilization, Mr. Ghandi?"
Ghandi - "I think it would be an excellent idea!"


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Riccardo Paolo Bestetti
In reply to this post by Riccardo Paolo Bestetti

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:

[hidden email] 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:

[hidden email] wget http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
[hidden email] tar -xJf glibc-2.24.tar.xz
[hidden email] mkdir build && cd build
[hidden email] sudo apt-get install gawk
[hidden email] ../glibc-2.24/configure arm-linux-gnueabi --host=arm-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix= --enable-kernel=2.6.32
[hidden email] make

Now I have:

[hidden email] 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:
  1. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

wv-tud
This post has NOT been accepted by the mailing list yet.
Dear Ricardo,

We are running into the same problem with Ubuntu 16.04. However what is the difference between the:

"g++-arm-linux-gnueabi and g++-arm-linux-gnueabi packages" you mention in your solution?

Thanks in advance!

Wilco
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Gautier Hattenberger-3
In reply to this post by Riccardo Paolo Bestetti

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:

- 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:

[hidden email] 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:

[hidden email] wget http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
[hidden email] tar -xJf glibc-2.24.tar.xz
[hidden email] mkdir build && cd build
[hidden email] sudo apt-get install gawk
[hidden email] ../glibc-2.24/configure arm-linux-gnueabi --host=arm-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix= --enable-kernel=2.6.32
[hidden email] make

Now I have:

[hidden email] 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:
  1. 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Ben Laurie
On 20 February 2017 at 15:50, Gautier Hattenberger
<[hidden email]> 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:
>
> user@ubuntu16.04:~/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:
>
> user@ubuntu16.04:~/glibc_build$ wget
> http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
> user@ubuntu16.04:~/glibc_build$ tar -xJf glibc-2.24.tar.xz
> user@ubuntu16.04:~/glibc_build$ mkdir build && cd build
> user@ubuntu16.04:~/glibc_build/build$ sudo apt-get install gawk
> user@ubuntu16.04:~/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
> user@ubuntu16.04:~/glibc_build/build$ make
>
> Now I have:
>
> user@ubuntu16.04:~/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
> <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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
>>> [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>> _______________________________________________ Paparazzi-devel mailing
>>> list [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________ Paparazzi-devel mailing
>> list [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________ Paparazzi-devel mailing
>> list [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: Ar.Drone 2 session stuck at "Waiting for telemetry"

Gautier Hattenberger-3
Hello,

Last week we flew the Parrot Disco for the first time, we tried a
transitioning vehicle and we did some formation flights with 3 flying
wings: https://www.youtube.com/watch?v=q4b8JRU1Gbw

And in the meantime, we are trying to finish the design and support of
this new board: https://wiki.paparazziuav.org/wiki/Chimera/v1.00

So I'm actually pretty busy ;)

Gautier


Le 20/02/2017 à 23:49, Ben Laurie a écrit :

> On 20 February 2017 at 15:50, Gautier Hattenberger
> <[hidden email]> 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:
>>
>> user@ubuntu16.04:~/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:
>>
>> user@ubuntu16.04:~/glibc_build$ wget
>> http://ftp.gnu.org/gnu/libc/glibc-2.24.tar.xz
>> user@ubuntu16.04:~/glibc_build$ tar -xJf glibc-2.24.tar.xz
>> user@ubuntu16.04:~/glibc_build$ mkdir build && cd build
>> user@ubuntu16.04:~/glibc_build/build$ sudo apt-get install gawk
>> user@ubuntu16.04:~/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
>> user@ubuntu16.04:~/glibc_build/build$ make
>>
>> Now I have:
>>
>> user@ubuntu16.04:~/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
>> <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>
>>>> _______________________________________________ Paparazzi-devel mailing
>>>> list [hidden email]
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> _______________________________________________ Paparazzi-devel mailing
>>> list [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>> _______________________________________________ Paparazzi-devel mailing
>>> list [hidden email]
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> [hidden email]
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
> _______________________________________________
> Paparazzi-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel