PaparazziUAV - User contributions [en]

Lisa/Bone

2014-04-17T23:36:23Z

Teslatech:

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.
NeoFromMatrix: Maybe we could use a MCU with more IO and 0805 parts.
The cape should provide enough parts and 0805 is easier tosolder by hand.

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.

Looking into the UART on both the F4 and BBB are very fast. We can achieve over 3Mbps.

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

NeoFromMatrix: how about 0.1" headers ? They are easier to solder by hand and molex connectors cost a bit...

== 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
6S would be cool (for extreme fast models), this is also the limitaton for most cheap chargers

-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?
0.1" screw terminals, seperate input for the servos (these maybe need higher voltage and will need more power)

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

NeoFromMatrix: That would be nice.

== 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
* BBB to F4 SPI interconnect, for doing some things as userprocesss on BBB and realtime stuff on the F4
* 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..
Bryan: Cheap USB-webcam would be all we would need.

Do we want a USB hub on the daughterboard - i would say no, keep it cheap and simple
Bryan: We may be able to enable host mode on USB0 and get use of both USB0 and USB1 on the board.

* Run code, used for research topics (maybe generated from Matlab/Simulink) on the BBB and let the F4 fly the plane and do the basic (realtime) stuff

* What else?

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

Lisa/Bone

2014-04-15T01:21:50Z

Teslatech:

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..
Bryan: Cheap USB-webcam would be all we would need.

Do we want a USB hub on the daughterboard - i would say no, keep it cheap and simple
Bryan: We may be able to enable host mode on USB0 and get use of both USB0 and USB1 on the board.

* What else?

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

Lisa/Bone

2014-04-14T19:23:20Z

Teslatech: /* Use cases */

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.

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

* What else?

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

Talk:Lisa/Bone

2014-04-14T19:16:49Z

Teslatech:

JKG Questions:
*Do we need a power supply on the cape? It will increase cost quite a bit. If Lisa/M is still connected directly to peripherals it may as well get power from off-board, most vehicles already have a 5-6V servo bus
* fully-populated Lia vs Lisa/M?
** Allows (almost) all connections to be broken out through the cape and BBB -- 0.1" header pins on Lia and sockets on cape with screws to lock boards together
*** much less wire nest
** no header pin access to ANALOG1 or ANALOG2

Note from Bryan:
*The SPI bus on the BB only can act as master. This would make the BB have to do busy loops polling the autopilot to check for data. I propose CAN as it has error detection and data framing.
*The lithium battery system only can act as a charger. The BB's power supply will not let it run on the nominal 3.6v of the lithium cell without a boosting SMPS.

Lisa/Bone

2014-04-14T19:14:46Z

Teslatech: /* Misc */

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.

== 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?

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

Lisa/Bone

2014-04-14T19:12:59Z

Teslatech: /* Communications */

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])

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

== 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?

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

Talk:Lisa/Bone

2014-04-14T19:10:06Z

Teslatech:

JKG Questions:
*Do we need a power supply on the cape? It will increase cost quite a bit. If Lisa/M is still connected directly to peripherals it may as well get power from off-board, most vehicles already have a 5-6V servo bus
* fully-populated Lia vs Lisa/M?
** Allows (almost) all connections to be broken out through the cape and BBB -- 0.1" header pins on Lia and sockets on cape with screws to lock boards together
*** much less wire nest
** no header pin access to ANALOG1 or ANALOG2

Note from Bryan:
The SPI bus on the BB only can act as master. This would make the BB have to do busy loops polling the autopilot to check for data. I propose CAN as it has error detection and data framing.

Talk:Lisa/Bone

2014-04-14T19:09:34Z

Teslatech:

JKG Questions:
*Do we need a power supply on the cape? It will increase cost quite a bit. If Lisa/M is still connected directly to peripherals it may as well get power from off-board, most vehicles already have a 5-6V servo bus
* fully-populated Lia vs Lisa/M?
** Allows (almost) all connections to be broken out through the cape and BBB -- 0.1" header pins on Lia and sockets on cape with screws to lock boards together
*** much less wire nest
** no header pin access to ANALOG1 or ANALOG2

Note from Bryan:
The SPI bus on the BB only can act as master. This would make the BB have to do busy loops polling the autopilot to check for data. I propose CAN as it has error correction and data framing.