PaparazziUAV - User contributions [en]

Micro logger

2014-08-29T08:43:01Z

Karlito139: /* Logging values */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

===Capability===
This logger is capable of logging the entire IMU (9 axis) on 32 bits values at 512Hz. This is possible when you erase completely the memory at the beginning of the log (ERASE_MEMORY_AT_START set to 1).

In case of buffer overflow, the reading tool is capable of "rebuilding" the missed values. It is going to put zeros where we missed values.

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

* SKIP_X_CALLS_BETWEEN_VALUES : you might want to slow down the logger instead of losing values (because of buffer overflows). if that value is set to 0, a new value of every logged messages will be added to the buffer. If set to 2, we will wait two calls to the module, then during the third one we will writte the values to the buffer. By default this modules is called at 512Hz.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. You might want to be certain of the frequency at which the module is called by loading it like that :

<modules main_freq="512">
<load name="high_speed_logger_direct_memory.xml"/>
</modules>

Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [http://karlito139.github.io/lisa_s_logger_reader/ here]. The source code is available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T15:49:19Z

Karlito139: /* Reading the values back */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

===Capability===
This logger is capable of logging the entire IMU (9 axis) on 32 bits values at 512Hz. This is possible when you erase completely the memory at the beginning of the log (ERASE_MEMORY_AT_START set to 1).

In case of buffer overflow, the reading tool is capable of "rebuilding" the missed values. It is going to put zeros where we missed values.

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

* SKIP_X_CALLS_BETWEEN_VALUES : you might want to slow down the logger instead of losing values (because of buffer overflows). if that value is set to 0, a new value of every logged messages will be added to the buffer. If set to 2, we will wait two calls to the module, then during the third one we will writte the values to the buffer. By default this modules is called at 512Hz.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [http://karlito139.github.io/lisa_s_logger_reader/ here]. The source code is available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T14:18:41Z

Karlito139: /* Introduction */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

===Capability===
This logger is capable of logging the entire IMU (9 axis) on 32 bits values at 512Hz. This is possible when you erase completely the memory at the beginning of the log (ERASE_MEMORY_AT_START set to 1).

In case of buffer overflow, the reading tool is capable of "rebuilding" the missed values. It is going to put zeros where we missed values.

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

* SKIP_X_CALLS_BETWEEN_VALUES : you might want to slow down the logger instead of losing values (because of buffer overflows). if that value is set to 0, a new value of every logged messages will be added to the buffer. If set to 2, we will wait two calls to the module, then during the third one we will writte the values to the buffer. By default this modules is called at 512Hz.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T14:15:37Z

Karlito139: /* Configuration of the module */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

* SKIP_X_CALLS_BETWEEN_VALUES : you might want to slow down the logger instead of losing values (because of buffer overflows). if that value is set to 0, a new value of every logged messages will be added to the buffer. If set to 2, we will wait two calls to the module, then during the third one we will writte the values to the buffer. By default this modules is called at 512Hz.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T14:12:49Z

Karlito139: /* Configuration of the module */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 4 Bytes values in a 2 Bytes slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log. This value is equivalent to the size of the values_to_log array.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T07:50:42Z

Karlito139: /* Reading the values back */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 32 bits values in a 16 bites slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

For this operation you will need to get the reader application available [https://github.com/karlito139/lisa_s_logger_reader here].

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T07:48:56Z

Karlito139: /* Reading the values back */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* very light (hard to do lighter)
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Configuration of the module==
To configure the messages you want to log, you will need to edite the module c file in : sw/airborne/modules/loggers/high_speed_logger_direct_memory.c. At the top of the file you will have a section containing all the parameters that you can change. Among those you got :
* ERASE_MEMORY_AT_START : if set to 1 the memory will be erased completly when starting a new log. This will take a little bit less than a minute, but afterwards you will be able to log values at a higher rate than if you didn't do it. If you let it to 0, the module is going to erase the memory block by block of 4K when needed.

* SIZE_OF_LOGGED_VALUES : the number of Bytes that each value logged must be (in memory). You can write a 32 bits values in a 16 bites slots, you just need to be certain that you don't have any overflows.

* NBR_VALUES_TO_LOG : the number of messages you want to log.

Then you have two arrays :

* values_to_log : containing the pointer to the values to log.
* name_of_the_values : the name of the messages logged. This is simply an aesthetic configuration, for you to know which message were logged.

==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

[[File:GCS mem.png]]

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==

[[File:Micro logger.png]]

WARNING !!! : On some boards the UART port is used also by the GPS. The soft behind the GPS might read all the values on the port instead of the logger module. To solve that issue you simply need to use an other UART port for the logger module (configured in : conf/modules/high_speed_logger_direct_memory.xml). The other solution is to move the GPS in you board makefile.

To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-28T07:46:16Z

Karlito139: /* Configuration of the module */

Micro logger

2014-08-28T07:45:28Z

Karlito139: /* How to use it */

File:Micro logger.png

2014-08-27T17:00:41Z

Karlito139: Karlito139 uploaded a new version of "File:Micro logger.png"

File:Micro logger.png

2014-08-27T16:57:46Z

Karlito139: Karlito139 uploaded a new version of "File:Micro logger.png"

Micro logger

2014-08-27T16:56:50Z

Karlito139:

File:Micro logger.png

2014-08-27T16:56:28Z

Karlito139:

File:GCS mem.png

2014-08-27T16:55:45Z

Karlito139:

Micro logger

2014-08-27T16:53:56Z

Karlito139: /* Advantages */

Micro logger

2014-08-27T16:53:29Z

Karlito139: /* Logging values */

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* hard to do lighter
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "'''settings/modules/high_speed_logger_direct_memory.xml'''".

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==
To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-27T16:51:59Z

Karlito139:

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* hard to do lighter
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "settings/modules/high_speed_logger_direct_memory.xml".

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==
To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finally you can click on the export button at the bottom of the window to save the values in a csv file.

Micro logger

2014-08-27T16:51:40Z

Karlito139: Created page with "=Introduction= The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot. ===Advantages=== * hard to do lighter * no bad ..."

=Introduction=

The micro logger is simply a memory chip (S25FL128S or S25FL256S) connected to one SPI port of your autopilot.

===Advantages===
* hard to do lighter
* no bad connexions (the memory needs to be soldered)

===Disadvantages===
* hard to remove
* slower than other loggers

=How to use it=
==Logging values==
To use the micro logger you simply need to load the module "'''high_speed_logger_direct_memory'''" in your airframe file. Then you are going to have to add the GUI to your GCS by adding to your settings the file : "settings/modules/high_speed_logger_direct_memory.xml".

Then in the GCS you can go in the tab settings, then logger. In this tab you will have only one command to change the status of the module.

At the start the module is in idle mode. To start logging you will need to prepare the memory first. To do that simply select the initialise mode and validate. The module will work. To test if the module have completed it's work you can click on the value to the left of the drop down menu. Once completed the status will be back to idle.

Then you can start actually logging values by selecting the "start log" mode and validating.

Once you are done with your log you need to select the "stop log" mode and validate.

==Reading the values back==
To read the values back you simply need to connect to your autopilot using a serial connexion. Then start the micro logger application, at the top right of the interface you get a drop down menu containing all the serial ports available on your computer, select the one corresponding to your autopilot. Then simply click on the "Dump memory" button. The application is going to fetch all the values stored in the memory (warning this operation might be slow, up to 40 minutes if you used the entire memory).

Finaly you can click on the export button at the bottom of the window to save the values in a csv file.

Video replay

2014-07-25T08:35:00Z

Karlito139: /* Common */

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

==Capture==
When capturing a video f your flight you can simplify the synchronization of the two files (the log file and the video file) by using son tags. When you open the video synchronizer (in paparazzi center : tools/video synchronizer), you get a tab called "capture". If you click on this tab you will be getting a button called sync. When you press this button your screen is going to blink for 1s. This will be easy to detect in you video file, and at the same time the tool is going to add a flag in the log file.

==Replay==
If you used the capture function of the tool you can use the automatic synchronization. If you didn't you will need to synchronize the files by hand using the manual technic. Both techniques starts the same way with the common section.

===Common===
First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. You are going to have to configure your GCS in order for it to display the 2D map and the video. This part is explained [https://wiki.paparazziuav.org/wiki/GCS_Configuration here]. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

===Automatic===
You are going to have to open the video file in a player and find the time at which you can see the flap (when the screen of your computer blinks). Then in the video synchronizer tool (in paparazzi center : tools/video synchronizer), you can select the replay tab at the top and then the auto tab. There you just got to specify the time at which you saw the blinking screen in the video, and you are done. When playing the log the video will start playing as if nothing append. But as soon as the tag (the one written in the log file) is read the video will synchronize with the log file player.

===Manual===
We now need to synchronize the log and video. For that you just need to launch the video synchronizer (in paparazzi center : tools/video synchronizer). This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you are going to have to select the Replay tab, and then the Manual tab. Then you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

Video replay

2014-07-24T14:59:35Z

Karlito139: /* How to use it */

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

==Capture==
When capturing a video f your flight you can simplify the synchronization of the two files (the log file and the video file) by using son tags. When you open the video synchronizer (in paparazzi center : tools/video synchronizer), you get a tab called "capture". If you click on this tab you will be getting a button called sync. When you press this button your screen is going to blink for 1s. This will be easy to detect in you video file, and at the same time the tool is going to add a flag in the log file.

==Replay==
If you used the capture function of the tool you can use the automatic synchronization. If you didn't you will need to synchronize the files by hand using the manual technic. Both techniques starts the same way with the common section.

===Common===
First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. You are going to have to configure your GCS in order for it to display the 2D map and the video. This part is explained here. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

===Automatic===
You are going to have to open the video file in a player and find the time at which you can see the flap (when the screen of your computer blinks). Then in the video synchronizer tool (in paparazzi center : tools/video synchronizer), you can select the replay tab at the top and then the auto tab. There you just got to specify the time at which you saw the blinking screen in the video, and you are done. When playing the log the video will start playing as if nothing append. But as soon as the tag (the one written in the log file) is read the video will synchronize with the log file player.

===Manual===
We now need to synchronize the log and video. For that you just need to launch the video synchronizer (in paparazzi center : tools/video synchronizer). This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you are going to have to select the Replay tab, and then the Manual tab. Then you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

Video replay

2014-07-24T14:56:28Z

Karlito139: /* How to use it */

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

==Capture==
When capturing a video f your flight you can simplify the synchronisation of the two files (the log file and the video file) by using son tags. When you open the video synchronizer (in paparazzi center : tools/video synchronizer), you get a tab cald "capture". If you click on this tab you will be getting a button called sync. When you press this button your screen is going to blick for 1s. This will be easy to detect in you video file, and at the same time the tool is going to add a flag in the log file.

==Replay==
If you used the cature fonction of the tool you can use the automatique synchronisation. If you didn't you will need to synchronise the files by hand using the manual technic. Both techniques starts the same way with the common section.

===Common===
First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. You are going to have to configure your GCS in order for it to diplay the 2D map and the video. This part is explained here. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

===Automatique===
You are going to have to open the video file in a player and find the time at which you can see the flap (when the screen of your computer blicks). Then in the video synchronizer tool (in paparazzi center : tools/video synchronizer), you can select the replay tab at the top and then the auto tab. There you just got to specify the time at wich you saw the blicking screen in the video, and you are done. When playing the log the video will start playing as if nothing append. But as soon as the tag (the one written in the log file) is read the video will synchronise with the log file player.

===Manual===
We now need to synchronise the log and video. For that you just need to launch the video synchronizer (in paparazzi center : tools/video synchronizer). This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you are going to have to select the Replay tab, and then the Manual tab. Then you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

File:Video replay example.png

2014-07-24T14:54:04Z

Karlito139: Karlito139 uploaded a new version of "File:Video replay example.png"

Video replay

2014-07-14T08:39:31Z

Karlito139: /* How to use it */

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. You are going to have to configure your GCS in order for it to diplay the 2D map and the video. This part is explained [https://wiki.paparazziuav.org/wiki/GCS_Configuration#Video_plugin here]. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

We now need to synchronise the log and video. For that you just need to launch the video synchronisator (in paparazzi center : tools/video synchronisator. This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

Video replay

2014-07-09T14:13:10Z

Karlito139: /* How to use it */

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

We now need to synchronise the log and video. For that you just need to launch the video synchronisator (in paparazzi center : tools/video synchronisator. This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

Video replay

2014-07-09T14:12:42Z

Karlito139: Created page with "This tool is here to let you play a recording of your flight in sync with the log file you recorded. File:Video_replay_example.png = How to use it = First of all you ar..."

This tool is here to let you play a recording of your flight in sync with the log file you recorded.

[[File:Video_replay_example.png]]

= How to use it =

First of all you are going to need to tell your GCS that you want to display a video. For that you need to change the command used by paparazzi center to call GCS. When you launch a replay session, paparazzi center should call GCS like that :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs

We are going to change it to :

/path/to/paparazzi/paparazzi/sw/ground_segment/cockpit/gcs -layout horizontal_with_video.xml -mplayer '-udp-slave /path/to/video/to/play.mp4'

Don't forget to enter the path to the video you want to play. This is going to launch the GCS with the top part sliced in two the left part displaying the map, the right one displaying the video.

We now need to synchronise the log and video. For that you just need to launch the video synchronisator (in paparazzi center : tools/video synchronisator. This tool is going to catch the time stamp sent by the log file player and send them to mplayer to display the right part of the video. In the window of this tool you can define the latency between the beginning of the video and the log (this value can be negative if needed).

Once this is done just open your log file using the log file player and you video is going to be played in sync with your log.

File:Video replay example.png

2014-07-09T14:02:52Z

Karlito139:

Server

2014-07-08T08:59:48Z

Karlito139: /* Export KML to Google Map */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree>
__TOC__

The <tt>server</tt> (in <tt>sw/ground_segment/tmtc/</tt>) is an agent that logs, distributes, and preprocesses messages for the [[GCS]] and other agents as described in the [[Overview#System_Architecture|system overview]].

See [[DevGuide/Server_GCS_com]] for the communication between the ''server'' and the ''[[GCS]]''.

== Options ==
-b Bus Default is 127.255.255.255:2010
-hostname <hostname> Set the address for the http server
-http Send http: URLs (default is file:)
-kml Enable KML file updating
-kml_no_http KML without web server (local files only)
-kml_port Port for KML files (default is 8889)
-n Disable log
-no_md5_check Disable safety matching of live and current configurations
-replay_old_log Enable aircraft registering on PPRZ_MODE messages
-help Display this list of options
--help Display this list of options

== Export KML to Google Map==
It is useful to export Flight information to Google Map. you can show basic flight information in google map cross platform through IP network.

You will need a webserver runing in the GCS computer, for python simpleHTTPServer:

''cd ~/paparazzi/''

''python -m SimpleHTTPServer''

to check if it work, you should see 8000 port is opened for listening.

-''netstat -l|grep 8000''

Then in Paparazzi center, excute a session. Pass some parameters to server agent:

''server -kml -kmlport 8000 -hostname 192.168.0.100(replace with you paparazzi center IP address)''

It's done. Now in any computer in the network, open browser to access <nowiki>http://192.168.0.100:8000/var/airframes/(you AC name)/</nowiki>
you will see FollowMe.kml file, open it with Google earth. you will be able to see the real time flight information. the information updated are:

1. AC lat, lon, alt
2. Flight Plan
3. current route

[[File:Kml_export.png]]
----

[[Category:Tools]] [[Category:User_Documentation]]

Lisa/S

2014-07-07T09:18:14Z

Karlito139: /* Barometer */

[[File:tudelft_logo.jpg|left|120px|link=http://mavlab.lr.tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing enough functionality to enable fully autonomous operation.

=== Mechanical Dimensions ===

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add one line to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Once that line is added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

Warning : the barometer doesn't seams to be working at a higher frequency than 120Hz in a fixed wing airframe. Than mean that in a fixed wing airframe the PERIODIC_FREQUENCY must be equal or lower than 120. In rotorcraft the barometer works fine.

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2014-06-25 Lisa/S is available for purchase from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Lisa/S

2014-07-07T09:06:24Z

Karlito139: /* Barometer */

[[File:tudelft_logo.jpg|left|120px|link=http://mavlab.lr.tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing enough functionality to enable fully autonomous operation.

=== Mechanical Dimensions ===

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add one line to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Once that line is added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

Warning : the barometer doesn't seams to be working at a higher frequency than 120Hz.

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2014-06-25 Lisa/S is available for purchase from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Subsystem/actuators

2014-06-26T12:40:53Z

Karlito139: /* Dual PWM */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Subsystems</categorytree>
This subsystem only needs be explicitly specified for rotorcrafts where there are several different actuators implementations and you have to add the correct one depending on the ESCs you use.

Currently possible actuators subsystems are
* ''mkk''
* ''asctec''
* ''asctec_v2''
* ''pwm''
* ''skiron''
* ''heli''
* ''ardrone2''

== MKK ==
Mikrokopter ESCs
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="mkk">
<configure name="MKK_I2C_SCL_TIME" value="50"/> 
</subsystem>
<define name="I2C_TRANSACTION_QUEUE_LEN" value="10"/> 
</firmware>
</source>
}}

* ''MKK_I2C_SCL_TIME'' is specific to LPC21x based boards (e.g. booz) and has no effect for STM32 based boards (e.g. Lisa/M/L)

=== XML configuration ===
required defines in section ''ACTUATORS_MKK'':
* ''NB'': number of motors
* ''ADDR'': the I2C addresses of your motors
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="ACTUATORS_MKK" prefix="ACTUATORS_MKK_">
<define name="NB" value="4"/>
<define name="ADDR" value="{ 0x52, 0x54, 0x56, 0x58 }"/>
</section>
</source>
}}
The order of addresses in the list defines the numbering of motors! Warn on this during motor mixing!

You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].
MKK specific values for SUPERVISION defines:
* ''STOP_MOTOR'' : 0, optional, as the default is already 0
* ''MIN_MOTOR'' : 3
* ''MAX_MOTOR'' : 200

== Asctec v1 ==
These controllers already to the mixing themselves, so the [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]] section is not needed.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec"/>
</firmware>
</source>
}}

== Asctec v2 ==
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec_v2"/>
</firmware>
</source>
}}
=== XML configuration ===
You need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].

== PWM ==
Only for stm32 based autopilot boards (eg. Lisa/M, Lisa/L)
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="pwm">
<define name="SERVO_HZ" value="400"/>
</subsystem>
</firmware>
</source>
}}

The define ''SERVO_HZ'' sets a higher update frequency for the pwm controllers which is needed for good response times on some ESCs. Some newer ESCs are said to work better with lower frequencies. More information should be added here.
=== XML configuration ===
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<servos min="0" neutral="0" max="0xff">
<servo name="FRONT" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="BACK" no="1" min="1000" neutral="1000" max="2000"/>
<servo name="LEFT" no="2" min="1000" neutral="1000" max="2000"/>
<servo name="RIGHT" no="3" min="1000" neutral="1000" max="2000"/>
</servos>
</source>
}}
You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].

