Neuer Flightcontroller mit Raspberry Pi

[brm]

Dann kannst auch gleich TauLabs nehmen. Wir stellen bald auf Chibios um. Ich habe schon mal einen Blink-LED-Kernel gebaut. Bootet sehr schnell . Leider hat der RPi nur eine serielle und die PWM sind fixed. Damit kann man gegenüber anderen Controllern keinen Blumentopf gewinnen.

ja, fixedwing kann man fliegende blumentöpfe nennen.

Im moment würde ich eher den intel edison weg gehen.
immerhin gibt es gleich yocto mit.

 

[ernieift]

Der edition gefällt mir auch mehr. Zunächst kommt erstmal ein STM32F7 raus. Mal sehen, wie der sich macht.

 

[brm]

Der edition gefällt mir auch mehr. Zunächst kommt erstmal ein STM32F7 raus. Mal sehen, wie der sich macht.

ja, dieser m7 ist noch ein zwitter - aber immer noch sehr interessant.
hoffe via nürnberg eine platine zu ergattern.

bleibt spannend

 

[ivereninov]

Real-time performance is usually the first question. There are many "experts" that claim that Linux can not run in real-time. With RT Preempt kernel APM:copter runs very reliably and there are no reasons why it should not. We did testing with loading the processor to the top and max latencies are 77uS (microseconds).

 

[brm]

as i said - look at the link provided above.
i don't trust you ;-)
you know why - because you are mentioning a number without saying to what it belongs.

the latency issue is chipset dependent - and the older arm systems do not really behave well.
https://www.osadl.org/Latency-plot-of-system-in-rack-2-slot.qa-latencyplot-r2s8.0.html

and don't forget to include the latency introduced by the driver plus corresponding hw.
i am more scared by the drivers...

hmm, i am used to have a latency in the us range ... +- one digit

 

[ivereninov]

I also have a link to provide
http://www.emlid.com/raspberry-pi-real-time-kernel/

Average loop time in APM is 2.5ms, so I do not see a problem with 0.08ms max latency. But these are just numbers, the real fact is that I can take it and fly around and it flies very stable. Isn't it what we are trying to achieve?

I work on Navio autopilot everyday for almost a year and have absolutely no doubts in RT performance of Linux.

 

[cloidnerux]

Is there a Video of a navio flying around in open ground and with some speed? Perhaps the GPS features of APM?

 

[infinity]

Hey there,

Sure, it is possible, but only if the kernel AND the drivers are adapted to have a low latency. I developed a multirotor software a few years ago (with an AtMega8) and for me personally, I wouldn't even think of using a OS as base for a flightcontroller! There are too many possibilitys where an error can occur and cause your system to crash! I know how stable Linux is and I like it. But for such a task, the "main" controller shouldn't do anything else than stabilize the multirotor or plane. An Rpi for navigation and GPS is a great possibility in my optinion.

Cheers

PS: Sorry, I'm tired, I haven't read through again so pls excuse any language mistakes

 

[brm]

I also have a link to provide
http://www.emlid.com/raspberry-pi-real-time-kernel/

Average loop time in APM is 2.5ms, so I do not see a problem with 0.08ms max latency. But these are just numbers, the real fact is that I can take it and fly around and it flies very stable. Isn't it what we are trying to achieve?

I work on Navio autopilot everyday for almost a year and have absolutely no doubts in RT performance of Linux.

i work with arm cpu's every day - since a couple of years.
the more interesting thing is looking at the device drivers.
there you see the real latency.
not just the optimized latency during a context switch.
which is ok.

the last time we took a freescale wandboard apart we come to the conclusion re-writing the spi drivers to fitt our needs was a must.

also a sad point is the sd card interface.
ever measured the latency over the lifetime of an sd card?

 

[ernieift]

To throw another time value: TauLabs on STM32F4@168Mhz has a selectable loop time down to 500µs. With OneShot-ESC you are able raise the PIDs far higher than normal. The jitter + latency here is less than 10µs. This is what i measured with a scope.

 

[brm]

To throw another time value: TauLabs on STM32F4@168Mhz has a selectable loop time down to 500µs. With OneShot-ESC you are able raise the PIDs far higher than normal. The jitter + latency here is less than 10µs. This is what i measured with a scope.

yes, the m4 running at 168mhz is very powerfull.
the reduced command latency results in higher pid settings.

but first i'd like to re-use my current esc's - i have no one-shot esc's at the moment.
i can easliy sync the main loop with the esc-pwm frequency by resetting the pwm counter at the end of the
main loop.
this should also reduce the comamnd latency ;-)

 

[ernieift]

Within TL, i synced the PID calculation and PWM Output with the (interrupt driven) MPU-rate. This can be up to 8000Hz. The STM32F4 is fast enough for rates up to 2000Hz.

 

[cloidnerux]

Hat eigentlich schon irgendwer mal so einen XMOS mehrkern Prozessor eingesetzt zum copter steuern?

 

[brm]

Within TL, i synced the PID calculation and PWM Output with the (interrupt driven) MPU-rate. This can be up to 8000Hz. The STM32F4 is fast enough for rates up to 2000Hz.

ups - still on my todo list.

going above 1khz means removing the ekf - which is not my intention.
so i stick with 1khz :-/
but having a pelican the picture will change.

 

[infinity]

My optimized (basic) control loop took 890µS on a Atmega8 overclocked to 20Mhz. But you write the output value in a register and don't give it to a kernel module!
It's all about optimizing the Code. Sometimes inline assembly is the best way, even if it is the most difficult and complicated.

I don't know much about 32bit or 64bit desktop CPU's but there are better options for a multicopter control. You simply don't need an i7 for flight stabiliization

 

[Pilotix]

Oh yeah, a flying Desktop

But back to my question: Who, and where are you ? Whois says... nothing , where is the about us ? Even 3dRobotics (which is your main competitor) has an about button...
This is what scares me...

Edit:
Optimizing isnt normal nowadays... Just have a look at the gaming Industry... once upon a time , there were programmers which programmed and optimized the games to run fast enough and look stunning... but now... thats another Thing

 

[infinity]

Oh yeah, a flying Desktop
...

Well, I was at DLR and we used an i7 onboard, but for image processing based autonomous flight. Have a look at Ascending Technologies, they sell an i7 board which has the size of 1 1/2 Raspberry Pi's and has awesome processing power. But in most cases you won't need it.



Have anybody seen a Navio+ live flying?