looking for the ArduCopter software architecture

[Sam]

Hi,

First of all I'd like say thanks to every developper that worked this awesome project, I've been working with the ardupilot and mission planner code for 2 month (7 hours per day) and I really enjoy what you guys did. 

I'm quite new to the drone world (only worked 6 month on the AR-Drone from parrot) and I'm willing to understand how thing really works, and I was wondering if you could help me figure out the answer of the following. 

I saw this architecture and I wanted to know if something similar exist for the "real" version of the ardupilot ? is there a .elf executable runing on the board ? if yes what is the difference between the sitl and the real one (except the fact that the motor, gps,... are simulated) ?

I'm also having trouble to understand what the ArduCopter.elf is responsable for. I though it was generating the whole simulation but I know MAVProxy has some role to play (since when I connected the mission planner to the ArduCopter executable I couldn't simulate a mission). Can anyone help me understand that ?

My main goal is to manage to make an hitl work so if anyone has some advice I'm also taking them :)

thanks in advance,

Sam

[Kevin Hester]

Hi,

I can help a little with this (does anyone know if there is already a wiki page for this?  I couldn't find one).  The following is just my understanding and there might be errors ;-)

On Tue, May 20, 2014 at 5:18 AM, Sam <ice.scr...@gmail.com> wrote:

Hi,

First of all I'd like say thanks to every developper that worked this awesome project, I've been working with the ardupilot and mission planner code for 2 month (7 hours per day) and I really enjoy what you guys did. 

I'm quite new to the drone world (only worked 6 month on the AR-Drone from parrot) and I'm willing to understand how thing really works, and I was wondering if you could help me figure out the answer of the following. 

I saw this architecture and I wanted to know if something similar exist for the "real" version of the ardupilot ? is there a .elf executable runing on the board ? if yes what is the difference between the sitl and the real one (except the fact that the motor, gps,... are simulated) ?

elf is a container format used on various OSes (with code, data, bss, relocations, symbols etc...).  

For the AVR based autopilots

By the time the ardupilot load reaches the board the elf file doesn't really exist.  The bootloader (I presume at least the avr mask rom is the initial target of the reset vector - but I've never checked) just branches into an appload which was prepopulated into the flash with all relocations applied etc...  

'Drivers' are just in the hal and they directly whack whatever registers they need to whack.

Scheduling is done by some component I've never looked into (i.e. not 'OS' threads) ;-)  (But this is the same with SITL)

For the PX4 based autopilots

There is a real bootloader and a nice 'posixish' OS that loads and runs the arducopter binary (though even in this case it is prelinked with the OS and there is no longer an elf file).

On this board all (or is it just most? - I don't know) HW whacking happens in real drivers - in the 'PX4Firmware' tree.  The APM code talks to these drivers via file descriptors.

The APM scheduler still runs and almost all of the APM code is scheduled with this tick based scheduler.  Some of this makes sense, some of it is an artifact of how the code began life on a 'threadless' CPU.  

For the linux based autopilots

I gather from Tridge and others that it is currently essentially like SITL with lots of stuff done in userspace.  As this code matures I presume the plan is to move out most HAL operations into real OS drivers.  Also I wouldn't be surprised if over time some non realtime operations might move over to OS threads (possibly also useful on the PX4)...

I'm also having trouble to understand what the ArduCopter.elf is responsable for. I though it was generating the whole simulation but I know MAVProxy has some role to play (since when I connected the mission planner to the ArduCopter executable I couldn't simulate a mission). Can anyone help me understand that ?

My main goal is to manage to make an hitl work so if anyone has some advice I'm also taking them :)

thanks in advance,

Sam

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Nizette]

Hi Sam,

As Kevin says, the ELF may or may not be running on the board per se, depending on the particular board, however the code /in/ the ELF is certainly running on the board.

The SITL architecture is as in that picture: Ardu*.elf is the Ardupilot code only, the simulation is done by an external physics engine. In that diagram, you can think of MAVProxy as most of the green lines in the middle and also the GCS in the bottom-left.  It's responsible for routing packets around the place but also has the ability to monitor/interact with the MAVLink telemetry stream.  If you want to connect mission planner to a SITL mission, you need to run the SITL MAVProxy instance with another "--out=" command line switch specifying the IP address and port number mission planner will be running on.

The difference between a SITL binary (ELF, hex, whatever) and one for download to a board is just the compiler used and the hardware abstraction layer wired in.  If you look in libraries/ you'll see a bunch of AP_HAL_* that contains the board-specific code for all supported hardware and SITL.  The SITL HAL is responsible for a small part of the simulation: Taking perfect data from the simulator and making it look like it came from sensors. A simple example is the SITL barometer, it takes altitude from the simulator, adds some noise and drift then makes it look like it came from a real baro (in terms of drivers).