== Dual PWM ==
This driver allows you to generate dual pulses to control for example double servos like those :

[[File:Dual linear servos.jpg]]

The signal we want to generate look like that :

[[File:Dual_pulse.png]]

During the time of a regular pwm pulse (20ms) we got two parts :
* the first 1 with a total period of 4ms. During that part we generate the first pulse that is going to control for exemple the first servo.
* the first 2 with a total period of 16ms. During that part we generate the second pulse that is going to control for exemple the second servo.

=== How to use the driver ===

'''CAUTION!''' This module is only implemented on the lisa M and lisa S boards at the time of writing this documentation (28 mars 2014)

First of all you are going to need to add the subsystem that is going to generate those pulses :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>

...

<subsystem name="actuators" type="dualpwm">
<define name="DUAL_PWM_ON"/>
</subsystem>

</firmware>
</source>
}}

=== XML configuration ===
Then we will be able to add a servo block into the airframe file (in the same way we would for regular servos). But we have to specify the driver that we are using for thoses servos :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
...
<servos driver="DualPwm">
<servo name="SWITCH" no="3" min="1100" neutral="1500" max="1900"/>
<servo name="pitchator" no="2" min="1100" neutral="1500" max="1900"/>
</servos>
...
</source>
}}

'''CAUTION!''' The tricky part about this module is that it requires the use of the full timer (that was previously shared between multiple regular pwm). In order to reduce the wast of pins we can only put that type of servos on specifics pins :
* lisa S (version 0.1) : on the servos 2 and 3 (as shown above). The dual PWM will then but outputted on the 5th pin (yes that is not logical).
* lisa M (version 2.0) : on the servos 4 and 5. The dual PWM will be outputted on the 4th pin.


