Software Development in Agriculture
Have you heard about software in cars that run on embedded devices? Do you think that creating such software might be challenging? Well, welcome to a complete new world of complexity, welcome to the world of agriculture machines! For many years, automatic steering (on fields), terminals to control the complex mechanical operations of a self-driving 16 ton combine harvester on a soft ground, and self-optimization systems to optimize any tiny bit of your harvester, are key demands from customers. I, myself, am working at CLAAS E-Systems, the electronics and software department within the CLAAS group. Our group is well known for being among the leading manufacturers for combine harvesters, tractors and forage harvesters.
The main human machine interaction interface on such machines, besides the driving joystick and the throttle pedal, are tablet like control terminals appended at the end of the driver’s arm rest. It is my daily job to bring awesome looking and user friendly interfaces together with safety regulations and put the results onto such terminals. Considering today’s demands on these terminals, we are approaching what one is used from a typical Linux desktop system: For example, one can think about different applications for steering, controlling the machine functionality, or the entertainment system. Such separations into different processes not only increase robustness. In a field with heavy safety regulations, clear separations of scopes and interactions they are a virtue to decrease effort spent on safety assurance.
Window Compositing using Wayland
Naturally, the composition of the different windows of separated processes into a seamless UI is the task of a window compositing system. From the desktop world we know the good old X.org server that today is slowly replaced by much more modern Wayland compositors. In the mobile and embedded world its successor already took over and Wayland is the default choice when considering a window compositor. Unlike for X.org, there are different implementations of the Wayland window compositing protocol. Best known, there is the Weston compositor, the actual reference implementation of the Wayland protocol. On top of it, driven by the demands in the automotive industry, there is also the IVI protocol abstraction layer. IVI provides a very small compositor interface with the primal goal of exchangeability and compatibility, for which your BSP (board support package) supplier usually has a compatible compositor to offer. And IVI often works well, specifically when you have a UI with only limited window dynamics or animations, like a static display of windows as it is the typical case for radio control and climate control windows in a car. But if you want to add fancy window animations or if you have a certain complex UI and gesture workflow in mind, the IVI protocol drastically shows its limits. Taking a step back and considering to extend the Weston compositor, however, would bring you into the complex world of working at the heart of one of your most crucial software components in an unfamiliar environment.
Qt Wayland Compositor
Recently with the Qt 5.8 release, the Qt Wayland Compositor Framework started to become a viable new alternative. It not only provides the Qt Quick API that allows you to easily create a compositor from scratch with just a few lines of declarative QML code. In particular, it allows you to change your work assumptions when thinking about a compositor: Since the whole compositor is created in Qt Quick and the complex surface interaction and Wayland protocol logic is well hidden, it is possible for “just” a Qt Quick developer with basic Wayland understanding to create a compositor from scratch. The big benefit therein lies in the point that such a developer is well trained in using Qt Quick for creating awesome user interactions with great looking UIs. For creating a compositor that presents all available windows in a swipeable way, a Qt Quick developer just uses a ListView, adds the windows and it’s done. Now think about how long a Wayland expert would need for this task and how challenging it would be to do some rapid prototyping for such a compositor in the other case.
The power of the QtWayland compositor framework thus is not only that it provides a nice and lean API to use but that it shifts the task of creating a Wayland compositor from the very specialized field of Wayland engineers to the field of Qt Quick/Qt developers. It allows you to focus just on creating the best interaction and UI for your customer, hence what really counts. If you are eager to try it out, just look at the examples shipped with the framework. Maybe you are also interested in my recent talk at FOSDEM ’17 in which I showed how simple it is to create a compositor from scratch.