What kind of HIL do you need and why? Ardupilot already has fairly decent HIL support, as far as it goes, but it doesn't find regular use - there's not much that it does that isn't done better my SITL.

HTH.

Ben.

--

[Ben Nizette]

btw, there's no similar architecture diagram for "real" i.e. non-SITL Ardupilot as it'd be pretty boring - the Ardupilot code running on a board optionally connected to a GCS via a (usually radio) telemetry link.

Ben.

[Randy Mackay]

 

     If anyone does get around to adding more developer documentation it should be in this section of the developer wiki I think:

            http://dev.ardupilot.com/wiki/apmcopter-code-overview/

 

     At some point after AVC + AC3.2 I’ll go through and update the existing documentation to match the post onion code structure.

 

-Randy

[David Pawlak]

@Randy, speaking of Oion you posted a good overview of the Onion struxture somewhere, but I can't find it. Do you have a link please!?? Sorry.

[Sam]

Hi, 

First of all thanks you all for the answers, I really appreciate that :)

Le mercredi 21 mai 2014 11:33:00 UTC+2, David Pawlak a écrit :

@Randy, speaking of Oion you posted a good overview of the Onion struxture somewhere, but I can't find it. Do you have a link please!?? Sorry.

On Tuesday, May 20, 2014 10:55:01 PM UTC-4, Randy Mackay wrote:

 

     If anyone does get around to adding more developer documentation it should be in this section of the developer wiki I think:

            http://dev.ardupilot.com/wiki/apmcopter-code-overview/

 

     At some point after AVC + AC3.2 I’ll go through and update the existing documentation to match the post onion code structure.

 

-Randy

 

 Thanks again I'll re-read that :)

btw, there's no similar architecture diagram for "real" i.e. non-SITL Ardupilot as it'd be pretty boring - the Ardupilot code running on a board optionally connected to a GCS via a (usually radio) telemetry link.

Ben.

Okay then  

On Wed, May 21, 2014 at 9:10 AM, Ben Nizette <benni...@gmail.com> wrote:

Hi Sam,

As Kevin says, the ELF may or may not be running on the board per se, depending on the particular board, however the code /in/ the ELF is certainly running on the board.

The SITL architecture is as in that picture: Ardu*.elf is the Ardupilot code only, the simulation is done by an external physics engine. In that diagram, you can think of MAVProxy as most of the green lines in the middle and also the GCS in the bottom-left.  It's responsible for routing packets around the place but also has the ability to monitor/interact with the MAVLink telemetry stream.  If you want to connect mission planner to a SITL mission, you need to run the SITL MAVProxy instance with another "--out=" command line switch specifying the IP address and port number mission planner will be running on.

If i'm understanding well, this mean that MAVProxy is mainly transmitting the packets to the ArduPilot (which is the Ardu*.elf on the sitl case) ? 

I managed to connect my mission planner to the MAVProxy interface using UDP. Then I tried to connect Mission Planner to the sitl through the TCP port (by placing it on the bottom left in the diagram) and I had some "bad gyro health" message and wasn't able to order the sitl to arm the motor for example. So I though maybe MAVProxy was simulated some hardware part, but then i read that "The APM code is built and run on a PC. A simulator provides sensor inputs" on this website : http://tridge.github.io/MAVProxy/simulation.html 

 

The difference between a SITL binary (ELF, hex, whatever) and one for download to a board is just the compiler used and the hardware abstraction layer wired in.  If you look in libraries/ you'll see a bunch of AP_HAL_* that contains the board-specific code for all supported hardware and SITL.  The SITL HAL is responsible for a small part of the simulation: Taking perfect data from the simulator and making it look like it came from sensors. A simple example is the SITL barometer, it takes altitude from the simulator, adds some noise and drift then makes it look like it came from a real baro (in terms of drivers).

So if I get it correctly the libs are compiled and made into an executable file that can run on a PC, the AP_HAL_* (can you also tell me what HAL stand for ?) folder contains the code that add noise and such to make the data generated by a simulator look like it comes from a real sensor ? So if this is correct what is the simulator MAVProxy ? I'm really sorry but I'm confuse :s

 

What kind of HIL do you need and why? Ardupilot already has fairly decent HIL support, as far as it goes, but it doesn't find regular use - there's not much that it does that isn't done better my SITL.

Just the board and no other hardware, It's a goal i fixed to myself mainly to understand the code, how things really works in low level and to get started. I saw that the SITL is really accurate and really well done :-)

HTH.

Ben.

[Enrico Mulas]

Hi,

HAL stand for Hardware Abstraction Layer

http://diydrones.com/profiles/blogs/lots-of-changes-to-apm-development

Enrico

[Ben Nizette]

On Wed, May 21, 2014 at 9:10 AM, Ben Nizette <benni...@gmail.com> wrote:

Hi Sam,

As Kevin says, the ELF may or may not be running on the board per se, depending on the particular board, however the code /in/ the ELF is certainly running on the board.

The SITL architecture is as in that picture: Ardu*.elf is the Ardupilot code only, the simulation is done by an external physics engine. In that diagram, you can think of MAVProxy as most of the green lines in the middle and also the GCS in the bottom-left.  It's responsible for routing packets around the place but also has the ability to monitor/interact with the MAVLink telemetry stream.  If you want to connect mission planner to a SITL mission, you need to run the SITL MAVProxy instance with another "--out=" command line switch specifying the IP address and port number mission planner will be running on.

If i'm understanding well, this mean that MAVProxy is mainly transmitting the packets to the ArduPilot (which is the Ardu*.elf on the sitl case) ? 

It's routing packets between Ardupilot (.elf) and the simulator, sending and receiving MAVLink messages like a GCS would and can optionally route these MAVLink messages to another GCS.

 

I managed to connect my mission planner to the MAVProxy interface using UDP. Then I tried to connect Mission Planner to the sitl through the TCP port (by placing it on the bottom left in the diagram) and I had some "bad gyro health" message and wasn't able to order the sitl to arm the motor for example.

Yes, MAVProxy has /two/ roles, it routes the simulator packets as well as acting as a GCS.  If you try and replace this with something that's only a GCS, it won't work.  MAVProxy is not doing any simulation itself, but what you're seeing is the fact that if it isn't running, the simulator packets containing things like angular rates will not be sent back to Ardupilot and therefore the sensors will not work.

 

So I though maybe MAVProxy was simulated some hardware part, but then i read that "The APM code is built and run on a PC. A simulator provides sensor inputs" on this website : http://tridge.github.io/MAVProxy/simulation.html 

That's right.  I hope the above makes it clearer that there are three components: Arudipilot, simulator and the MAVProxy instance that glues it all together.  As I mentioned before, it might help to think of MAVProxy as all the green interconnect lines on that diagram you sent through before, not just as a GCS (it's not completely true, but close).

 

 

The difference between a SITL binary (ELF, hex, whatever) and one for download to a board is just the compiler used and the hardware abstraction layer wired in.  If you look in libraries/ you'll see a bunch of AP_HAL_* that contains the board-specific code for all supported hardware and SITL.  The SITL HAL is responsible for a small part of the simulation: Taking perfect data from the simulator and making it look like it came from sensors. A simple example is the SITL barometer, it takes altitude from the simulator, adds some noise and drift then makes it look like it came from a real baro (in terms of drivers).

So if I get it correctly the libs are compiled and made into an executable file that can run on a PC, the AP_HAL_* (can you also tell me what HAL stand for ?) folder contains the code that add noise and such to make the data generated by a simulator look like it comes from a real sensor ?

Yep, that's right. As Enrico mentioned, HAL is hardware abstraction layer. It is the chunk of code that means that no other part of Ardupilot knows what kind of board it's running on (APM, Pixhawk, SITL etc) by making all the boards kind of look the same.  In the case of SITL, "look the same" means to add noise etc.

 

So if this is correct what is the simulator MAVProxy ? I'm really sorry but I'm confuse :s

I don't understand this question, but I hope the above has answered it anyway :)

 

 

What kind of HIL do you need and why? Ardupilot already has fairly decent HIL support, as far as it goes, but it doesn't find regular use - there's not much that it does that isn't done better my SITL.

Just the board and no other hardware, It's a goal i fixed to myself mainly to understand the code, how things really works in low level and to get started. I saw that the SITL is really accurate and really well done :-)

OK.  As I say, HIL is already done so if you're looking for an outcome, just use it! But if you're using SITL as a way of getting in to the code, fair enough.

Cheers,

  --Ben.

 

HTH.

Ben.

[Randy Mackay]

 

     I’ve added the post-onion code structure pids to the arducopter code overview landing page.  This is probably not the perfect place to put it.  Instead it should probably go on an “Overview page” but for now you can find it at the link below.

           http://dev.ardupilot.com/wiki/apmcopter-code-overview/

 

-Randy

 

 

From: drones-...@googlegroups.com [mailto:drones-...@googlegroups.com] On Behalf Of Ben Nizette
Sent: May 22, 2014 10:54 AM
To: drones-...@googlegroups.com
Subject: Re: [drones-discuss] looking for the ArduCopter software architecture

 

 

On Wed, May 21, 2014 at 9:10 AM, Ben Nizette <benni...@gmail.com> wrote:

[Sam]

Hi, 

Okay now I get it thanks a lot, like really I've been struggling to understand that for a while. You guys are awesome thanks for that explanaition I'm gonna like this community :-) I know it sound too much but I really thinks so. 

Thanks again :)

Sam