[[Category:User_Documentation]] [[Category:Subsystems]]

Lisa/S

2014-04-10T12:58:30Z

Karlito139: /* IMU */

[[File:tudelft_logo.jpg|left|120px|link=http://tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing a lot of functionality is achieved:

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 debug UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add one line to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Once that line is added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2013-11-27 Lisa/S is available for pre-order from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Lisa/S

2014-04-10T12:37:14Z

Karlito139: /* Barometer */

[[File:tudelft_logo.jpg|left|120px|link=http://tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing a lot of functionality is achieved:

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 debug UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add one line to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Once that line is added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

== IMU ==

The IMU used on the lisa s is a regular aspirin 2. But depending on how you put the lisa s on your UAV you migth get the axes mixed. You can for exemple put the lisa S side way :

[[File:Lisa s sideway.jpg]]

For that you just need to add an option in your airframe :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="LISA_S_SIDEWAY"/>
...
</firmware>
</source>
}}

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2013-11-27 Lisa/S is available for pre-order from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Lisa/S

2014-04-10T08:42:46Z

Karlito139: /* Barometer */

[[File:tudelft_logo.jpg|left|120px|link=http://tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing a lot of functionality is achieved:

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 debug UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add two lines to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
<configure name="LISA_S_BARO" value="BARO_MS5611_SPI"/>
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Then you just need to load the associated module (still in your airframe file :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
...
<modules>
...
<load name="baro_ms5611_spi.xml"/>
...
</modules>
...
</source>
}}

Once thoses 3 lines are added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

== IMU ==

The IMU used on the lisa s is a regular aspirin 2. But depending on how you put the lisa s on your UAV you migth get the axes mixed. You can for exemple put the lisa S side way :

[[File:Lisa s sideway.jpg]]

For that you just need to add an option in your airframe :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>
...
<define name="LISA_S_SIDEWAY"/>
...
</firmware>
</source>
}}

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2013-11-27 Lisa/S is available for pre-order from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

File:Lisa s sideway.jpg

2014-04-10T08:40:48Z

Karlito139:

Lisa/S

2014-04-02T15:33:42Z

Karlito139:

[[File:tudelft_logo.jpg|left|120px|link=http://tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing a lot of functionality is achieved:

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 debug UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add two lines to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
<configure name="LISA_S_BARO" value="BARO_MS5611_SPI"/>
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
</source>
}}

Then you just need to load the associated module (still in your airframe file :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
...
<modules>
...
<load name="baro_ms5611_spi.xml"/>
...
</modules>
...
</source>
}}

Once thoses 3 lines are added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2013-11-27 Lisa/S is available for pre-order from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Lisa/S

2014-04-02T15:31:34Z

Karlito139:

