Thank you to Peter barker for very detailed notes on the meeting.
-
InvenSense black-box investigations - just how do they work?
-
Tridge has worked this out with a suggestion from Leonard
-
- 950Hz tone allowed tridge to work out their internal processing
-
http://uav.tridgell.net/Leonard/FFT/950Hz-1kHz-FFT.png
-
http://uav.tridgell.net/Leonard/FFT/1kHz-4kHz-FFT.png
-
Beat frequency at 50Hz (delta of 1kHz and 950Hz) shows that sampling is happening at 1kHz
-
http://uav.tridgell.net/Leonard/FFT/950Hz-8kHz-FFT.png
-
This new code also shows a beat up higher, meaning we really are sampling at 4kHz
-
Filters have eliminated the lower beats
-
Shows the high-rate sampling is really going to help avoid problems caused by 500Hz-1kHz vibration
-
MPU6000 bug fixed this-morning
-
SPI bus is VERY busy on stm32
-
24 samples every 2.5ms
-
Linux boards use i2c, so don’t have the same issue (i2c is asynchronous for the CPU)
-
Tridge is looking at using DMA for SPI on stm32
-
Setup cost is high
-
Hundreds of bytes/transfer (for FIFO transfers) might make it worthwhile
-
We already use DMA for SD card, UARTs, but not for SPI transfers
-
New filtering strategy for high-rate sampling
-
(insert link from agenda here)
-
There’s been a shift of where we do SPI transfers on stm32
-
Used to be IO thread
-
In thread-per-bus this is done separately
-
No DMA on stm32 we don’t have multiple cores
-
Main thread would get interrupted by IO/thread-per-bus thread, then you would see 800us spike in routine you wouldn’t see most times (e.g. in mavlink routine)
-
Now we do an explicit (possible) 800us transfer as part of the main loop
-
Ensures we are always working with the latest data, too!
-
Less timing jitter
-
Way fewer timing overruns
-
Single-blind of fast-sensor sampling, comment from pilot was “chalk and cheese”
-
Factor of 20 reduction in low-frequency aliasing
-
But not on PixHawk one ATM (slow sensors)
-
MPU6000 does do 8kHz gyros, but should we use that fact?
-
Paul says probably, especially if there’s a blade passage frequency or motor fundamental at relevant frequencies
-
All about beats at the control frequencies
-
FIFO!
-
There are hardware bugs in the FIFO
-
Anything more than 30 samples and you get corrupted (even though it should hold 50 or 60…)
-
Julien had a workaround; he would flush the FIFO when it got too full!
-
The reset as it was could cause corruption (race condition if it was adding a sample when you were resetting)
-
Gyros would get interpreted as accels and vice-versa!
-
Would use temperature as a pseudo-canary…
-
We now use a three-step process to reset the FIFO
-
Set to use FIFO, but no data to be entered
-
Reset FIFO
-
Enable gyros, accels and temperature into FIFO
-
Fast sensors with LSM sensors
-
Tridge talking with ST about hardware bug in lsm303d
-
Progress with ST engineers, they’re trying to reproduce
-
Probably going to be more weird register settings….
-
Luis: How long ‘til we don’t need PX4Firmware tree?
-
Switchable for the sensors (defaults to in-tree)
-
px4io layer
-
ADC
-
CANBUS
-
Aim is to make it fly better, not to remove PX4Firmware
-
And to share drivers with Linux
-
CANBUS is probably a good next target
-
Px4io is a mess and would be really good to fix up
-
CANBUS F3-based boards!
-
http://www.jdrones.com/media/dev/UAVCAN_Devboard-Pinout.png
-
Where should he send these dev boards for people to work on?
-
Tridge is planning on shifting Zubax GPS to new CANBUS framework
-
Question as to whether the protocol is a problem, or the current software
-
Tridge thinks it is the current software, and thinks Pavel has done a good job on the specs
-
Hal.can!
-
Software needs simplifying
-
Best PC CANBUS thing to get:
-
Contact Ben, he has a lot
-
USBtin was recommended, but there’s apparently something better
-
USBbabel nobody has tried (was recommended for remote CAN stuff)
-
Tridge has been doing SRXL dev remotely, and thinks doing the same for CAN should be as straight-forward using this device
-
Philip says unreliable compared to Ben’s
