Greendorph Robots

Most operators are older city sanitation workers employed by the companies that buy Greendorph’s service. They need an app that is easy to navigate, uses plain words instead of technical terms, and doesn’t put too many actions on a single screen.

The original app worked against them in three ways. Functions were hard to find. The structure followed the machine rather than the work, grouping functions in a way only the engineers understood. And the app assumed prior knowledge, with nothing to explain what the robot could do or how to control it.

During testing, workers kept asking us where settings were and how to drive the robot manually to record a map. After those first visits I had few chances to return to the sites, so field support became my link to operators, regularly passing on how the app was used and where people got stuck.

I built this diagram in my first weeks, after learning how the robot is operated and how the whole system works. Setup runs through three phases. The site is mapped with the local app, virtual walls and tasks are deployed, and the result is tested. Deployment has two branches. Remotely, map data is pulled onto the platform and edited before being sent back. On site, the operator records precise routes and function points with the local app.

Seeing every map pass through the remote team before it is deployed later shaped how the redesign treats maps.

This is a B2B2C product. Choosing a site and robot serves the cleaning company in the middle, while the rest of the app serves its workers and the sanitation workers in the field, so the app never controls just one robot. Throughout the redesign I met regularly with the engineers and field support. Field support brought client feedback, and the mechanical engineers brought technical requirements and constraints, which kept the structure within what the robot could actually do.

With older operators in mind, each screen keeps to a few actions and uses plain words instead of technical terms. Recovery states sit outside the four tabs and open only when needed, such as after a lost connection, an obstacle wait, a localization problem or an emergency stop.

The original home screen reflects how the engineers thought about the robot, with tasks in one place and maps in another. A new operator had to know in advance which category held the next step.

The refined task setup gathers everything needed to prepare one job, so the next decision is visible without searching.

This adds steps between recording a map and using it, at a point where workers want to get started. But a map that doesn’t match the site, or a route that crosses a pre-set limit, is exactly the failure workers were dealing with on site. A clear status on every map makes the wait understandable. A verified map goes straight to positioning, and an unverified one says it will open for tasks once it passes verification.

The same reasoning keeps operating parameters read-only for operators. The remote team sets and checks those limits, so field workers can see them but can’t change them.

A one-tap control would be faster, but these commands move a real machine in public spaces, so an accidental tap or an unnoticed fault matters. The confirmation step is where the operator checks the robot and the site, and the pending state stops the app from showing a job as running or paused before the robot has confirmed it.

Pausing keeps the job’s progress and never resumes on its own. Before resuming, the operator checks the site, connection and robot position, so the job continues from where things actually stand.

Positioning matches the map to the site before any task can start. Starting a job runs through the readiness checks, and pausing and resuming show each pending and confirmed state as it happens.

The dashboard uses driving mode, speed and resource gauges to show the machine’s status. On the panel, cleaning functions share a consistent icon and on/off pattern, with power and emergency stop set apart.

Working on a physical machine changed how I thought about controls. Operators drive the YJ80 largely from muscle memory, so the panel has to stay consistent and predictable. The photograph of the panel in use shows its physical scale and how the screen and buttons sit within reach of the operator.