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.
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.
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.
Flag incomplete configurations before they distort a comparison. Missing rover data is reported instead of silently filled with an unreviewed default.
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.
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.
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.
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.
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.