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.

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
  

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

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)

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