Lisa/Bone

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)

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

  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

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

• What else?