[[File:tudelft_logo.jpg|left|120px|link=http://tudelft.nl/en/]]
[[File:1bitsquared_logo.png|left|120px|link=http://1bitsquared.com]]
[[Image:Lisa S V0 1 r2 on finger.jpg|300px|right]]

__TOC__

== Lisa/S ==

Lisa/S is a very small general purpose autopilot. The main goal of creating an autopilot of minimal size and weight, while providing a lot of functionality is achieved:

* '''Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")'''
* '''Weight: 2.8g (0.1oz)'''

=== Features ===

* 72MHz 32bit ARM Cortex M3 MCU with 16KB RAM and 512KB Flash
* Combined 3 Axis Gyroscope and 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (Altimeter)
* Onboard U-Blox GPS
* Pads to simply connect a [[SuperbitRF|Superbit CYRF]] RC and telemetry module
* Switching buck/boost converter allowing wide range of power input making it perfect and stable for operation from a 1S LiPO cell.
* 2 MOSFET switches connected to PWM output channels
* 6 PWM (servo) outputs
* 1 debug UART port
* 1 CAN interface
* 1 Bind/Boot tact switch
* SWD programming/debugging interface
* Size: 20mm x 20mm x 5mm (0.787" x 0.787" x 0.197")
* Weight: 2.8g (0.1oz)

=== Pictures ===

[[Image:Lisa_s_v0_1_r2_top_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_ruler.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_top_superbit.jpg|300px]]
[[Image:Lisa_s_v0_1_r2_bottom_superbit.jpg|300px]]

So if you are ready to make your tiny plane fly autonomously,[http://1bitsquared.com/collections/frontpage/products/lisa-s you can already order one here]

== Pinout ==

TODO

== Block Diagrams ==

TODO

== Barometer ==

In order to use the barometer, you just need to add two lines to your firmware block (in your airframe file) :

{{Box Code|conf/airframes/myplane.xml|
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
<configure name="LISA_S_BARO" value="BARO_MS5611_SPI"/>
...
</target>
...
<define name="USE_BAROMETER" value="TRUE"/>
...
</firmware>
}}

Then you just need to load the associated module (still in your airframe file :

{{Box Code|conf/airframes/myplane.xml|
...
<modules>
...
<load name="baro_ms5611_spi.xml"/>
...
</modules>
...
}}

Once thoses 3 lines are added to the airframe file, you should be able to get the values of the barometer and paparazzi is going to take them into account when doing it's calculations.

== Schematics ==

[[Image:Lisa_s_0_1_r1_schematic.png|300px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

== Availability ==
[[File:1bitsquared_logo.png|100px|link=http://1bitsquared.com]]

As of 2013-11-27 Lisa/S is available for pre-order from [http://1bitsquared.com/products/lisa-s-starter-kit 1 BIT SQUARED].

Subsystem/actuators

2014-03-31T08:10:28Z

Karlito139:

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Subsystems</categorytree>
This subsystem only needs be explicitly specified for rotorcrafts where there are several different actuators implementations and you have to add the correct one depending on the ESCs you use.

Currently possible actuators subsystems are
* ''mkk''
* ''asctec''
* ''asctec_v2''
* ''pwm_supervision''
* ''skiron''
* ''heli''
* ''ardrone2''

== MKK ==
Mikrokopter ESCs
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="mkk">
<configure name="MKK_I2C_SCL_TIME" value="50"/> 
</subsystem>
<define name="I2C_TRANSACTION_QUEUE_LEN" value="10"/> 
</firmware>
</source>
}}

* ''MKK_I2C_SCL_TIME'' is specific to LPC21x based boards (e.g. booz) and has no effect for STM32 based boards (e.g. Lisa/M/L)

=== XML configuration ===
required defines in section ''ACTUATORS_MKK'':
* ''NB'': number of motors
* ''ADDR'': the I2C addresses of your motors
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="ACTUATORS_MKK" prefix="ACTUATORS_MKK_">
<define name="NB" value="4"/>
<define name="ADDR" value="{ 0x52, 0x54, 0x56, 0x58 }"/>
</section>
</source>
}}
The order of addresses in the list defines the numbering of motors! Warn on this during motor mixing!

You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].
MKK specific values for SUPERVISION defines:
* ''STOP_MOTOR'' : 0, optional, as the default is already 0
* ''MIN_MOTOR'' : 3
* ''MAX_MOTOR'' : 200

== Asctec v1 ==
These controllers already to the mixing themselves, so the [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]] section is not needed.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec"/>
</firmware>
</source>
}}

== Asctec v2 ==
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="asctec_v2"/>
</firmware>
</source>
}}
=== XML configuration ===
You need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].

== PWM Supervision ==
Only for stm32 based autopilot boards (eg. Lisa/M, Lisa/L)
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft">
...
<subsystem name="actuators" type="pwm_supervison">
<define name="SERVO_HZ" value="400"/>
</subsystem>
</firmware>
</source>
}}

The define ''SERVO_HZ'' sets a higher update frequency for the pwm controllers which is needed for good response times.
=== XML configuration ===
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<servos min="0" neutral="0" max="0xff">
<servo name="FRONT" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="BACK" no="1" min="1000" neutral="1000" max="2000"/>
<servo name="LEFT" no="2" min="1000" neutral="1000" max="2000"/>
<servo name="RIGHT" no="3" min="1000" neutral="1000" max="2000"/>
</servos>
</source>
}}
You also need the matching [[Rotorcraft_Configuration#Motor_Mixing|Motor Mixing section]].
Example PWM specific values for SUPERVISION defines:
* ''STOP_MOTOR'' : 800
* ''MIN_MOTOR'' : 1000
* ''MAX_MOTOR'' : 2000

== Dual PWM Supervision ==
This module allow you to generate dual pulses to control for example double servos like those :

[[File:Dual linear servos.jpg]]

The signal we want to generate look like that :

[[File:Dual_pulse.png]]

During the time of a regular pwm pulse (20ms) we got two parts :
* the first 1 with a total period of 4ms. During that part we generate the first pulse that is going to control for exemple the first servo.
* the first 2 with a total period of 16ms. During that part we generate the second pulse that is going to control for exemple the second servo.

=== How to use the module ===

'''CAUTION!''' This module is only implemented on the lisa M and lisa S boards at the time of writing this documentation (28 mars 2014)

First of all you are going to need to add the subsystem that is going to generate those pulses :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing">
<target name="ap" board="lisa_s_0.1">
...
</target>

...

<subsystem name="actuators" type="dualPwm">
<define name="DUAL_PWM_ON"/>
</subsystem>

</firmware>
</source>
}}

=== XML configuration ===
Then we will be able to add a servo block into the airframe file (in the same way we would for regular servos). But we have to specify the driver that we are using for thoses servos :

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
...
<servos driver="DualPwm">
<servo name="SWITCH" no="3" min="1100" neutral="1500" max="1900"/>
<servo name="pitchator" no="2" min="1100" neutral="1500" max="1900"/>
</servos>
...
</source>
}}

'''CAUTION!''' The tricky part about this module is that it requires the use of the full timer (that was previously shared between multiple regular pwm). In order to reduce the wast of pins we can only put that type of servos on specifics pins :
* lisa S (version 0.1) : on the servos 2 and 3 (as shown above). The dual PWM will then but outputted on the 5th pin (yes that is not logical).
* lisa M (version 2.0) : on the servos 4 and 5. The dual PWM will be outputted on the 4th pin.


[[Category:User_Documentation]] [[Category:Subsystems]]

File:Dual linear servos.jpg

2014-03-28T17:11:23Z

Karlito139: Karlito139 uploaded a new version of "File:Dual linear servos.jpg"

File:Dual pulse.png

2014-03-28T17:10:35Z

Karlito139: Karlito139 uploaded a new version of "File:Dual pulse.png"

File:Dual pulse.png

2014-03-28T17:08:54Z

Karlito139:

File:Dual linear servos.jpg

2014-03-28T17:00:48Z

Karlito139:

Airframe Configuration

2014-03-13T12:59:31Z

Karlito139: /* Servos */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
== About ==
The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.

The XML airframe configuration file is located in <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="yourairframe">

</airframe>
</source>}}

Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].

== Creating a new Aircraft ==
While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:
* Airframe (what this page is about)
* [[Flight_Plans|Flight Plan]]
* [[Settings]]
* [[Radio_Control|Radio]] (if you use a PPM based R/C system)
* [[Telemetry]]
Each aircraft is assigned a name, unique ID and the associated configuration files in [[Conf.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).

== Firmware and Hardware definitions ==
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
</firmware>
</source>
}}
=== Select your Board ===
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.
The ''name'' attribute is either "ap" (autopilot) or "sim" (simulation).

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
<target name="sim" board="pc"/> 
<target name="ap" board="lisa_m_1.0"/> 
...
</firmware>
</source>
}}

==== Simulation targets ====
target name="sim","jsbsim","nps" 
board="pc" 

More Information at [[Simulation]].

==== Board targets ====
target name="ap" 
board=
"apogee_0.99",
"apogee_1.0",
"ardrone2_raw",
"ardrone2_sdk",
"booz_1.0",
"classix",
"hb_1.1",
"krooz_sd",
"lisa_l_1.0",
"lisa_l_1.1",
"lisa_m_1.0",
"lisa_m_2.0",
"logom_2.6",
"navgo_1.0",
"sdlog_1.0",
"stm32f4_discovery",
"tiny_0.99",
"tiny_1.1",
"tiny_2.1",
"tiny_2.11",
"twog_1.0",
"umarim_1.0",
"umarim_lite_2.0",
"yapa_2.0",

==== Direct Makefile ====
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section. This is only needed in very advanced setups. For example when testing newly developed hardware.

=== LEDs ===
You can configure the LEDs on the autopilot to be used for different status indicators:
; ''SYS_TIME_LED'': blinks with 1Hz
; ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; ''RADIO_CONTROL_LED'': on if RC signal is ok
; ''BARO_LED'' : only on booz and navgo boards: blinks until baro offset is initialized and then stays on

Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board page for the defaults.
Use a configure node in the firmware section to assign an indicator to a LED number or disable that with ''none'':
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<configure name="SYS_TIME_LED" value="1"/>
<configure name="RADIO_CONTROL_LED" value="2"/>
<configure name="GPS_LED" value="none"/>
</firmware>
</source>
}}
Beware that you can only assign '''one''' indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to ''none''.

