24 replies to this topic

[Reddog]

Kenn Sebesta, on 28 November 2011 - 11:11 PM, said:

Because the R/C transmitter is "guaranteed", whereas the GCS running on your computer is anything but. In a multitasking environment, you have no determinism, so you never know when something will interrupt.

Its only guaranteed because it was built that way......

[Kenn Sebesta]

Reddog, on 28 November 2011 - 11:19 PM, said:

Its only guaranteed because it was built that way......

True, but there are precious few opportunities available for doing it any other way. If we want GCS to compile and run, we need Qt. Qt runs on Mac, Linux, and Windows, three OSes that are not real-time (although Linux can indeed run real-time and userspace tasks at the same time, using RTAI). So structurally, we cannot build a real-time system on the GCS side, unless we sit down and create our own operating system.

This being impractical, what we can do instead is create a distribution of Linux that runs GCS and nothing else. An embedded system, effectively. While this is much more practical, I'm not sure this is quite practical yet. For me as a researcher it makes sense, because I have a budget for this and I can thus resist temptation. For a user, I'm not quite so sure.

I like your point, though, that hobbyists will have a TX, and thus won't be interested by what GCS has to offer beyond configuration. To be honest, though, I don't see that we can answer the all important questions about where OP wants to go. That might be best answered by Dankers.

[Reddog]

Kenn Sebesta, on 28 November 2011 - 11:34 PM, said:

True, but there are precious few opportunities available for doing it any other way. If we want GCS to compile and run, we need Qt. Qt runs on Mac, Linux, and Windows, three OSes that are not real-time (although Linux can indeed run real-time and userspace tasks at the same time, using RTAI). So structurally, we cannot build a real-time system on the GCS side, unless we sit down and create our own operating system.

Thats not quite true. A SBC (for GCS) interfaced with an STM32 (for real time) would do the trick.

[Kenn Sebesta]

Reddog, on 29 November 2011 - 12:17 AM, said:

Thats not quite true. A SBC (for GCS) interfaced with an STM32 (for real time) would do the trick.

But what is the SBC running in order to run the necessary toolkit for the GCS graphics? OpenPilot depends heavily on Qt for all the glue that makes GUIs work. The code to run GCS pales in comparison to the code to run GCS's windows, click events, focuses, etc... All this is non-real-time, and there's little to nothing that can be done about it, sadly. So if GCS, as a whole, is controlling the board, these is always a clear and present risk that the GUI crash or otherwise get hung up on things. IMHO, the best way to mitigate these factors are to run a stripped down version of Linux, which we could indeed run on an SBC.

P.S. I think I hijacked your thread, sorry.

[Reddog]

Kenn Sebesta, on 29 November 2011 - 12:24 AM, said:

P.S. I think I hijacked your thread, sorry.

As I said I think this will end up splitting into 3 different discussions and hardware is one of them, so you didn't really hijack.