Planning a robotics software project.

Describe one useful outcome.

Start with the person using the application and the job they need to do. “An operator can start a product conversation using this customer’s approved documents” is easier to scope than “make the robot intelligent”.

For a first build, choose a representative interaction or workflow. Include the expected result, the conditions it needs to work in and what the operator should do when something goes wrong.

Bring the exact robot details.

Share the manufacturer, model, edition and software information you have. Identify the SDK or application interfaces available to your team and who can provide access to the robot for testing.

For a Unitree G1 project, we review the customer’s configuration and access before confirming an integration. Work on one configuration does not establish compatibility with every G1 edition or another manufacturer’s robot.

• Available hardware, test location and operator contact.
• SDK/API documentation and the interfaces you are permitted to use.
• Network and audio arrangements for a voice application.
• Approved documents, sample inputs and any existing application.

Use the initial brief to describe access; credentials and confidential records do not belong in a public enquiry.

Decide what the simulation must answer.

A motion preview can help a team review poses and timing. A physics simulation can examine behaviour under a specified model and assumptions. An application test environment can exercise commands, status and an operator workflow.

These are different deliverables. Agree which question matters, which inputs are available and how the result will be assessed. A convincing animation alone does not demonstrate physical balance or successful execution on hardware.

Know what changes the cost.

The main scoping questions are how much new integration is required, how available the hardware and documentation are, and how much testing and handover the customer needs. Model usage, hosting and continuing support may be separate costs.

A useful proposal identifies the deliverable, customer dependencies, exclusions, acceptance criteria and payment milestones. Where feasibility is uncertain, a paid assessment can establish the next development scope.

We quote after reviewing the brief. A motion prototype, a connected voice application and a customer portal need different estimates.

Agree how you will review the result.

Choose representative inputs and operator actions before development starts. For voice, that might be an approved question set and checks for unavailable information. For a portal, it could include preparation, start/stop and connection-loss behaviour. For simulation, define the experiment and the observations to report.

Agree who receives the project files, configuration, documentation and training. If physical robot testing is needed, include its access, responsibilities and acceptance conditions as a distinct milestone.