Skip to content
Rover simulation · application of LunCoSim

Find the traverse that fails before the vehicle does.

A rover can have enough wheel torque and still fail when slope, motor load, battery state, temperature and autonomy interact. LunCoSim lets you test that mission question in one run.

Mission-first — start with the route the mission requires Connected study — mobility, resources and autonomy together
ONE ROVER · FOUR CONNECTED MODELS · ONE RUN Drivetrain & suspension rigid bodies · rocker-bogie differential wheel contact · surface friction → torque demand, wheel slip Power bus battery · solar power · drive motors load changes affect available power → bus voltage, state of charge Thermal case masses · conductors · radiators thermostatic heaters on the same bus → component temperatures Autonomy repeatable scenarios · mission decisions waypoints, sensing, anomaly response → drive and steer commands A steeper slope needs more torque, draws more current and leaves less power and thermal margin for the mission.
The result you need is not wheel torque alone. It is whether the rover can finish the traverse with usable power, thermal margin and a controller that still knows what to do.
Mission question

Will the rover finish the traverse with margin?

A traverse requirement is more than distance. It includes terrain, payload, energy, communications and autonomy. A drivetrain test or battery budget alone cannot tell you whether the rover can complete it.

Start with the outcome: reach the site, deliver the payload, preserve the link or return with margin. A slope can increase torque, torque can increase current, current can lower bus voltage, and heat can reduce performance before autonomy reacts. The mission result depends on that chain, not on any one subsystem report.

Put mobility, power and thermal behavior in the same run so a design change updates its consequences immediately. That gives the team one result to review instead of another spreadsheet and integration meeting.

What the study includes

Change the variables that decide the traverse.

Compare rover and route variants without rebuilding the study each time. Change the variables that matter and keep the same mission assumptions across runs.

Suspension See whether the suspension keeps the wheels in contact as the rover crosses the route. Change spring, damper and rest-length settings per wheel.
Drivetrain Check whether the powertrain can deliver the torque the route demands. Change the motor, gearbox or axle and compare the result with the same rover.
Traction Compare how tire and surface friction change the route outcome. Use the same friction behavior wherever that tire is used.
Rocker-bogie Check how chassis articulation changes the rover’s response to terrain. The simplified joint model keeps the study fast enough to compare variants.
Mass properties Keep mass and inertia aligned with the design you are comparing. The values remain visible in the scene instead of hiding in code.
Live tuning Change wheel and joint parameters while the scenario is running, then see the effect without restarting the study.

Flag incomplete configurations before they distort a comparison. Missing rover data is reported instead of silently filled with an unreviewed default.

Confidence

Choose the right level of detail.

Use the model to compare route and vehicle choices. Its response is checked against reference behavior, so the team can see where it is useful and where specialist analysis should take over.

Mission loop Compare route, vehicle and resource choices in one run.
Inspectable Trace geometry, contact, power, thermal behavior and control.
Reference-checked Compare the rover response with continuous reference behavior.
Specialist-ready Know when wheel–soil or structural detail should be studied elsewhere.

Use the result to decide which route or rover configuration deserves deeper component analysis. Use specialist structural or wheel–soil analysis when that detail becomes the decision.

From requirement to run

Find the route and configuration that work together.

Start with the mission requirement, build only the model needed to answer it, then repeat the run as the rover or route changes.

Define the mission outcome

Define the route as waypoints, payload, energy, communications and failure behavior. Start with what the rover must accomplish, not a list of parts to build.

Start from a working rover

Use one of the shipped configurations or bring your own. The shared scene keeps geometry, wheel layout and system assumptions together, so a variant is easy to compare with the baseline.

Connect the consequences

Let mobility, electrical and thermal behavior respond to the same rover state. A motor-load change can affect power, temperature and autonomy without a second hand-maintained integration model.

Choose the ground that matters

Load terrain data from the site and study the slopes, lighting and surface conditions behind the route decision instead of relying on a generic test surface.

Run the mission behavior

Give the rover waypoints, sensing and failure responses, or control it directly. The same command interface supports a person, a script or an AI agent.

Find where the plan stops working

Vary slope, tire, battery capacity or heater settings and identify the routes and configurations that fail before you commit to hardware or operations.

Where to go deeper

Use specialist detail when it changes the decision.

This page focuses on rover studies. See the platform overview for the broader mission workflow.

Wheel–soil detail belongs in specialist analysis

The rover contact and friction model is built for whole-route studies. Pair it with soil analysis when sinkage, drawbar pull or detailed lunar-soil behavior changes the decision.

Use structural analysis for component loads

Use LunCoSim to compare rover behavior and mission margins. Bring in structural analysis when flexible structures, wheel deformation or component loads change the design.

Add detail when it changes the decision

Use this rover model for fast, inspectable comparisons. Add component detail when it changes the design choice.

Qualification remains a separate step

Use the simulator to explore the range of conditions and rehearse mission behavior, then use formal verification and acceptance testing for qualification evidence.

Next

Test the rover question that matters.

Start with a traverse, a vehicle trade-off or an autonomy question. Run the connected case, inspect what changed and decide where higher-fidelity analysis is worth the effort.

Also studying descent? See lander & powered descent.