Should we move ArduPilot Groundstation from LabVIEW to Nokia's Qt?

As we prepare to migrate our current LabVIEW groundstation from ArduPilot to supporting ArduPilot Mega, we're taking the opportunity to rethink its architecture and code base.

Right now it's written in LabVIEW, a visual programming environment that has the advantage of rapid development and easy-to-make instrument displays, as well as being cross-platform. But the problem with it is that the development tools aren't free (indeed, the ones that can create an executable file start at $1,249!), and distributing the files requires users to download a runtime engine and serial driver. As a result, we don't have as much community participation in the ground station as we do in most of our other projects.

Over the past year, we've been looking for an alternative with free and good development tools. It needs to be cross-platform, compatible with open source code standards, and appropriate for a ground station (ie, able to handle a rich visual environment and to talk directly with the serial port). Eventually a good candidate emerged in Nokia's Qt application and UI framework, and I'd like to present it here for community feedback.

You can see a glimpse of Qt above, but here's the description from the site:

"Qt is a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

Features

Intuitive C++ class library
Portability across desktop and embedded operating systems
Integrated development tools with cross-platform IDE
High runtime performance and small footprint on embedded"

Note that it's cross platform on more than just computers--it will also run on phones, too, which introduces the possibility of an ArduPilot GCS on Android or some other smartphone, which would be very cool. Also, we intend to integrate the current ArduPilot configuration utility into the GCS, so one desktop program can handle all the ArduPilot functions, from mission planning to real-time data display, including integrated Google Earth and video handling and image processing.

So what do you think? Is this a good code foundation for a full-featured groundstation? Does Qt look like something you'd adopt for the right project?

[UPDATE: See this Swiss team's MAV groundstation for an example of what Qt can do. Nice! It's open source, so we can build on it if we want.]

At the company I worked for previously we spent some time tinkering with Qt on WIndows CE, but eventually scrapped it in favor of an Android solution for the project we were working on (a GPS Navigation product with a 4.7" touch screen). There is some real power under the hood, so it definitely shouldn't be overlooked. I would have to say though, if this were my project and i had to select a language likely to have plenty of coder support and long term reliability - I'd have to go with a combination of Java and Python...Python for Rapidly getting the thing up and going, then hardening objects into more static Java code modularly. This may be a bit complex, but the result is usually a bunch of really solid Java parts with some Python holding it all together. I'm not sure you could really go wrong wither way, but my guess would be we likely have more people with Python experience than Qt. Just some thoughts.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Howard Gordon March 30, 2010 at 10:33pm

The PicHawk code looks like a great starting point. You should take a close look at their MAVLINK protocol to see whether you might want to support it in ArduPilot. This statement is interesting - "NEWS: MAVLINK will be evolved to be SAE AS-4 compatible in the next months. The goal is to create a kind of AS-4 light". SAE AS-4 is the new name for the JAUS framework.
David Ankers March 30, 2010 at 9:22pm

Now that is cool! Never seen that before and they are way more advanced than we are, I would suggest joining forces with them and definitely not us! We have a long way to go and are planning to reinvent the wheel somewhat, plus our GCS is fairly tied up with UAVTalk & UAVObjects.

That looks like an amazing project, very very powerful hardware and their Quad is so stable.
3D Robotics

Chris Anderson March 30, 2010 at 9:10pm

Turns out a Swiss university team has already written a very good looking open source UAV groundstation in Qt. Screenshots below...

Anybody know anything about the PixHawk MAV project?
David Ankers March 30, 2010 at 8:15pm

> My suggestion is to not bother with Python. It's a lot less cross-platform than you should expect,

I strongly disagree with this, additionally Qt is not as they advertise "write once, run anywhere". Python is much more cross platform than Qt in C++ by a long way.
3D Robotics

Chris Anderson March 30, 2010 at 8:14pm

David, that IS a coincidence. We were actually turned on to Qt by Nokia itself--I didn't know you guys were using it but am glad you are! Maybe join forces?

With nearly 10,000 members, I'm pretty sure we can find a few C++ developers in this community. With Howard's comments in mind about the cross-platform limitation of Python, I'm tempted to just do it right.
David Ankers March 30, 2010 at 8:02pm

Wow this is a coincidence. ;-)

For Ardu I personally do not think Qt & C++ fits very well, I would seriously consider Python with Qt bindings. It gets what you want without needing C++ developers, Python seems to fit with the project a lot better and there is a higher learning curve with C++, it just doesn't feel like it is a fit for Ardu as well as Python does.

Obviously as a lot of people know OpenPilot is using Qt for our GCS and this is where Chris learnt about it, we are taking our time with OpenPilot hence C++ was chosen as it is what I know being a KDE developer. We would have got many more developers if we had used Python or Java for sure.

We also have a OpenPIlot GCS running on Android (or at least I do as this is my project) but again Qt is not the right tool for this, Java is on Android.
Howard Gordon March 30, 2010 at 7:55pm

My suggestion is to not bother with Python. It's a lot less cross-platform than you should expect, at least in my painful experience of maintaining a Python-based robot control console. QT does look like an interesting choice - there's at least one open-source GCS project in the works. Also, it appears that QT will run on Android.
Scott Plunkett March 30, 2010 at 7:41pm

At the company I worked for previously we spent some time tinkering with Qt on WIndows CE, but eventually scrapped it in favor of an Android solution for the project we were working on (a GPS Navigation product with a 4.7" touch screen). There is some real power under the hood, so it definitely shouldn't be overlooked. I would have to say though, if this were my project and i had to select a language likely to have plenty of coder support and long term reliability - I'd have to go with a combination of Java and Python...Python for Rapidly getting the thing up and going, then hardening objects into more static Java code modularly. This may be a bit complex, but the result is usually a bunch of really solid Java parts with some Python holding it all together. I'm not sure you could really go wrong wither way, but my guess would be we likely have more people with Python experience than Qt. Just some thoughts.
Admin

Morli March 30, 2010 at 7:11pm

Sounds good, started the download already, will start learning shortly , cross platform is gr8 possibility,
3D Robotics

Chris Anderson March 30, 2010 at 5:50pm

Qt is totally cross-platform: Windows, Mac, Linux, mobile phones.

I do think Processing is an interesting choice, but just don't know how easy it is to create a full UI with it.

Python could could work with a Flash front end, but would required running two programs, not one, I think. I think Jason would be the best to comment on that, since he's done something similar with his GCS.

of 6

This reply was deleted.