Connectivity Solutions Will Not Help with Autonomous Farming

Over the last two years, agricultural OEMs have been in a rush to get data from their machines to their cloud servers. Claas uses Proemion’s connectivity solution. Agco, Grimme, Krone and a few others bet on AgriRouter running on SAP’s cloud servers. Holmer seems to favour Bosch’s IoT suite. All these solutions have one thing in common: They transfer little data, typically less than 50 data points per second. They top out at 100 data points. They are good for task or order management, asset tracking, fleet management, monitoring of machine health and remote diagnosis.

At least some of these companies seem to think that these connectivity solutions will help them with driver-less or autonomous farming like harvesting, seeding, spraying or fertilising. The wishful thinking would go like this.

The farm machines transfer data to the cloud. The data is used to train machine learning algorithms on extremely powerful compute servers. The model, the result of the learning process, automagically detects whether grains are dirty, maize leaves are dry or the heads of sugar beets are chopped off. Typically, this model runs in the cloud as well, because it requires more compute power than is available on the farm machine or because it adapts to new conditions and self-optimises by continuous learning. This is the way how voice assistants like Alexa and Siri understand spoken language or how medical software recognises cancer cells in MRT scans.

This approach does not work for farm machines. Here is why and what we can do about it.
Continue reading

Farmpilot Could Have a Bright Future

Farmpilot is a software to help farmers and contract farmers with their daily logistic tasks. It helps with planning at which location drivers and vehicles have to be at a certain time. It also helps tracking the fuel consumption, distance and area of the vehicle on the field and road – ordered by field and by customer. Contract farmers use this information for invoicing the landowners and farmers for paying their employees.

Many farmers use farmpilot already. Two of the biggest sugar producers in Europe, Nordzucker and Südzucker, have mandated the use of farmpilot for harvesting sugar beets (see page 3 of this PDF). Of course, farmpilot sends its data to the cloud. And – Arvato, the company developing farmpilot, has the cloud infrastructure in place.

Probably every terminal in a tractor or harvester comes with a task or job management. The manufacturers of these terminals should replace their home-grown solutions by farmpilot and save the development effort. There are three ways how to do that.

First, the farmpilot application runs on a tablet and communicates with the terminal over (W)LAN. The tablet has a mobile Internet connection and synchronises its data with the farmpilot servers in the cloud. The terminal relays data like fuel consumption, distance, harvested area and GPS coordinates from the CAN busses to the farmpilot application on the tablet. The driver interacts with the application solely on the tablet. This is most likely what we will see soon in the sugar industry.

Second, the application is mirrored to the display of the machine’s terminal via VNC – similar to MirrorLink, Apple CarPlay and Android Auto for in-vehicle infotainment systems. The application still runs on the tablet or smartphone, but the user interacts through the terminal’s touch screen with it. This is more convenient for the driver, because the terminal is usually closer to the joystick and the steering wheel than the tablet.

Third, the farmpilot app runs on the terminal directly and communicates directly with the cloud servers. There is no need for an extra tablet or smartphone anymore. The app could use something similar to the AWS IoT Device SDK, which sends MQTT messages to the cloud and receives MQTT messages from the cloud in a secure way. Using a cross-platform GUI and application framework like Qt, Arvato could develop their app once and deploy it on all terminals, tablets, smartphones and PCs. This would be the best solution for the user and the solution with the least development effort.

This is not yet the bright future, but the necessary groundwork Arvato must do. In its current version, the farmpilot application relays a few CAN messages to the cloud. The infrastructure to forward every relevant CAN message from the engine, the harvesting header or the drive train to the cloud is in place. The farmpilot app is the gateway to all the data from the harvesters and tractors. Once this data is in the cloud, Arvato could run deep learning algorithms to find the right header or implement settings for an optimal yield or to detect machine defects early.

Now, this would be a bright future for farmpilot.

More Reasons For Not Using Web

The Qt Company published a guest post “Qt QML v HTML5 – a practical comparison” and a whitepaper by the Austrian Qt consultancy Sequality. Sequality had one developer writing a simplified application for controlling a bottling plant first with Qt and then with Web (AngularJS). The developer had 160 hours for each implementation. The application had to run on a tablet, a PC and a Raspberry Pi 3 with different resolutions.

Here are my favourite findings of Sequality’s experiment.

  • The developer finished considerably more functionality with QML than with Web.
  • Higher efforts to use OpenGL acceleration for Web: “Enabling GPU rendering on Chromium […] doesn’t fix the HTML5 demo’s performance problem. In fact, the CPU is utilized even more, which leads to overheating.”
  • Higher efforts for testing Web: “The fact that HTML5 applications can be executed on a number of platforms – and a number of browser engines on each platform – multiplies the testing time correspondingly.”
  • Availability of a certain Web technology in 10 years: “Modern HTML5-based applications that use frameworks like AngularJS are relatively new and undergo changes from year to year – a valid question is whether AngularJS (or any other currently trendy Javascript-library) will still be a relevant HTML5-technology in 10 years.”

Finding Projects as a Freelance Software Developer

Three years ago aged 45, I started as a freelance software developer in Southern Germany. It were three pretty amazing years. I had paid work for 522.5 days of 750 working days, which amounts to nearly 70% of total working days. My hourly rate was roughly 94 Euros with 8 hours per day. Additionally, I passed on 285 days of work to other developers at a rate of 61 Euros. Despite this success, finding projects still feels a bit like black magic. Sometimes I could have got three projects at the same time. Sometimes I struggled for several months to find the next project. I want to share my experience in finding projects: what worked for me and what didn’t.
Continue reading