As part of LCA 2020, I gave my main talk Planning for and handling failures from open hardware, aviation, to production at Google.
The talk focussed on failures I've encountered in multiple fields, and what I learned from reading from other people's failures, a common practise in aviation that has saved countless lives in not re-creating failures and accidents out of ignorance.
As they say in aviation "experience is a cruel teacher: she gives you the test first, and if you survive, then you get to learn the lesson".
After looking at examples of failures we experienced at Google, I give a fair amount of examples from aviation, from AF447, QF32, and the Boeing 737 Max disaster which is so many failures in so many ways that it takes a while to describe in details. My hope is that engineers in a similar situation where they know they are getting overruled, can use other escallation steps to avoid disaster for others.
You can get the talk PDF or openoffice source from here. Otherwise, you can read the slides below and watch the video recording:
As part of LCA 2020, I gave a quick talk at the Open Hardware Miniconf about a year's worth of work in ESP32 and upgrading my Shirt from 24x32 neopixels (P10) to 64x96 in RGBPanels (P4), giving me almost 10x more pixels.
Running lots of demo code at 96x64 in 24bpp, storing 2 framebuffers for page switching, plus bitplanes for PWM, it ended up significantly stressing the amount of fragmented memory available on ESP32, so this talk deals with what I learned and how to get around the limitations.
Then, I also brought a demo of my next version using Raspberry Pi and displaying a framebuffer of 128x192, using FastLED_RPIRGBPanel_GFX I wrote for the occasion :)
Demo of 64x96 with ESP32 and 128x192 on Rasberry Pi
While in Surfers Paradise (Australia's Gold Coast), I noticed a cat café while driving by in the tram, so I went to say hello :)
It was end of day, so the cats were kind of tired of human interaction, but took time to take a few pictures:
Palais de la Découverte was the first science museum I went to when I was a kid, it had impressive exhibits then some 30 years ato, and they just added even newer ones, keeping the old favourites. Unfortunately the museum is scheduled to be moved to a lesser and smaller location in 2020, losing irreplaceable history and impressive exhibits.
I've been to many science museums around the world, and this is one of the top ones in the world, and honestly the best one in the world in amount of cool big scale experiments they had in a single building.
When we found that out, we spent 1.5 days going through all the presentations they had during the Xmas holidays, and we saw most but not all of the static exhibits:
it is located at the back of the grand palais, an iconic building in Paris
The different presentations were definitely a highlight:
exhibits on magnetism, showing magnets lose their properties when they are too warm
more interesting: stream of liquid gas is susceptible to magnetism
supraconductive material, when cooled sufficiently will stay in a magnetic equilibrium
The museum's high power experiments (static electricity and electro magnets) have been there forever and are always a favourite:
nice generator, 330kV
go big, or go home
induced electric currents from magnetism allow for levitation, and it's hot
There were lots of other exhibit of course:
it's all about density, yes this is real water and a real bowling ball
Multiple sections on animals
the ants exhibit was cool
the octopus demo was cool too
it gets to open a jar with a crab inside
and eat the yummy crab
The 2nd day, we came at opening time to see some static exhibits before the presentations started:
We then went to see the excellent supraconductivity:
and then came the time for the full scale maglev demo
a bit of time to cool down the supraconductive magnets
and then it was Jennifer's turn:
There plenty of other presentations:
turning gas into solid
oxygen in the air liquefies first, and causes flammable liquid
safety goggles are for other people :)
they had bucket fulls of liquid gas to play with
After 1.5 days, we didn't quite get the time to see it all, but we made a good dent. The staff and demonstrator were awesome. I'm really sad that this museum will close forever in less tha na year.
RBGPanels are a pain to drive, they require constant refreshing and it becomes more of a problem when you aim for higher resolutions (128x128 and above), as they require more horsepoewr and memory than either a teensy 3.6 or ESP32 can reasonably provide (the two top of the line chips supported by SmartMatrix)
Another issue is that SmartMatrix, while better than all the other libraries on arduino, doesn't support all kind of weird panels out there, specifically the AB and AC panels that you often end up getting when you get higher resolutions like 128x64.
Using Neopixels would work better of course, but they caan't reasonably be had in less than P5 (0.5cm/LED) while RGBPanels go down to P2. Also, neopixels are about 10X more expensive per pixel, if not more.
So, the solution is to use a rPi to drive RGBPanels of size 128x128 and larger (a single Pi with 3 parallel channels can reasonably run up to 256x256. After that it gets harder and you need multiple microcontrollers).
This is where the excellent https://github.com/hzeller/rpi-rgb-led-matrix driver comes in. It's the most feature complete RGBPanel driver for microcontrollers
Ok, but you have all this arduino code, maybe written for a FastLED::NeoMatrix or Adafruit::NeoMatrix array using the Adafruit::GFX API. Or maybe, you used the FastLED API with an XY mapping function, or maybe even you're using the LEDMatrix API for FastLED. None of those work on rPi, and you don't want to change/rewrite your code.
Well, there is good news: you can use https://github.com/ChrisMicro/ArduinoOnPc to run arduino code on PCs, and therefore also rPi. It is however designed to display in an X11 windows, which is not what you'd want. So, instead, I forked it for you and wrote a rPi glue driver for my FrameBuffer::GFX base class: https://github.com/marcmerlin/ArduinoOnPc-FastLED-GFX-LEDMatrix
You therefore end up getting access to those 3 arduino graphics APIs, and you can render on rPi using a much faster and the more feature complete https://github.com/hzeller/rpi-rgb-led-matrix driver
By using these driver options, I get about 400Hz refresh rate on rPi3, lowering the amount of pwm bits:
~/rpi-rgb-led-matrix/examples-api-use/demo --led-gpio-mapping=regular --led-rows=64 --led-cols=128 --led-row-addr-type=0 --led-chain=1 --led-show-refresh --led-slowdown-gpio=1 --led-parallel=3 --led-pwm-dither-bits=1 --led-pwm-bits=7 --led-panel-type=FM6126A -D0
Those variables are assigned when you create "rgb_matrix::Canvas *canvas", which is fed into matrix->setCanvas(). See this example code:
With rPi, especially with the active-3 board you can drive resolutions of at least 256x256. Here is an example of 128x192, 4 times bigger than the highest resolution I was ever able to drive on ESP32 (64x96). Here is a video natively playing on rPi: