3D Robotics

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


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.]

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Developer
    I will go for QT... ArduPilot is programmed in C/C++. Actually i was thinking on apply myself on Visual C++ or C#, but QT is very similar to Visual C++ plus is multi platform. So i will start something very simple without OpenGL, simple numeric gauges and buttons to program mission's and telemetry. From there the community will start to improve it and add features as before.
  • PyQt would be a great place to start. Who should I contact to get involved with this?
  • Admin
    Clearly a well said points to note "for" QT and i agree since I need learn some thing new anyway. thanks for sharing Chris & Lorenz . I assume by "Sharing the source code" here we can contribute/customize for our requirement & it will be a open source. Thats gr8 news Chris
  • 3D Robotics
    I asked Lorenz Meier of the PixHawk team (who have a Qt groundstation) for his advice. Here's his response, with his permission. BTW, they're sending me a zip file of the source code, which we can post here:

    "In general I think your readers are right that Python is a way easier choice and that more people will be able to contribute that way.

    However I think that the discussion has ben led away from the right focus: It is not the question, wether Python or C/C++ is easier to learn and handle. It is also not the question how many developers exist for each language.

    Because eventually the development will be carried out by a small group of 2..5 enthusiastic developers, not dozens of people of the community. The reason for this is quite simple: A ground control station with significant functionality will require time to understand the basic structure and concepts (independent of the choice of language and toolkit) and only few people will be willing to invest that.

    The questions are merely, like in any application development:

    - What does the use case require (What is the best toolkit and programming language)
    - What is a user, what is a developer?
    - What are the requirements of users?
    - What are the requirements of developers?

    I have also some guesses on the answers:

    - The use case requires complete operating system abstraction. It requires a really, really good UI toolkit with hardware acceleration through OpenGL (HUD rendering on CPU is just too slow). It should also support multithreading

    - My educated guess: 95% of ArduPilot users will not want to touch the GCS code at all, so we are looking at 95% pure-users and 5% more intense developers

    - Users want: Easy deployment (download an executable and double-click it, no additional libraries, no compiling of code), Low hardware requirements, and then implementation, not language specific stuff like look and feel, good interaction concepts, etc.

    - Developers want: Clean separation of individual UI parts, separation of communication and visualization layers, assistants for UI elements like forms, an object oriented general setup and multithreading support (critical for using serial, OpenGL and still having a responsive UI).


    In general Python and C++ fulfill all these requirements, except that deployment for Python applications on Windows requires to install the whole toolkit or to pack the python code into an C/C++ executable with in-built interpreter. Now many points are not that new or surprising, but some things are worth to notice:

    - Because of the hardware access to serial and OpenGL interfaces, implementing this kind of application is not trivial, because it involves multithreading and requires careful implementation. This eventually implies that it will require either significant time to learn these concepts or a computer science background

    - These requirements imply "experts" either by profession or interest. Those experts typically prefer an object oriented architecture and are, if they come from the application development domain, usually trained in C/C++ or Java (because those applications can be deployed easily on Windows). Of course any of them can pick up Python quickly, if he/she doesn't know it already as well.


    To conclude, I would say the more important concerns should be to select a language and toolkit that supports multithreading, OpenGL hardware acceleration, object oriented programming and easy deployment. I think it is pretty clear that Qt is the right toolkit. Now C/C++ vs Python will more depend on what developers prefer and how well the deployment with py2exe works in practice.

    Our decision to go with C/C++ was eventually driven by the easier deployment in Windows and the fact that our developers here write C/C++ code on the MCU and single board computer and thus can easily understand the ground control station code."
  • 3D Robotics
    For those interested in Qt, this looks like a good book.
  • Well after buying LabView of coarse I vote for Labview, BUT I go with whatever cycles the improvements faster. And also something that does not have a steep learning curve.
    Earl
  • I would vote for Java for the following reasons:
    - It has the biggest developper's community
    - It is truely cross-platform ( You could also have a J2ME flavor for mobile devices)
    - There are loads of very good free IDEs available (eclipse, netbeans, ...)
    - There are a lot of open source libraries available ( 3d graphics, 2D graphs,...)
    - It is much simpler/safer to program than C++
    - It could run as a tool in processing This would be useful during dev phases.
    - I don't believe garbage collection would be an issue for a GCS if it is reasonably well designed. At least not on most today's PC.
  • I Agree with Howard HTML 5 has a lot of potencial. Just have a look at this small demo of the new HTML 5 Canvas element.
    Has I said previously I am working on a small prof of concept using only html 5 to render the GCS UI and Java on the webserver side. But don't worry there are several lightweight opensource webservers that can be used to implement the communication with aircraft. I am very confident that it can be done.
    HTML 5 is already supported by several browsers and it will take off very quickly in the next 12 months.
  • 3D Robotics
    @dydx: it's pretty much the features of our current ground station and configuration utility combined, with better Google Earth integration, voice synthesis and maybe the capacity for video display.
  • If we're looking at a new technology platform then it is likely the existing ground station will need to be redeveloped from scratch. Which means it probably worth re-evaluating the requirements.

    Is there currently a set of requirements for an Ardupilot ground station software? Maybe we should get the community to collate some generic implementation independent requirements to determine what are some desired features. We'd also need to get strategic direction from Chris/Jordi to ensure that requirements are in line with Ardupilot strategic roadmap.

    I have wasted time in the past exploring a myriad of different implementation technologies before having a well defined set of requirements.
This reply was deleted.