PaparazziUAV - User contributions [en]

Lisa/Bone

2014-04-15T00:57:15Z

Poine:

Lisa/Bone is a project consisting in designing a Paparazzi [http://beagleboard.org/Products/BeagleBone+Black Beaglebone Black] cape.

For now, this page is a placeholder for the definition of the board.

== MCU or not MCU ==

BeagleBone Black (BBB) has all the peripherals needed to make an autopilot (PWM, ADC, SPI, I2C, UARTS, Capture, etc...). The daughter board could just be a connectors, supply and aspirin carrier board. It would minimize cost and complexity, but we'd lose the possibility of segregating critical code. Discarded for that reason

I suggest a 64 pins STM F4 (like in Lisa/M)

We don't need level converters. BBB is happy with 3.3V IOs

My current plan is to base the cape on Lisa/M, rework supply and connectors.

Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith

Gautier says he wants UART communications:
can you justify and specify which UART of the F4 you'd use ?
My argument against it is that UARTs are a scarce resource on the F4 - SPI is easy on BBB, from userland using SPIdev ( [http://elinux.org/BeagleBone_Black_Enable_SPIDEV see here])
On F4, Lisa/L's SPI code can be reused. This code is well validated (or did it get broken by the change to libopencm?)

=> UART comminucation is still easier to use expecially for new-comers. It is also sufficient for high-level operations (controlling at navigation level) from the BB.
SPI code on MCU side has changed a lot since Lisa/L, I wouldn't bet it is still working.
I really don't care which UART is used.

== Connectors ==

Let's start from Lisa/M connectors. We have a little bit more space available
- I would like 10 full size servo connectors - supply bus isolated

== Supply ==

-If we're going for the code segregation thing, it makes sense to have two independent rails: one non-critical for BBB and one critical for F4

-I would like to be able to power the whole thing from 3/4S flight pack

-Should we go for the PTH8080 that were used on Lisa/L, a pair of them?

-Any idea for a good connector for input supply ? Or do we just skip that and go for beefy solder pads as usual?

-Beagle has the possibility to run on one lipo cell and has a chip capable of charging it from the 5V supply ( [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system see here] )
Should we implement something like this to allow changing the vehicle's battery pack without having to shutdown the autopilot (or switch from lab power supply to flight pack) ?
1400mAh give ~3h endurance and weights 25g, 500mAh is 10g
Discarded, Bryan says it doesn't work

== Misc ==

-We want a push button for triggering BBB shutdown - maybe with a molex to be able to mount a button in a convenient place when in airframe (P9-9 to ground [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2014/03/05/bbb--sonos-like-sound-system see here])

-If linux system is setup properly you will not have to shutdown the BB. You will be able to just pull power with no issues.

-Maybe one or two GPIO in order to have status leds next to the button?

-Do we want to be able to flash F4 from BBB?

== Communications ==

* BBB drives the xbee and tunnels communications to F4. Bad, we lose advantage of code segregation
* BBB and F4 each have a xbee. Bad, we increase weight and power consumption :)
* for short distances (rotorcraft), BBB through wifi(Bryan-wifi is not hard real time), F4 through wifi
* BBB communicates throught internet stick, BBB forwards data to F4
* BBB uses internet stick, F4 uses xbee -> redundant communication, interent stick could be used for image/video
* CAN has built in data framing and CRC with many-master-many-slave type data system.
Lisa/M (the F4 board) has one can driver. Do we want to add a second driver for the BBB?
== Use cases ==

Let's describe a couple of scenarios of what we would do with that board:

* I want to investigate autonomous soaring. F4 runs the current fixedwing code. BBB runs the autonomous soaring program written in Python/Numpy and talks to the navigation layer running on F4. BBB receives every sensor measurement, state estimation and actuators command from F4, for real time use and logging.

* Someone runs image processing on BBB (using a usb webcam?) and current rotorcraft code in F4 - similar to case 1

* OpenCV onboard for motion tracking and 2d ground tracking for extra stability systems

Does image processing require some kind of fancy camera with a fancy interface, or is USB good enough? BBB only has one USB... so webcam, or wifi, or hub..
Do we want a USB hub on the daughterboard - i would say no, keep it cheap and simple

* What else?

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

Lisa/Bone

2014-04-15T00:46:06Z

Poine:

Lisa/Bone is a project consisting in designing a Paparazzi [http://beagleboard.org/Products/BeagleBone+Black Beaglebone Black] cape.

For now, this page is a placeholder for the definition of the board.

== MCU or not MCU ==

BeagleBone Black (BBB) has all the peripherals needed to make an autopilot (PWM, ADC, SPI, I2C, UARTS, Capture, etc...). The daughter board could just be a connectors, supply and aspirin carrier board. It would minimize cost and complexity, but we'd lose the possibility of segregating critical code. Discarded for that reason

I suggest a 64 pins STM F4 (like in Lisa/M)

We don't need level converters. BBB is happy with 3.3V IOs

My current plan is to base the cape on Lisa/M, rework supply and connectors.

Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith

Gautier says he wants UART communications:
can you justify and specify which UART of the F4 you'd use ?
My argument against it is that UARTs are a scarce resource on the F4 - SPI is easy on BBB, from userland using SPIdev ( [http://elinux.org/BeagleBone_Black_Enable_SPIDEV see here])
On F4, Lisa/L's SPI code can be reused. This code is well validated (or did it get broken by the change to libopencm?)

=> UART comminucation is still easier to use expecially for new-comers. It is also sufficient for high-level operations (controlling at navigation level) from the BB.
SPI code on MCU side has changed a lot since Lisa/L, I wouldn't bet it is still working.
I really don't care which UART is used.

== Connectors ==

Let's start from Lisa/M connectors. We have a little bit more space available
- I would like 10 full size servo connectors - supply bus isolated

== Supply ==

-If we're going for the code segregation thing, it makes sense to have two independent rails: one non-critical for BBB and one critical for F4

-I would like to be able to power the whole thing from 3/4S flight pack

-Should we go for the PTH8080 that were used on Lisa/L, a pair of them?

-Any idea for a good connector for input supply ? Or do we just skip that and go for beefy solder pads as usual?

-Beagle has the possibility to run on one lipo cell and has a chip capable of charging it from the 5V supply ( [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system see here] )
Should we implement something like this to allow changing the vehicle's battery pack without having to shutdown the autopilot (or switch from lab power supply to flight pack) ?
1400mAh give ~3h endurance and weights 25g, 500mAh is 10g

== Misc ==

-We want a push button for triggering BBB shutdown - maybe with a molex to be able to mount a button in a convenient place when in airframe (P9-9 to ground [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2014/03/05/bbb--sonos-like-sound-system see here])

-If linux system is setup properly you will not have to shutdown the BB. You will be able to just pull power with no issues.

-Maybe one or two GPIO in order to have status leds next to the button?

-Do we want to be able to flash F4 from BBB?

== Communications ==

* BBB drives the xbee and tunnels communications to F4. Bad, we lose advantage of code segregation
* BBB and F4 each have a xbee. Bad, we increase weight and power consumption :)
* for short distances (rotorcraft), BBB through wifi(Bryan-wifi is not hard real time), F4 through wifi
* BBB communicates throught internet stick, BBB forwards data to F4
* BBB uses internet stick, F4 uses xbee -> redundant communication, interent stick could be used for image/video
* CAN has built in data framing and CRC with many-master-many-slave type data system.
Lisa/M (the F4 board) has one can driver. Do we want to add a second driver for the BBB?
== Use cases ==

Let's describe a couple of scenarios of what we would do with that board:

* I want to investigate autonomous soaring. F4 runs the current fixedwing code. BBB runs the autonomous soaring program written in Python/Numpy and talks to the navigation layer running on F4. BBB receives every sensor measurement, state estimation and actuators command from F4, for real time use and logging.

* Someone runs image processing on BBB (using a usb webcam?) and current rotorcraft code in F4 - similar to case 1

* OpenCV onboard for motion tracking and 2d ground tracking for extra stability systems

Does image processing require some kind of fancy camera with a fancy interface, or is USB good enough? BBB only has one USB... so webcam, or wifi, or hub..
Do we want a USB hub on the daughterboard - i would say no, keep it cheap and simple

* What else?

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

Lisa/Bone

2014-04-13T11:24:04Z

Poine:

Lisa/Bone is a project consisting in designing a Paparazzi [http://beagleboard.org/Products/BeagleBone+Black Beaglebone Black] cape.

For now, this page is a placeholder for the definition of the board.

== MCU or not MCU ==

BeagleBone Black (BBB) has all the peripherals needed to make an autopilot (PWM, ADC, SPI, I2C, UARTS, Capture, etc...). The daughter board could just be a connectors, supply and aspirin carrier board. It would minimize cost and complexity, but we'd lose the possibility of segregating critical code. Discarded for that reason

I suggest a 64 pins STM F4 (like in Lisa/M)

We don't need level converters. BBB is happy with 3.3V IOs

My current plan is to base the cape on Lisa/M, rework supply and connectors.

Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith

Gautier says he wants UART communications:
can you justify and specify which UART of the F4 you'd use ?
My argument against it is that UARTs are a scarce resource on the F4 - SPI is easy on BBB, from userland using SPIdev ( [http://elinux.org/BeagleBone_Black_Enable_SPIDEV see here])
On F4, Lisa/L's SPI code can be reused. This code is well validated (or did it get broken by the change to libopencm?)

== Connectors ==

Let's start from Lisa/M connectors. We have a little bit more space available
- I would like 10 full size servo connectors - supply bus isolated

== Supply ==

-If we're going for the code segregation thing, it makes sense to have two independent rails: one non-critical for BBB and one critical for F4

-I would like to be able to power the whole thing from 3/4S flight pack

-Should we go for the PTH8080 that were used on Lisa/L, a pair of them?

-Any idea for a good connector for input supply ? Or do we just skip that and go for beefy solder pads as usual?

-Beagle has the possibility to run on one lipo cell and has a chip capable of charging it from the 5V supply ( [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system see here] )
Should we implement something like this to allow changing the vehicle's battery pack without having to shutdown the autopilot (or switch from lab power supply to flight pack) ?
1400mAh give ~3h endurance and weights 25g, 500mAh is 10g

== Misc ==

-We want a push button for triggering BBB shutdown - maybe with a molex to be able to mount a button in a convenient place when in airframe (P9-9 to ground [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2014/03/05/bbb--sonos-like-sound-system see here])

-Maybe one or two GPIO in order to have status leds next to the button?

-Do we want to be able to flash F4 from BBB?

== Communications ==

* BBB drives the xbee and tunnels communications to F4. Bad, we lose advantage of code segregation
* BBB and F4 each have a xbee. Bad, we increase weight and power consumption :)
* for short distances (rotorcraft), BBB through wifi, F4 through wifi

== Use cases ==

Let's describe a couple of scenarios of what we would do with that board:

* I want to investigate autonomous soaring. F4 runs the current fixedwing code. BBB runs the autonomous soaring program written in Python/Numpy and talks to the navigation layer running on F4. BBB receives every sensor measurement, state estimation and actuators command from F4, for real time use and logging.

* Someone runs image processing on BBB (using a usb webcam?) and current rotorcraft code in F4 - similar to case 1

* What else?

Lisa/Bone

2014-04-13T11:09:35Z

Poine:

Lisa/Bone is a project consisting in designing a Paparazzi [http://beagleboard.org/Products/BeagleBone+Black Beaglebone Black] cape.

For now, this page is a placeholder for the definition of the board.

== MCU or not MCU ==

BeagleBone Black (BBB) has all the peripherals needed to make an autopilot (PWM, ADC, SPI, I2C, UARTS, Capture, etc...). The daughter board could just be a connectors, supply and aspirin carrier board. It would minimize cost and complexity, but we'd lose the possibility of segregating critical code. Discarded for that reason

I suggest a 64 pins STM F4 (like in Lisa/M)

We don't need level converters. BBB is happy with 3.3V IOs

My current plan is to base the cape on Lisa/M, rework supply and connectors.

Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith

Gautier says he wants UART communications:
can you justify and specify which UART of the F4 you'd use ?
My argument against it is that UARTs are a scarce resource on the F4 - SPI is easy on BBB, from userland using SPIdev ( [http://elinux.org/BeagleBone_Black_Enable_SPIDEV see here]) - on F4, Lisa/L's SPI code can be reused. This code is well validated

== Connectors ==

Let's start from Lisa/M connectors. We have a little bit more space available
- I would like 10 full size servo connectors - supply bus isolated

== Supply ==

-If we're going for the code segregation thing, it makes sense to have two independent rails: one non-critical for BBB and one critical for F4

-I would like to be able to power the whole thing from 3/4S flight pack

-Should we go for the PTH8080 that were used on Lisa/L, a pair of them?

-Any idea for a good connector for input supply ? Or do we just skip that and go for beefy solder pads as usual?

-Beagle has the possibility to run on one lipo cell and has a chip capable of charging it from the 5V supply ( [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system see here] )
Should we implement something like this to allow changing the vehicle's battery pack without having to shutdown the autopilot (or switch from lab power supply to flight pack) ?
1400mAh give ~3h endurance and weights 25g, 500mAh is 10g

== Misc ==

-We want a push button for triggering BBB shutdown - maybe with a molex to be able to mount a button in a convenient place when in airframe

-Maybe one or two GPIO in order to have status leds next to the button?

-Do we want to be able to flash F4 from BBB?

== Communications ==

* BBB drives the xbee and tunnels communications to F4. Bad, we lose advantage of code segregation
* BBB and F4 each have a xbee. Bad, we increase weight and power consumption :)
* for short distances (rotorcraft), BBB through wifi, F4 through wifi

== Use cases ==

Let's describe a couple of scenarios of what we would do with that board:

* I want to investigate autonomous soaring. F4 runs the current fixedwing code. BBB runs the autonomous soaring program written in Python/Numpy and talks to the navigation layer running on F4. BBB receives every sensor measurement, state estimation and actuators command from F4, for real time use and logging.

* Someone runs image processing on BBB (using a usb webcam?) and current rotorcraft code in F4 - similar to case 1

* What else?

Lisa/Bone

2014-04-13T10:55:20Z

Poine: Created page with "Lisa/Bone is a project consisting in designing a Paparazzi [http://beagleboard.org/Products/BeagleBone+Black Beaglebone Black] cape. For now, this page is a placeholder for t..."

DevGuide/Settings

2012-06-08T00:46:01Z

Poine:

'''Settings''' is the generic mechanism that allows to get/set the value of any variable of the embedded code.

==Overview==

===Problem Statement===
Given an embedded program in C, we want a way to set/get the value of any variable without having to write any ad-hoc code.
* The variable can be of any base type (e.g. uint16, int32, float) or a structured type (not implemented yet).
* The variable can be directly accessed (declared in a header) or used through a pair of accessors (e.g. SetVar/GetVar).
* Typically the variable is manipulated through a graphical user interface on the ground station.
* The graphical interface can manipulate the variable in a different unit (e.g. the embedded code uses a binary fixed point representation)

===Solution===
The solution used in Paparazzi consist in describing the variables in a high level xml file, which is then processed to generate embedded code and used by the graphical user interface to display the suitable controls.

[[File:settings_overview.png|frame|800px]]

==Persistent Settings==
===Problem Statement===

===Solution===

DevGuide/Settings

2012-06-08T00:38:38Z

Poine:

'''Settings''' is the generic mechanism that allows to get/set the value of any variable of the embedded code.

==Overview==

===Problem Statement===
Given an embedded program in C, we want a way to set/get the value of any variable without having to write any ad-hoc code.
* The variable can be of any base type (e.g. uint16, int32, float) or a structured type (not implemented yet).
* The variable can be directly accessed (declared in a header) or used through a pair of accessors (e.g. SetVar/GetVar).
* Typically the variable is manipulated through a graphical user interface on the ground station.
* The graphical interface can manipulate the variable in a different unit (e.g. the embedded code uses a binary fixed point representation)

===Solution===
The solution used in Paparazzi consist in describing the variables in a high level xml file, which is then processed to generate embedded code and used by the graphical user interface to display the suitable controls.

[[File:settings_overview.png|800px]]

==Persistent Settings==
===Problem Statement===

===Solution===

2011-04-15T09:37:58Z

Poine:

2011-01-28T23:39:33Z

Poine:

This page describe how to compute "mixing" for an arbitrary multirotors configuration.

[[Image:hexa_3D.png|800px]]

== Introduction ==

"Mixing" consist in converting rotational accelerations commands computed by the autopilot into throttle commands for each of the motor controllers.

Let us consider a vehicle comprising a set of <math>N</math> identical fixed pitch rotors <math>R_i, i \in[1:N]</math> located at coordinates <math>(X_i,Y_i, 0), i\in[1:N]</math> and spinning in the same plane in the direction <math>D_i, i\in[1:N], D_i\in[-1;1]</math> at a rotational speed <math>\omega_i, i\in[1:N]</math>.

Assuming a quasi hovering regime, the force produced by each rotor can be considered normal to the rotor plane and proportional to the square of its rotational speed. Expressed in body frame ( front, right, down ), this leads to
<math>
\overrightarrow{F}_{i}^{B} = \begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix}
</math>

Under the same assumption, the torque produced by each rotor can also be assumed to be in the same direction and proportional to the square of the rotational speed.

The moment produced by each rotor around the CG, expressed in body frame can then be writen

<math>
\overrightarrow{M}_{i}^{B} = \begin{pmatrix}X_i C_t \omega_i^2\\Y_i C_t \omega_i^2\\D_i C_m \omega_i^2\end{pmatrix}
</math>
Where <math>C_t</math> is a "thrust" coefficient and <math>Cd</math> is a "torque" coefficient. It has been measured experimentally that <math>\frac{Ct}{Cm} \approx 10</math> on a mikrokopter.

As a first approximation we can consider that the rotational speed of the propeller is proportional to the square root of the applied command <math>u_i</math>

<math>
\omega_i^2 = K u_i
</math>

This allows us to express the momentum produced by the set of rotors as

<math>
\overrightarrow{M}^{B} = \sum_{i} \overrightarrow{M}_{i}^{B} =
\begin{pmatrix}
K C_t \sum_{i} X_i u_i\\
K C_t \sum_{i} Y_i u_i\\
K C_m \sum_{i} D_i u_i
\end{pmatrix}
</math>

which can be rewriten as a matrix vector product

<math>
\overrightarrow{M}^{B} =
K C_t
\begin{pmatrix}
X_1&X_2&\ldots&X_n\\
Y_1&Y_2&\ldots&Y_n\\
\frac{C_m}{Ct}D_1&\frac{C_m}{Ct}D_2&\ldots&\frac{C_m}{Ct}D_n
\end{pmatrix}
\begin{pmatrix}
u_1\\
u_2\\
\vdots\\
u_n
\end{pmatrix}
</math>

<math>
\overrightarrow{M}^{B} = A \overrightarrow{U}
</math>

<math>A</math> is a <math>3*N</math> matrix describing the geometric positions of our rotors and <math>U</math> is the vector of throttle commands for our set of motor controllers.

In order to express the command applied to each power train as a function of the momentum we want to apply to our vehicle, we need to find <math>B</math>, a <math>N*3</math> matrix such as

<math>
\overrightarrow{U} = B \overrightarrow{M}^B
</math>

If <math>A</math> has rank 3, we know that such a matrix exists (yeah, we can't do 2 rotors or have all rotors aligned), and in this case, we have the relationship

<math>
AB = \mathcal{I}_3
</math>

We know that one solution of this equation is the Moore-Penrose pseudoinverse of <math>A</math>.
Furthermore, this solution is the one leading to the power train command vector having the smallest euclidian norm, which is interesting as it optimizes the repartion of our control effort across our power trains.

== Example ==

Let's consider the following H hexarotors configuration.

[[Image:hexa_h.png|200px]]

<math>
A =
\begin{pmatrix}
-0.35 &-0.35 &0 & 0 & 0.35 & 0.35 \\
0.17 &-0.17 &0.25&-0.25& 0.33 &-0.33 \\
-0.1 & 0.1 &0.1 &-0.1 &-0.1 & 0.1
\end{pmatrix}
</math>

The first two lines of the <math>A</math> matrix represent the coordinates of each rotor in the <math>X,Y</math> plan, and the third line the direction in which they spin.

<math>
B =
\begin{pmatrix}
- 0.714 & 0.241 & - 1.465 \\
- 0.714 & - 0.241 & 1.465 \\
0 & 0.929 & 2.441 \\
0 & - 0.929 & - 2.441 \\
0.714 & 0.687 & - 1.094 \\
0.714 & - 0.687 & 1.094
\end{pmatrix}
</math>

Normalizing <math>B</math> yelds
<math>
\tilde{B} =
\begin{pmatrix}
-75 & 25 & -154 \\
-75 & -25 & 154 \\
0 & 97 & 256 \\
0 & -97 & -256 \\
75 & 72 & -115 \\
75 & -72 & 115
\end{pmatrix}
</math>

which in turns yelds the following supervision section

2010-10-03T11:44:03Z

Poine:

Lisa

2010-10-03T11:43:29Z

Poine:

Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a design focusing on cost and simplicity.

=Lisa/L=

== Description ==

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

== Documentation ==

The documentation about Lisa/L has been split in two: You can have a look at the [[User/LisaL]] user manual or the [[Dev/LisaL]] developer manual or look at pictures on the [[LisaL_Gallery]] gallery page.

= Lisa/M =

== Description ==
Lisa/M is a 50*25mm single processor board, with 7 full size servo connectors. This board is about the size of a conventional RC receiver and features a footprint for an aspirin IMU and an affordable barometer. Intended usages range from a CAN servo driver to a full blown autopilot or a flybarless heli controller.

[[Image:lisa_m_top_small.png|360px]] [[Image:lisa_m_bot_small.png|360px]] [[Image:aspirin_small.png|360px]]

== Documentation ==
Lisa/M is only at the stage of prototype. Documentation will follow as soon as the board reaches production stage.

= Lisa/S =

Lisa/S is only a project at the moment. The focus for this design is size, weight and power consumption. The intent is to produce an autopilot suited for the smallest airframes.
For now just a CAD rendering to wet your appetite.
[[Image:lisa_s_cad.png|360px]]

Lisa

2010-09-29T18:51:41Z

Poine:

Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a design focusing on cost and simplicity.

=Lisa/L=

== Description ==

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

== Documentation ==

The documentation about Lisa/L has been split in two: You can have a look at the [[User/LisaL]] user manual or the [[Dev/LisaL]] developer manual or look at pictures on the [[LisaL_Gallery]] gallery page.

= Lisa/M =

== Description ==
Lisa/M is a 50*25mm single processor board, with 7 full size servo connectors. This board is about the size of a conventional RC receiver and features a footprint for an aspirin IMU and an affordable barometer. Intended usages range from a CAN servo driver to a full blown autopilot or a flybarless heli controller.

[[Image:lisa_m_top_small.png|360px]] [[Image:lisa_m_bot_small.png|360px]]

== Documentation ==
Lisa/M is only at the stage of prototype. Documentation will follow as soon as the board reaches production stage.

= Lisa/S =

Lisa/S is only a project at the moment. The focus for this design is size, weight and power consumption. The intent is to produce an autopilot suited for the smallest airframes.
For now just a CAD rendering to wet your appetite.
[[Image:lisa_s_cad.png|360px]]

Lisa

2010-09-29T10:42:50Z

Poine:

Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a designing focusing on cost and simplicity.

=Lisa/L=

== Description ==

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

== Documentation ==

The documentation about Lisa/L has been split in two: You can have a look at the [[User/LisaL]] user manual or the [[Dev/LisaL]] developer manual or look at pictures on the [[LisaL_Gallery]] gallery page.

= Lisa/M =

== Description ==
Lisa/M is a 50*25mm single processor board, with 7 full size servo connectors. This board is about the size of a conventional RC receiver and features a footprint for an aspirin IMU and an affordable barometer. Intended usages range from a CAN servo driver to a full blown autopilot or a flybarless heli controller.

[[Image:lisa_m_top_small.png|360px]] [[Image:lisa_m_bot_small.png|360px]]

== Documentation ==
Lisa/M is only at the stage of prototype. Documentation will follow as soon as the board reaches production stage.

= Lisa/S =

Lisa/S is only a project at the moment. The focus for this design is size, weight and power consumption. The intent is to produce an autopilot suited for the smallest airframes.
For now just a CAD rendering to wet your appetite.
[[Image:lisa_s_cad.png|360px]]

Lisa

2010-09-29T10:39:22Z

Poine:

Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a designing focusing on cost and simplicity.

=Lisa/L=

== Description ==

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

The documentation about Lisa/L has been split in two: You can have a look at the [[User/LisaL]] user manual or the [[Dev/LisaL]] developer manual or look at pictures on the [[LisaL_Gallery]] gallery page.

= Lisa/M =

Lisa/M is a 50*25mm single processor board, with 7 full size servo connectors. This board is about the size of a conventional RC receiver and features a footprint for an aspirin IMU and an affordable barometer. Intended usages range from a CAN servo driver to a full blown autopilot or a flybarless heli controller.

[[Image:lisa_m_top_small.png|360px]] [[Image:lisa_m_bot_small.png|360px]]

= Lisa/S =

Lisa/S is only a project at the moment. The focus for this design is size, weight and power consumption. The intent is to produce an autopilot suited for the smallest airframes.
For now just a CAD rendering to wet your appetite.
[[Image:lisa_s_cad.png|360px]]