== Subsystems ==

Each autopilot features certain [[Subsystems|subsystems]] which need to be configured properly.
The most important ones are described below.

=== IMU ===
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="imu" type="aspirin_v1.5"/>
</firmware>
</source>
}}

See the [[Subsystem/imu|imu subsystem]] page for more details.
Also see the [[ImuCalibration|IMU calibration]] page.

=== AHRS ===
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>
</source>
}}
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.

If the magnetometer should be used the [[Subsystem/ahrs#Local_Magnetic_Field|local magnetic field section]] must be filled in.

=== Radio Control ===

Supported types are:
* ''ppm''
* ''spektrum''
* ''datalink''

Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm"/>
</firmware>
</source>
}}

=== Telemetry (Modem) ===
The modem protocol and baud rate must be set in both the airframe file and ground station. Any standard baud rate can be used, with 9600 being adequate and 57600 recommended for most users to allow high speed telemetry for more detailed flight data analysis. The actual data rate is determined by the number of messages being sent and the period of each message as defined in your [[Telemetry|telemetry file]], e.g. <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

The [[Subsystem/telemetry|telemetry subsystem]] supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.

Just specify the appropriate [[Subsystem/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.

'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="telemetry" type="transparent"/>
</firmware>
</source>
}}

=== GPS ===
The serial port settings must match that of the GPS and are configured here along with the necessary files to interpret the u-blox UBX binary protocol:

Just specify the appropriate [[Subsystem/gps|gps subsystem]] in your firmware section. You can currently choose between the types '''ublox''' and '''ublox_utm''' for the older series 4 modules which still provide a UTM message.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="gps" type="ublox"/>
</firmware>
</source>
}}

The correct UART is already defined by default according to your board.
The default GPS baudrate is 38400baud.

If you need to set different baud rates or UART see the [[Subsystem/gps]] page for the options.

'''Note:'''
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

== XML Parameters ==
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''

=== Commands ===

The <tt>commands</tt> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:
<source lang="xml">
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands>
</source>
For rotorcraft, it is usually:
<source lang="xml">
<commands>
<axis name="PITCH" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="YAW" failsafe_value="0"/>
<axis name="THRUST" failsafe_value="0"/>
</commands>
</source>

Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board. The range of these values is [-9600:9600]. For <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <tt>servo</tt> definition the <tt>neutral</tt> and <tt>min</tt> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <tt>servos</tt> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <tt>servos</tt> section:
<source lang="xml">
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos>
</source>
Names are associated to the corresponding '''real physical connector''' to which a servo is connected '''on the autopilot board'''. For example no="2" means connector two on the board. Also the servo neutral value, total range and direction are defined. Min/max/neutral values are expressed in microseconds. The direction of travel can be reversed by exchanging min with max (as in <tt>"ELEVON_LEFTSIDE"</tt>, above). The ''standard'' travel for a hobby servo is 1000µs - 2000µs with a 1500µs neutral. Trim can be added by changing this neutral value. Absolute servo travel limits can be increased or reduced with the min/max values. The <tt>"THROTTLE"</tt> servo typically has the same value for the <tt>neutral</tt> and <tt>min</tt>.

