Electric and autonomous vehicles need more than a vehicle model. They need a dependable description of the places where the vehicle will operate: road surfaces, open drains, flood-prone sections, charging points, access rules and the uncertainty attached to each observation. That infrastructure can begin as software and data before a team owns a robot or vehicle.

Start with a scene contract

A useful scene pack states its source, coordinate system, landmarks, roads, hazards and linked tasks. The 9jaRobotics scene lab accepts a small, validated scene format and can import permitted GeoJSON. It projects geographic coordinates into local metres for scene inspection and export. Start with the example geometry or import your own attributed scene.

For a Lagos or Abuja pilot, begin with one operational question: can a delivery vehicle reach a clinic while avoiding a reported open drain and preserving a battery reserve? A compact scene can represent the clinic, depot, charging bay and hazard, then carry the same geometry into an editable Webots starter world.

Collect the observations that routing needs

Start with a collection brief on 9jaTesters. A useful road observation can include surface type, flood depth, clearance, a timestamp, confidence and charger status. Keep these observations and their review records alongside your scene. They supply evidence for a later planner experiment; static scene geometry alone does not establish route suitability.

  • Road surface: paved, patched, rough or unpaved.
  • Local hazards: pothole cluster, open drain, flood section or temporary closure.
  • Charger state: location, connector or access note, availability timestamp and queue observation.
  • Vehicle constraints: ground clearance, starting charge and minimum reserve.
  • Provenance: contributor reference, capture method, permission and review status.

Collection, annotation and human review requests go through 9jaTesters. Define the permitted recording locations, required evidence, reviewer acceptance criteria and observation freshness in the brief. Contributors can join the workforce there. Begin with one agreed collection before expanding coverage.

Connect maps to model evaluation

Map geometry alone does not test whether a model understands a Nigerian instruction. Use the task benchmark for its supported command contract: navigate to reception, room-01, store or charger, stop, or request clarification. A richer mobility question needs its own destination labels, hazard constraints and evaluation contract. Preserve the reviewed observation, scene version and model output together so the result can be reproduced.

Use Webots as the next handoff

When a scene is stable enough to inspect, export the editable .wbt starter world and attach a robot model and controller in Webots. The exported world contains static geometry and source notes. It does not include a live map feed, vehicle dynamics, sensor noise or a safety-tested controller. Those are the next experiments to specify.

This staged path creates a useful local asset: permissioned observations become versioned scene packs, scene packs become repeatable route and task tests, and only then do teams decide which physical hardware is worth acquiring. Read the simulation guide for the smaller browser lab and the human-video guide for the boundary between demonstrations and robot measurements.

Bring people into the project

Use 9jaTesters to request collection, annotation, testing or human review. Describe the task, volume, location or languages, and acceptance criteria in your brief. For contributor opportunities, join the 9jaTesters workforce.