Difference between revisions of "Lisa/Bone"

From PaparazziUAV
Jump to navigation Jump to search
(→‎MCU or not MCU: mcu suggestion)
 
(17 intermediate revisions by 5 users not shown)
Line 9: Line 9:


I suggest a 64 pins STM F4 (like in Lisa/M)
I suggest a 64 pins STM F4 (like in Lisa/M)
  NeoFromMatrix: I would suggest STM32F429ZIT6 15,55€Mouser


We don't need level converters. BBB is happy with 3.3V IOs
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.
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 (like the discovery board) and 0805 (or bigger) parts.
  The cape should provide enough space and 0805 is easier to solder by hand.


Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith
Communications between F4 and BBB is through SPI (BBB master, F4 slave) in order to have high bandwith
Line 18: Line 21:
Gautier says he wants UART communications:  
Gautier says he wants UART communications:  
   can you justify and specify which UART of the F4 you'd use ?
   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
   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 ==
== Connectors ==
Line 24: Line 34:
Let's start from Lisa/M connectors. We have a little bit more space available
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
   - 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 ==
== Supply ==
Line 31: Line 42:


-I would like to be able to power the whole thing from 3/4S flight pack
-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?
-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?
-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] )
-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) ?
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
1400mAh give ~3h endurance and weights 25g, 500mAh is 10g
 
  Discarded, Bryan says it doesn't work


== Misc ==
== 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
-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?
-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?
-Do we want to be able to flash F4 from BBB?
  NeoFromMatrix: That would be nice.


== Communications ==
== Communications ==
Line 53: Line 70:
* BBB drives the xbee and tunnels communications to F4. Bad, we lose advantage of code segregation  
* 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 :)  
* BBB and F4 each have a xbee. Bad, we increase weight and power consumption :)  
* for short distances (rotorcraft), BBB through wifi, F4 through wifi
* 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 ==
== Use cases ==
Line 63: Line 84:


* Someone runs image processing on BBB (using a usb webcam?) and current rotorcraft code in F4 - similar to case 1
* 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?
* What else?
[[Category:Lisa]] [[Category:Autopilots]]

Latest revision as of 11:51, 29 April 2014

Lisa/Bone is a project consisting in designing a Paparazzi 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)

 NeoFromMatrix: I would suggest STM32F429ZIT6 15,55€Mouser

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 (like the discovery board) and 0805 (or bigger) parts.
  The cape should provide enough space and 0805 is easier to solder 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 ( 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 ( 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 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?