More Sphinx doc (#2583)

Co-authored-by: Gautier Hattenberger <gautier.hattenberger@enac.fr>
This commit is contained in:
Fabien-B
2020-09-21 15:51:35 +02:00
committed by GitHub
parent 5e041b5090
commit 3bb42c00be
64 changed files with 1053 additions and 339 deletions
Binary file not shown.

After

Width:  |  Height:  |  Size: 81 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 127 KiB

@@ -0,0 +1,29 @@
.. developer_guide communication
=============
Communication
=============
We saw in the User Guide :doc:`../user_guide/communication` section that you can change which messages are sent, and at which rate. We will see in this section how you can define and send your own messages.
Define a new message
--------------------
By default, PprzLink default message definition is used. You can find it in ``sw/ext/pprzlink/message_definitions/v1.0/messages.xml``. To add your own messages, you first need to copy this file in your ``conf`` directory.
Add your message in that file on the model of the other messages. Make sure to add it in the appropriate message class (telemetry, datalink, ground, ...), and make sure to use
a free name and a free ``id`` within this class. This *id* being encoded on a uin8_t, it must be comprise between 1 and 255 (0 is reserved). As you can see, there are not much left in the telemetry class...
.. note:: The ids are uniq within the class but the names are uniq in the whole file: you can't have two messages with the same name, even if they are in different classes.
Re-build paparazzi with ``make`` at the root directory. your message should now be present in the ``var/messages.xml`` file.
Send a telemetry message
------------------------
If you defined a new telemetry message, you now want the drone to send it. You can either send it manually from a module or use the Paparazzi periodic telemetry.
.. warning::
This section is not written yet, go to `http://wiki.paparazziuav.org/wiki/Telemetry <http://wiki.paparazziuav.org/wiki/Telemetry>`_.
@@ -1,9 +0,0 @@
.. developer_guide dev_second developer2
======================
Developer 2
======================
TBD
Binary file not shown.

After

Width:  |  Height:  |  Size: 156 KiB

@@ -1,4 +1,4 @@
.. developer_guide main_developer index_developer
.. developer_guide index_developer
=================
Developer Guide
@@ -10,5 +10,6 @@ TBD
:maxdepth: 2
system_overview
developer2
communication
modules
@@ -0,0 +1,9 @@
.. developer_guide modules
========
Modules
========
TBD
@@ -1,9 +1,43 @@
.. developer_guide dev_first system_overview
.. developer_guide system_overview
=========================
Detailed System Overview
System Architecture
=========================
TBD
The typical configuration constitute of a standard laptop as ground station and one or more drones, possibly with a RC transmitter for each as safety link. The Command and Control link is made by a pair of modems on the ground and in the drones.
.. image:: general_arch.png
Ground architecture
-------------------
The Gound Control Station (GCS) constits of multiples programs, communicating with each other by the software bus `Ivy <https://www.eei.cena.fr/products/ivy/>`_.
.. note::
Ivy is a simple protocol and a set of open-source (LGPL) libraries and programs that allows applications to broadcast information through text messages, with a publisher / subscriber mechanism based on regular expressions.
.. image:: agents_arch.png
The core Paparazzi programs are Link, which handle the communication with the drones, the Server, which maintain the state of all aircrafts, and the GCS, the user facing application to control the drones.
Many other tools have been developed for various use cases, they are available in the *Tools* menu of the paparazzi center. But more interesting: you can write your own tools that will interact with Paparazzi via the Ivy bus.
Airborne architecture
---------------------
In the case of a fixedwing aircraft, the airborne top level architecture is divided in two processes: the *AP* (autopilot) process which does most of the job, and the *FBW* (Fly by Wire) process. FBW manages the radio receiver and control the servos. In the catastrophic event that the AP process crashes, the aircraft can still be controlled via the RC transmitter.
For the rotorcraft, there is only one process called *Main*.
.. note::
It is planned to make a failsafe process for rotorcraft that will allow basic stabilization and control of the drone.
.. warning::
TODO: Explain airborne architecture
.. image:: airborne_arch.png
The aircraft is configured by various XML configuration files: *airframe*, *flight_plan*, *radio* and *telemetry*. theses will be covered in the :doc:`../user_guide/index_user_guide` section.