Mobile apps and robotics: what belongs on the phone?

“Can we control it from a phone?” sounds like a small feature request. The interesting question is what control should mean.

Does the person want to check the robot’s status, request a task, adjust a setting, or drive it manually? Each needs a different interface and different behavior when communication stops.

This article is a general design discussion using hypothetical examples. It doesn’t describe a particular robot or client implementation.

Start with one operator task

Imagine an app where an authorized operator selects a saved destination and requests a robot task. I’d scope that journey before adding a map full of controls.

The operator needs to choose the correct robot, understand whether it is available, submit the request, and see what happens next. A good first screen might be quite simple if it answers those questions clearly.

Manual driving is a separate requirement. It shouldn’t be slipped into the same estimate as a status dashboard merely because both use buttons.

Give the app a clear boundary

For this example, I would put operator interaction on the phone and keep motion execution and protective behavior within the robot system. The phone could communicate through an authenticated application interface whose supported operations are explicitly defined.

That boundary gives the mobile developer a contract to implement. It also lets the robotics team change internal components without exposing every internal message to the app.

Technologies such as ROS 2, Nav2, SLAM, LiDAR, and Gazebo may appear in the broader robotics stack. Listing them doesn’t define a mobile integration. The useful specification still needs to say which requests the app can make and which statuses it can receive.

Show acceptance, progress, and completion separately

A request reaching the robot doesn’t necessarily mean the task has finished, or even that it has been accepted.

ROS 2 actions provide a useful reference for long-running work: a goal can be accepted or rejected, feedback can describe progress, and a result reports the outcome. Cancellation is a request with its own handling, rather than an immediate guarantee of completion. ROS 2 action design

An app-facing interface can preserve those distinctions without exposing ROS message details to the person holding the phone. For our hypothetical journey, the screen could show:

Sending request
Task accepted
Task in progress
Task completed, failed, or canceled

Those are interface labels, not a complete implementation. Add separate states for rejection and unavailable status. Only show a percentage when the system has a meaningful way to calculate it.

Decide what happens when the phone disconnects

If the app loses contact halfway through a task, it no longer knows the current outcome. “Connection lost, task status unavailable” is more accurate than declaring success or failure.

The robotics team must define whether the robot continues, pauses, or follows another behavior when communication disappears. That decision depends on the operation and environment. Closing the app should never be the accidental mechanism that determines it.

When communication returns, the app should retrieve the existing task’s state using its identifier. Automatically sending the same request again could start duplicate work.

Treat cancel as a real interaction

If the operator taps Cancel, show that cancellation was requested while waiting for confirmation. If the request is rejected or communication is lost, explain the actual state available to the app.

A normal mobile cancel button should not be presented as an emergency stop. The system’s protective mechanisms need their own design and validation; a phone interface and its network connection cannot establish those properties by appearance alone.

This matters to the wording as much as the implementation. “Cancel requested” and “Robot stopped” make different promises.

Review the integration in stages

I’d begin with a simulated or mocked task interface to review the screen states. Then I would test the agreed operations against the robotics system, including rejected requests, delayed feedback, lost connections, and cancellation outcomes.

If a simulator such as Gazebo is part of the project, record which behaviors were tested there. Keep physical-hardware validation as a separate milestone, because a simulation demonstration doesn’t establish how the complete physical setup behaves.

The most useful mobile robotics app isn’t necessarily the one with the most controls. It’s the one that lets an operator understand the task and make an informed next decision.

The same attention to current state applies to connected sensors. See designing an honest IoT dashboard for a smaller example of freshness, confirmation, and uncertain outcomes.