The attribute <tt>driver</tt> for <tt>servos</tt> node tells which actuators' driver is associated to the listed servos. After the version '''v4.9_devel-164-gdb0d004''', multiple servos sections can be defined and used together, if the correct [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <tt>driver</tt> attribute is specified.

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000µs range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with zero (0) not with one
* Servos are also known under the synonym actuators
* (after version '''v4.9_devel-164-gdb0d004''') For I2C based motor speed control using the [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:
** min: command to stop the motor
** neutral: motor idle command
** max: max thrust command

The <tt>servos</tt> are then linked to the commands in the <tt>command_laws</tt> section:
<source lang="xml">
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws>
</source>

[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]
where the third line is the simplest: the throttle servo value equals throttle command value. The other lines define and control the pitch/roll mixing. Elevon values are computed with a combination of two commands, '''ROLL''' and '''PITCH'''. This ''mixer'' is defined with two intermediate variables '''aileron''' and '''elevator''' introduced with the <tt>let</tt> element. The '''@''' symbol is used to reference a command value in the <tt>value</tt> attribute of the <tt>set</tt> and <tt>let</tt> elements. In the above example, the servos are limited to +/- 70% of their full travel for pitch and 30% for roll, only in combination can the servos reach 100% deflection. Note that these numbers ''should add up 100% or more, never less''. For example, you may want 100% travel available for pitch - this means if a roll is commanded along with maximum pitch only one servo will respond to the roll command as the other has already reached its mechanical limit. If you find after tuning that these numbers add to less than 100% consider reducing the surface travel mechanically.

Note that the signs used in the description follow the standard convention.

After '''v4.9_devel-164-gdb0d004''', the <tt>command_laws</tt> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===
This section gives characteristics for monitoring the main power battery.

<tt>MILLIAMP_AT_FULL_THROTTLE</tt> represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. <tt>MILLIAMP_AT_FULL_THROTTLE</tt> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the <tt>MILLIAMP_AT_FULL_THROTTLE</tt> value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).

The <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as decribed above for <tt>MILLIAMP_AT_FULL_THROTTLE</tt>, but only partial throttle (cruise throttle) should be applied in flight.

If both <tt>MILLIAMP_AT_FULL_THROTTLE</tt> and <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> are tweaked well, you get precise energy estimations with less than 5% error independant of your flight pattern without even requiring a [[Current_sensor|current sensor]].

The <tt>CATASTROPHIC_BAT_LEVEL</tt> (was previously <tt>LOW_BATTERY</tt>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <tt>CRITIC</tt> and <tt>LOW</tt> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.

The <tt>MAX_BAT_LEVEL</tt> may be specified to improve the display of the battery gauge in the strip or in "papgets". Note that this definition is optional, with a default value of 12.5V.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</source>
}}

The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the <tt>VoltageOfAdc(adc)</tt> define and also specify offsets or anything else you might need, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
...
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/>
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/>
</section>
</source>
}}

=== Modules ===
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

<source lang="xml">
<modules main_freq="60">
<load name="demo_module.xml"/>
</modules>
</source>

* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz

=== GCS ===
Use this optional section to help customize parts of the GCS for a specific airframe:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="GCS">
...
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/>
<define name="ALT_SHIFT_PLUS" value="5"/>
<define name="ALT_SHIFT_MINUS" value="-5"/>
<define name="SPEECH_NAME" value="Quad"/>
<define name="AC_ICON" value="flyingwing"/>
</section>
</source>
}}
[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").
* <tt>AC_ICON</tt> can be used to define the vehicle icon (or overwrite the default icon) that shows up on the 2D-map of the GCS. Available values are: <tt>flyingwing</tt> , <tt>fixedwing</tt> , <tt>rotorcraft</tt> , <tt>home</tt>.

[[Category:User_Documentation]] [[Category:Airframe_Configuration]]

Airframe Configuration

2014-03-13T12:58:32Z

Karlito139: /* Servos */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Airframe_Configuration</categorytree>
== About ==
The airframe file is the most important configuration file and contains all the hardware and software settings for your airframe. It describes what hardware you have and which firmware, sensors, algorithms, etc. you want to use and also holds your configuration parameters. All gains, trims, and behavior settings are defined with standard XML elements.

The XML airframe configuration file is located in <tt>conf/airframes/<yourairframe>.xml</tt> and always begins with a <!DOCTYPE airframe SYSTEM "airframe.dtd"> line and should look like this
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<!DOCTYPE airframe SYSTEM "airframe.dtd">
<airframe name="yourairframe">

</airframe>
</source>}}

Also see the wiki pages for [[Fixedwing_Configuration|fixedwing specific configuration]] and [[Rotorcraft_Configuration|rotorcraft specific configuration]].

== Creating a new Aircraft ==
While the airframe file is where you configure most aspects of your aircraft, a fully specified aircraft needs several XML configuration files:
* Airframe (what this page is about)
* [[Flight_Plans|Flight Plan]]
* [[Settings]]
* [[Radio_Control|Radio]] (if you use a PPM based R/C system)
* [[Telemetry]]
Each aircraft is assigned a name, unique ID and the associated configuration files in [[Conf.xml|<tt>conf/conf.xml</tt>]]. To create a new Aircraft, click new in the menu A/C in the [[Paparazzi_Center|Paparazzi Center]] and select your new airframe file, etc. (or specify it by hand in [[Conf.xml|<tt>conf/conf.xml</tt>]]).

== Firmware and Hardware definitions ==
First you should specify which firmware you want to use, that is if you have a <tt>[[Fixedwing_Configuration|fixedwing]]</tt> aircraft or a <tt>[[Rotorcraft_Configuration|rotorcraft]]</tt>:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
</firmware>
</source>
}}
=== Select your Board ===
To specify autopilot hardware you are using and it's low-level settings you have to add a ''target''-tag.
Each ''target'' has two attributes, which are ''name'' and a corresponding ''board'' attribute.
The ''name'' attribute is either "ap" (autopilot) or "sim" (simulation).

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
<target name="sim" board="pc"/> 
<target name="ap" board="lisa_m_1.0"/> 
...
</firmware>
</source>
}}

==== Simulation targets ====
target name="sim","jsbsim","nps" 
board="pc" 

More Information at [[Simulation]].

==== Board targets ====
target name="ap" 
board=
"apogee_0.99",
"apogee_1.0",
"ardrone2_raw",
"ardrone2_sdk",
"booz_1.0",
"classix",
"hb_1.1",
"krooz_sd",
"lisa_l_1.0",
"lisa_l_1.1",
"lisa_m_1.0",
"lisa_m_2.0",
"logom_2.6",
"navgo_1.0",
"sdlog_1.0",
"stm32f4_discovery",
"tiny_0.99",
"tiny_1.1",
"tiny_2.1",
"tiny_2.11",
"twog_1.0",
"umarim_1.0",
"umarim_lite_2.0",
"yapa_2.0",

==== Direct Makefile ====
Optionally you can also add a raw [http://en.wikipedia.org/wiki/Makefile Makefile] section. This is only needed in very advanced setups. For example when testing newly developed hardware.

=== LEDs ===
You can configure the LEDs on the autopilot to be used for different status indicators:
; ''SYS_TIME_LED'': blinks with 1Hz
; ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; ''RADIO_CONTROL_LED'': on if RC signal is ok
; ''BARO_LED'' : only on booz and navgo boards: blinks until baro offset is initialized and then stays on

Depending on your board some of the LEDs on it are already assigned to some indicators by default, check the appropriate autopilot board page for the defaults.
Use a configure node in the firmware section to assign an indicator to a LED number or disable that with ''none'':
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<configure name="SYS_TIME_LED" value="1"/>
<configure name="RADIO_CONTROL_LED" value="2"/>
<configure name="GPS_LED" value="none"/>
</firmware>
</source>
}}
Beware that you can only assign '''one''' indicator to a LED number. So if the LED you want to use is already in use because another indicator is set to that number by default you have to disable that other indicator by setting it to ''none''.

== Subsystems ==

Each autopilot features certain [[Subsystems|subsystems]] which need to be configured properly.
The most important ones are described below.

=== IMU ===
Add the [[Subsystem/imu|imu subsystem]] with the type you are using.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="imu" type="aspirin_v1.5"/>
</firmware>
</source>
}}

See the [[Subsystem/imu|imu subsystem]] page for more details.
Also see the [[ImuCalibration|IMU calibration]] page.

=== AHRS ===
The [[Subsystem/ahrs|AHRS subsystem]] specifies which attitude estimation filter you are using, e.g. for the complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>
</source>
}}
All AHRS algorithms depend on an imu subsystem, except for the ahrs_infrared which depends on the infrared module.
See the [[Subsystem/ahrs|AHRS subsystem page]] for more details.

If the magnetometer should be used the [[Subsystem/ahrs#Local_Magnetic_Field|local magnetic field section]] must be filled in.

=== Radio Control ===

Supported types are:
* ''ppm''
* ''spektrum''
* ''datalink''

Just specify the appropriate [[Subsystem/radio_control|radio control subsystem]] in your firmware section, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="radio_control" type="ppm"/>
</firmware>
</source>
}}

=== Telemetry (Modem) ===
The modem protocol and baud rate must be set in both the airframe file and ground station. Any standard baud rate can be used, with 9600 being adequate and 57600 recommended for most users to allow high speed telemetry for more detailed flight data analysis. The actual data rate is determined by the number of messages being sent and the period of each message as defined in your [[Telemetry|telemetry file]], e.g. <tt>conf/telemetry/default.xml</tt>. Those wishing to experiment with "alternative" modems can reduce the number and period of each telemetry message to fit within most any bandwidth constraint.

The [[Subsystem/telemetry|telemetry subsystem]] supports the following modem protocols:
* Standard transparent serial (pprz) - this is compatible with all modems and can be used to connect the autopilot directly to a PC for testing without a modem.
* Maxstream API protocol (xbee) - compatible with all Maxstream modems including the 9XTend and Zigbee. This protocol enables hardware addressing, allowing multiple aircraft to be managed from a single ground modem.

Just specify the appropriate [[Subsystem/telemetry|telemetry subsystem]] in your firmware section. You can currently choose between the types ''transparent'', ''transparent_usb'' and ''xbee_api''.

'''The default baudrate is 57600 baud, see the [[Subsystem/telemetry|telemetry subsystem]] page for more details and configuration options.'''
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="telemetry" type="transparent"/>
</firmware>
</source>
}}

=== GPS ===
The serial port settings must match that of the GPS and are configured here along with the necessary files to interpret the u-blox UBX binary protocol:

Just specify the appropriate [[Subsystem/gps|gps subsystem]] in your firmware section. You can currently choose between the types '''ublox''' and '''ublox_utm''' for the older series 4 modules which still provide a UTM message.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="gps" type="ublox"/>
</firmware>
</source>
}}

The correct UART is already defined by default according to your board.
The default GPS baudrate is 38400baud.

If you need to set different baud rates or UART see the [[Subsystem/gps]] page for the options.

'''Note:'''
* u-blox GPS modules are factory configured for 9600 baud, 38,400 baud is recommended along with the other required changes. The GPS can be accessed directly through the [[tunnel|UART Tunnel]] and [[GPS#GPS_configuration_using_U-Center|Configured with u-center]]

== XML Parameters ==
'''When defining parameters you can use [[Units|automatic unit conversion]] to conveniently set it in e.g. degrees.'''

=== Commands ===

The <tt>commands</tt> lists the abstract commands you need to control the aircraft. In a simple fixed-wing example, we have only three:
<source lang="xml">
<commands>
<axis name="THROTTLE" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="PITCH" failsafe_value="0"/>
</commands>
</source>
For rotorcraft, it is usually:
<source lang="xml">
<commands>
<axis name="PITCH" failsafe_value="0"/>
<axis name="ROLL" failsafe_value="0"/>
<axis name="YAW" failsafe_value="0"/>
<axis name="THRUST" failsafe_value="0"/>
</commands>
</source>

Each command is also associated with a failsafe value which will be used if no controller is active, for example during initialization of the autopilot board. The range of these values is [-9600:9600]. For <tt>"THROTTLE"</tt>, the range is [0, 9600] and in the corresponding <tt>servo</tt> definition the <tt>neutral</tt> and <tt>min</tt> are usually the same for PWM based servos (see below). Note that these commands do not necessarily match the servo actuators. For example, the <tt>"ROLL"</tt> command is typically linked to two aileron actuators.

=== Servos ===

The above commands get translated to the <tt>servos</tt> here. In the example below we use two elevons and a motor. ([http://en.wikipedia.org/wiki/Elevon ''Elevons''] are surfaces used for both pitch and roll as on a flying wing.) These servos are listed in the <tt>servos</tt> section:
<source lang="xml">
<servos>
<servo name="THROTTLE" no="0" min="1000" neutral="1000" max="2000"/>
<servo name="ELEVON_LEFTSIDE" no="1" min="2000" neutral="1500" max="1000"/>
<servo name="ELEVON_RIGHTSIDE" no="2" min="1000" neutral="1500" max="2000"/>
</servos>
</source>
Names are associated to the corresponding '''real physical connector''' to which a servo is connected '''on the autopilot board'''. For example no="2" means connector two on the board. Also the servo neutral value, total range and direction are defined. Min/max/neutral values are expressed in microseconds. The direction of travel can be reversed by exchanging min with max (as in <tt>"ELEVON_LEFTSIDE"</tt>, above). The ''standard'' travel for a hobby servo is 1000µs - 2000µs with a 1500µs neutral. Trim can be added by changing this neutral value. Absolute servo travel limits can be increased or reduced with the min/max values. The <tt>"THROTTLE"</tt> servo typically has the same value for the <tt>neutral</tt> and <tt>min</tt>.

The attribute <tt>driver</tt> for <tt>servos</tt> node tells which actuators' driver is associated the the listed servos. After the version '''v4.9_devel-164-gdb0d004''', multiple servos sections can be defined and used together, if the correct [[Subsystem/actuators| actuators subsystems]] are loaded. Some boards are automatically loading a default driver, the one used when no <tt>driver</tt> attribute is specified.

Note the following important tips:
* Reverse the servo direction by exchanging min/max
* Trim should always be adjusted mechanically if possible to avoid asymmetrical travel
* Any reduction of the total travel range should be done mechanically to maintain precision
* Many servos will respond well to values slightly outside the normal 1000-2000µs range but experiment carefully as the servo may not operate reliably outside this range and may even suffer permanent damage.
* Board connector numbering starts with zero (0) not with one
* Servos are also known under the synonym actuators
* (after version '''v4.9_devel-164-gdb0d004''') For I2C based motor speed control using the [[Rotorcraft_Configuration#Motor_Mixing|motor mixing]]:
** min: command to stop the motor
** neutral: motor idle command
** max: max thrust command

The <tt>servos</tt> are then linked to the commands in the <tt>command_laws</tt> section:
<source lang="xml">
<command_laws>
<let var="aileron" value="@ROLL * 0.3"/>
<let var="elevator" value="@PITCH * 0.7"/>
<set servo="THROTTLE" value="@THROTTLE"/>
<set servo="ELEVON_LEFTSIDE" value="$elevator + $aileron"/>
<set servo="ELEVON_RIGHTSIDE" value="$elevator - $aileron"/>
</command_laws>
</source>

[[Image:airframe_sign_conventions.jpg|thumb|Sign conventions for flight dynamics]]
where the third line is the simplest: the throttle servo value equals throttle command value. The other lines define and control the pitch/roll mixing. Elevon values are computed with a combination of two commands, '''ROLL''' and '''PITCH'''. This ''mixer'' is defined with two intermediate variables '''aileron''' and '''elevator''' introduced with the <tt>let</tt> element. The '''@''' symbol is used to reference a command value in the <tt>value</tt> attribute of the <tt>set</tt> and <tt>let</tt> elements. In the above example, the servos are limited to +/- 70% of their full travel for pitch and 30% for roll, only in combination can the servos reach 100% deflection. Note that these numbers ''should add up 100% or more, never less''. For example, you may want 100% travel available for pitch - this means if a roll is commanded along with maximum pitch only one servo will respond to the roll command as the other has already reached its mechanical limit. If you find after tuning that these numbers add to less than 100% consider reducing the surface travel mechanically.

Note that the signs used in the description follow the standard convention.

After '''v4.9_devel-164-gdb0d004''', the <tt>command_laws</tt> section is mandatory for both fixedwing and rotorcraft firmwares, only for fixedwing otherwise.

=== Battery ===
This section gives characteristics for monitoring the main power battery.

<tt>MILLIAMP_AT_FULL_THROTTLE</tt> represents the actual current (in mA) when full THROTTLE is applied. Note that when flying the current typically is significantly lower than in static tests at home on your workbench. <tt>MILLIAMP_AT_FULL_THROTTLE</tt> is used to compute the <tt>energy</tt> value of the <tt>BAT</tt> message when no [[Current_sensor|Current sensor]] is mounted in the airframe. This value can also be used in flight plans. For example, if at full throttle your motor consumes 10 Amps, use a value of 10000. You can "tweak" this number after a few flights to match the capacity of your battery. If upon landing your bat.energy messages says that you used 2500 mAh while the energy recharged into the battery is only 2000 mAh, you could reduce the <tt>MILLIAMP_AT_FULL_THROTTLE</tt> value by 20% to match your in-flight current consumption. This tweaking is most precise if you fly full throttle only (respectively no throttle to glide down again).

The <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> can be added to tweak the energy estimation for non full throttle cruise. As the current consumption is nonlinear, at 50% throttle it is likely to be substantially less than 50%. A superellipse is used to approximate this nonlinearity. The default setting is 1.2 and is used if the <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> is not defined in your airframe file. A value 1 corresponds to linear behaviour, 1.5 corresponds to strong nonlinearity. The tweaking is done same as decribed above for <tt>MILLIAMP_AT_FULL_THROTTLE</tt>, but only partial throttle (cruise throttle) should be applied in flight.

If both <tt>MILLIAMP_AT_FULL_THROTTLE</tt> and <tt>CURRENT_ESTIMATION_NONLINEARITY</tt> are tweaked well, you get precise energy estimations with less than 5% error independant of your flight pattern without even requiring a [[Current_sensor|current sensor]].

The <tt>CATASTROPHIC_BAT_LEVEL</tt> (was previously <tt>LOW_BATTERY</tt>) value defines the voltage at which the autopilot will lock the throttle at 0% in autonomous mode (kill_throttle mode). This value is also used by the ground server to issue a '''CATASTROPHIC''' alarm message on the bus (this message will be displayed in the console of the GCS). <tt>CRITIC</tt> and <tt>LOW</tt> values will also used as threshold for '''CRITIC''' and '''WARNING''' alarms. They are optional and the respective defaults are 10.0 and 10.5V.

The <tt>MAX_BAT_LEVEL</tt> may be specified to improve the display of the battery gauge in the strip or in "papgets". Note that this definition is optional, with a default value of 12.5V.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
<define name="MILLIAMP_AT_FULL_THROTTLE" value="12000" unit="mA" />
<define name="CATASTROPHIC_BAT_LEVEL" value="6.0" unit="V"/>
<define name="CRITIC_BAT_LEVEL" value="6.5" unit="V"/>
<define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
<define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
</source>
}}

The conversion of ADC measurements to Voltage is already defined for the different autopilot boards, if you need to override these defaults you can use the <tt>VoltageOfAdc(adc)</tt> define and also specify offsets or anything else you might need, e.g.:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="BAT">
...
<define name="VOLTAGE_ADC_SCALE" value="0.0177531"/>
<define name="VOLTAGE_OFFSET" value="0.5" unit="V"/>
<define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_SCALE * adc + VOLTAGE_OFFSET)"/>
</section>
</source>
}}

=== Modules ===
The [[Modules|modules]] allow to add new code in a flexible way with initialisation, periodic and event functions without modifying the main AP loop.

<source lang="xml">
<modules main_freq="60">
<load name="demo_module.xml"/>
</modules>
</source>

* The main_freq parameter (in Hz) allows to specify the frequency of the main loop. Default is 60 Hz

=== GCS ===
Use this optional section to help customize parts of the GCS for a specific airframe:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="GCS">
...
<define name="ALT_SHIFT_PLUS_PLUS" value="30"/>
<define name="ALT_SHIFT_PLUS" value="5"/>
<define name="ALT_SHIFT_MINUS" value="-5"/>
<define name="SPEECH_NAME" value="Quad"/>
<define name="AC_ICON" value="flyingwing"/>
</section>
</source>
}}
[[Image:ac_icon_multi_uav.png|thumb|Various A/C icons demonstrated on a multi UAV simulation session]]

* <tt>ALT_SHIFT_PLUS_PLUS</tt> sets the number of metres the target altitude will change when the double up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_PLUS</tt> sets the number of metres the target altitude will change when the up arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>ALT_SHIFT_MINUS</tt> sets the number of metres the target altitude will change when the down arrow button is pressed on the [[GCS#Strips|strip]]
* <tt>SPEECH_NAME</tt> a string ([a-zA-Z0-9_]) that will be used in place of the aircraft name specified in <tt>conf.xml</tt> for the [[Speech|speech]] and [[GCS#Alarms|alarms]] functionality. Set this to "_" to prevent the speech function from saying the aircraft name. Useful if your aircraft name takes a long time to say (i.e. "UAV1-A_with_spektrum" can be shortened to "Plane").
* <tt>AC_ICON</tt> can be used to define the vehicle icon (or overwrite the default icon) that shows up on the 2D-map of the GCS. Available values are: <tt>flyingwing</tt> , <tt>fixedwing</tt> , <tt>rotorcraft</tt> , <tt>home</tt>.

[[Category:User_Documentation]] [[Category:Airframe_Configuration]]

File:Edit airframe.png

2014-03-11T10:12:06Z

Karlito139: Karlito139 uploaded a new version of "File:Edit airframe.png"

Indication about the location of the edit button of the airframe into the paparazzi GUI.

File:Edit airframe.png

2014-03-11T10:09:51Z

Karlito139: Indication about the location of the edit button of the airframe into the paparazzi GUI.

Indication about the location of the edit button of the airframe into the paparazzi GUI.

GPSd position

2014-03-07T17:11:02Z

Karlito139: /* Installing gpsd2ivy */

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree>
__TOC__

== Display a GPS position ==

Sometimes it is useful to display an external GPS position on the GCS. That might be your ground station position (e.g. if operating from a moving ship) or you walking through the field with your laptop searching an outlanded aircraft.

The external gps position will be displayed through a dark red dot surrounded by a black circle. If the gps data is lost/older than 10s the red dot will get a light red circle.

[[Image:Gpsd_pos_ok.png|left|thumb|GPSd position ok]]

[[Image:Gpsd_pos_lost.png|left|thumb|GPSd position is lost]]

 

=== Using gpsd ===

The GPS receiver could be connected through a serial port, USB, Bluetooth, a network, ... The gpsd package is used to interface to the receiver. On some Linux distributions the gpsd daemon is started automatically by default (e.g. Ubuntu 9.10) and might confuse the modem operation that also uses the serial/USB port. It is a good idea to disable the automatic startup of gpsd or at least change the configuration to only access one given port as described below. It can be turned off by running

If gpsd is not installed, install it via:

$ sudo apt-get install libgps-dev gpsd

Then configure it via:

$ sudo dpkg-reconfigure gpsd

There are several ways to tell gpsd how to connect to your receiver. The simplest is to start gpsd (as root) with the device you want.

sudo gpsd /dev/ttyUSB0

If your GPS receiver is always connected to the same port (and can not be confused with another Paparazzi modem) you can put the device into '''/etc/default/gpsd''' and start gpsd automatically. There should be a way that udev takes care of that.

START_DAEMON="true"
DAEMON_OPTS=""
DEVICES="/dev/ttyS2"
USBAUTO="false"and start it through the '''GPSd position display''' in the Paparazzi Center Tools bar or by hand

A Bluetooth GPS receiver can be configured in '''/etc/bluetooth/rfcomm.conf'''. In this example it can be used as '''/dev/rfcomm0''' (put your GPS devices Bluetooth address).

rfcomm0 {
bind yes;
device 00:06:66:00:53:AE;
}

On some Linux distributions it is needed to bind the rfcomm

sudo rfcomm bind 0

=== Installing gpsd2ivy ===

The small tool that gets the position info from gpsd and forwards that to the ivy bus so that the gcs can display it is called gpsd2ivy. It can be started through the '''GPSd position display''' in the Paparazzi Center Tools bar.

Install the needed gps libraries:
sudo apt-get install libgps-dev gpsd
or
sudo apt-get install --install-suggests paparazzi-dev

Then compile gpsd2ivy via:

cd sw/ground_segment/tmtc
make gpsd2ivy

manually it is started by

./gpsd2ivy

=== Using gpsd2ivy ===
It seams that you need to get first the location of your drone before having the one of your ground station. You might want to restart the gpsd2ivy program in order to force the calculation of a new position of your ground station (will staying in GCS).

[[Category:Tools]] [[Category:User_Documentation]]

GPSd position

2014-03-07T17:10:46Z

Karlito139:

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree>
__TOC__

== Display a GPS position ==

Sometimes it is useful to display an external GPS position on the GCS. That might be your ground station position (e.g. if operating from a moving ship) or you walking through the field with your laptop searching an outlanded aircraft.

The external gps position will be displayed through a dark red dot surrounded by a black circle. If the gps data is lost/older than 10s the red dot will get a light red circle.

[[Image:Gpsd_pos_ok.png|left|thumb|GPSd position ok]]

[[Image:Gpsd_pos_lost.png|left|thumb|GPSd position is lost]]

 

=== Using gpsd ===

The GPS receiver could be connected through a serial port, USB, Bluetooth, a network, ... The gpsd package is used to interface to the receiver. On some Linux distributions the gpsd daemon is started automatically by default (e.g. Ubuntu 9.10) and might confuse the modem operation that also uses the serial/USB port. It is a good idea to disable the automatic startup of gpsd or at least change the configuration to only access one given port as described below. It can be turned off by running

If gpsd is not installed, install it via:

$ sudo apt-get install libgps-dev gpsd

Then configure it via:

$ sudo dpkg-reconfigure gpsd

There are several ways to tell gpsd how to connect to your receiver. The simplest is to start gpsd (as root) with the device you want.

sudo gpsd /dev/ttyUSB0

If your GPS receiver is always connected to the same port (and can not be confused with another Paparazzi modem) you can put the device into '''/etc/default/gpsd''' and start gpsd automatically. There should be a way that udev takes care of that.

START_DAEMON="true"
DAEMON_OPTS=""
DEVICES="/dev/ttyS2"
USBAUTO="false"and start it through the '''GPSd position display''' in the Paparazzi Center Tools bar or by hand

A Bluetooth GPS receiver can be configured in '''/etc/bluetooth/rfcomm.conf'''. In this example it can be used as '''/dev/rfcomm0''' (put your GPS devices Bluetooth address).

rfcomm0 {
bind yes;
device 00:06:66:00:53:AE;
}

On some Linux distributions it is needed to bind the rfcomm

sudo rfcomm bind 0

=== Installing gpsd2ivy ===

The small tool that gets the position info from gpsd and forwards that to the ivy bus so that the gcs can display it is called gpsd2ivy. It can be started through the '''GPSd position display''' in the Paparazzi Center Tools bar.

Install the needed gps libraries:
sudo apt-get install libgps-dev gpsd
or
sudo apt-get install --install-suggests paparazzi-dev

Then compile gpsd2ivy via:

cd sw/ground_segment/tmtc
make gpsd2ivy

manually it is started by

./gpsd2ivy

=== Installing gpsd2ivy ===
It seams that you need to get first the location of your drone before having the one of your ground station. You might want to restart the gpsd2ivy program in order to force the calculation of a new position of your ground station (will staying in GCS).

[[Category:Tools]] [[Category:User_Documentation]]

GPSd position

2014-03-07T17:06:37Z

Karlito139: /* Using gpsd2ivy */

Contributing

2014-03-04T10:30:19Z

Karlito139: /* Software development */

== How to contribute ==
There are of course lots of ways to contribute to Paparazzi and get involved.

Help is always welcome on all aspects of the project. May this be documentation, wiki, maintenance, electronics or code contributions/fixes.

=== Wiki ===
Just create an account and you can start adding information, cleaning it up or just fixing some typo you just noticed :-)

Some information and links on how to edit the wiki can be found at [[Help:Editing]].

Please be aware of past edits and page histories. Try not to remove this; if you are moving/renaming a page, use the '''move''' tab at the top of a page. This ensures the revision history is moved with the page.

=== Software development ===
We use the distributed version control system [http://git-scm.com/ git]. The [http://github.com/paparazzi/paparazzi/ Papaprazzi master repository is hosted on Github].

Also see the [[Git|Git wiki page]] for more details about setting up Git and cloning the source-code and data repository.

Please also have a look at the [http://docs.paparazziuav.org/latest/styleguide.html Coding Style Guide].

Here is the short version if you already know git:
# Create an account on [http://github.com/ github].
# Fork the [http://github.com/paparazzi/paparazzi/ papaprazzi repo] on github. (After logging in press the '''fork''' button).
# '''git clone git@github.com:<yourname>/paparazzi.git'''
# '''git remote add upstream https://github.com/paparazzi/paparazzi.git'''
# '''git fetch upstream'''
# checkout a new branch based on the development branch (master): '''git checkout -b my_new_feature upstream/master'''
# fix/code and commit in logical units
# push your feature/bugfix branch
# Send us a [http://help.github.com/pull-requests/ pull request] on github. (Or send patches to the mailing list).

=== Issue/Feature Tracker ===
To report bugs, issues and feature request please use either the mailing list or even better the simple [https://github.com/paparazzi/paparazzi/issues issue tracker on github]

=== Continuous Integration Builds ===
We have a [http://paparazzi.gondwana.com.au build server] running some [[Builds/Tests|CI tests]].

[[Category:Developer_Documentation]]