Dronin gone to the dogs! (BeagleBone Blue)

jihlein

I just finished modifications to the sim code to enable it to run on the BeagleBone Blue single board computer. On the bench, it works okay, with a few small issues. I have it running with an SBUS receiver, external mag, and gps. The adc is reading battery voltage. I'm running at 500 Hz loop rate, ESCs are at 400 Hz update rate. The BeagleBone Blue is nt as powerful as the RPI3, it's loading the single core CPU at about 48%.

The 2 issues I'm seeing are:

1)Occasionally the sensor status will go from green to red. It's fairly infrequent, and doesn't seem to cause any obvious issues. I think this is being caused by the unfortunate fact that the MPU9250 on this board is communicating by I2C rather than SPI. If I can figure out how to change the BeagleBone Blue I2C clock, I may try overclocking the MPU9250 I2C and see if that helps some. SPI is broken out to external pins, could get an MPU9250 braekout board that talks SPI......

2)The event status is toggling between green and yellow fairly regularly. I'm connected to the BeagleBone Blue over Wifi, that may have something to do with it, I'm not 100% sure. I may try a direct serial connection to see if that helps any.

There may be better ways to implement some of this, comments welcome. I have a beater quad that I'm going to install this on for testing, maybe this weekend.

I should add I made use of the PRU code and other utilities used by the ArduPilot BeagleBone Blue target in this effort.

mlyle

Nice.

Sensors going red is very bad.

Have you built a preempt-rt kernel for the beaglebone blue? I really don't recommend flying without a hard-realtime kernel.

If you've done the first, you may need to set some kernel tasks (SPI, I2C, and any associated interrupts/dma tasklets) to realtime using chrt. On the current directions for pi we change 'spi0' for that reason.

jihlein

BeagleBone Blue comes with a preempt-rt kernel installed. Not familiar with chrt, time for some research. Thanks!

mlyle

No problem. The command is on the flyingpi wiki page for spi0. The tricky part is, you need to figure out -all- the kthreads you're using and that's not trivial.

jihlein

capture.jpeg

@mlyle - pgrep i2c returns no output, so I'm not sure what that tells me. Think it is saying there are no I2C kernel tasks running.

mlyle

jihlein Yah, it looks like on the beaglebone it's (sic) drivers/i2c/busses/i2c-omap.c which is interrupt driven and completes requests in the interrupt bottom half / a dedicated interrupt thread depending on hw revision.

Unfortunately I don't have beaglebone hardware. But part of making RT work reliably is ensuring that everything in the path of realtime activity is running at an appropriate rt priority. Otherwise, low-priority realtime threads will outweigh (and even non-realtime threads will compete with) completion of I2C activity, preventing sensors from running and resulting in priority inversion.

That is, RT highprio thread A starts an I2C request and goes to sleep to wait for completion; RT medprio thread B starts running; I2C request completes and ordinary, non-realtime kernel thread wants to run to mark request completed; thread B keeps running until it wants to be done for other reasons because it's higher priority.