From software to hardware: a building-washing drone and Raspberry Pi displays

01The building-washing drone

In this project, the drone's physical design had to be thought through together with its software, processing unit and communication infrastructure. ROS and an NVIDIA Jetson Nano formed the software and processing side, and I built the technical structure, including the fiber infrastructure, together with the drone's design. From design to technical infrastructure, the whole responsibility was mine.

design         → building-washing drone
software       → ROS
processing     → NVIDIA Jetson Nano
infrastructure → fiber

In web projects you can think about one layer independently of the others. Here that was not possible: a mechanical decision affected the processing unit, the processing unit affected the software, and the software affected the communication needs. I had to approach the project not as a single component but as a complete system from the start.

What struck me most in this project was the order of decisions. In a web application most decisions can be undone later; swapping a library or rewriting a service takes time, but it is possible. In a physical system, some decisions set the frame for the others, and going back is far more expensive. So treating design and technical infrastructure together was not a preference from the start, but a necessity.

02ROS, Jetson Nano and fiber together

ROS provides a framework in which the different software parts of a robotic system can talk to each other. The Jetson Nano is the processing unit this software runs on. The fiber infrastructure is part of the system's technical structure. I needed to think of these three not as separately chosen parts but as connected layers of the same system; a decision about any one of them also set the limits of the others.

For me, the part of robotics most similar to web development was the need to separate responsibilities. Splitting software into distinct tasks helps you change one part without breaking the whole. The difference is this: here every software decision also has a physical counterpart.

03Raspberry Pi advertising displays

The second project is more modest but just as holistic: digital displays running on a Raspberry Pi 4, used for advertising and promotion in cafés and markets. The displays are managed from a phone application. I built the display software, the mobile control and the device's technical infrastructure together.

The venue's digital shop window, managed from the phone in your pocket.

The real work was making the display's behavior in the venue and the management flow on the phone serve the same need. For the business owner, it had to be one system, not two separate products.

For a display in a venue, web habits alone are not enough. A web page can be closed and reopened; a display in a venue is a device expected to stay on all day and keep running on its own. For devices like this, it seems more accurate to me to think of the display software not as a separate application, but as part of the device itself.

The questions I think about in a system like this are a little different from those in web projects. The display runs in a venue, often in a corner where nobody stands next to it, while management happens from a phone held in someone's hand. In between there is a device, a connection and an application, but the user does not want to see any of them separately. They want to see what they changed on the phone show up on the screen. I treated the device side and the application side together around that simple expectation.

04Two sides of working alone

In both projects, the whole responsibility from design to technical infrastructure was mine. That has an advantage: you know every part of the system and can predict where a decision will land. But you are also the one who decides at every layer; the person writing the software, the person thinking about the hardware and the person asking questions on the user's behalf are the same. This taught me to own decisions outside the area I was used to.

Another risk of working alone is blind spots. You have to ask yourself the questions someone else on a team would ask. So when I work on a layer, I try to look at it through the eyes of the next layer that will use it: what does the software expect from the processing unit, what does the phone application expect from the display?

05The same line, continued

I followed a similar approach in a vehicle tracking system I developed as an individual IoT project: an embedded application running on a Raspberry Pi that shows live GPS, an interactive map, and speed, signal strength, battery and sensor data in one interface. There too, the interface had to stay smooth while keeping the data from the hardware up to date.

Looking back at these projects, the common thread is clear: whether it is a display, a drone or a vehicle, the behavior a user sees is the result of many layers working together. Having seen all of those layers still helps me today when I work on the web and service side.