CoVAPSy Autonomous Vehicle

Case Study

CoVAPSy – 1/10-scale Autonomous Vehicle. CoVAPSy is a collaborative team competition run by ENS Paris-Saclay; this case study describes Mehdi Bouama’s contribution to the navigation and control software for the team’s 1/10-scale race vehicle, built on a Raspberry Pi 4 with an RPLidar A2M12.

Context & Challenge

CoVAPSy 2026 required a small autonomous vehicle to navigate a track reactively from lidar data alone, without a pre-built map, while staying responsive enough to avoid getting stuck against track boundaries and other obstacles; the vehicle is designed to stop safely when lidar data goes missing or becomes stale.

Scope & Responsibilities

CoVAPSy is a collaborative team project; the complete vehicle and competition entry are not solely Mehdi Bouama’s work. This case study describes the navigation and control software: the reactive Python control loop, the lidar acquisition and consumption pipeline, the navigation and speed laws, the lidar watchdog, and the stuck-recovery logic, as published in the public repository.

Architecture / System Design

A background thread performs continuous 360-degree lidar acquisition; the main control loop polls the latest scan through a non-blocking consumer with freshness tracking, computes a direction and a speed from it, and drives an ESC and a servo through hardware PWM. An optional sonar thread runs in parallel and is read only during a reverse manoeuvre. The direction law is a normalized left/right lidar-sector difference, clamped to a fixed maximum steering angle; the speed law is exponential in the same left/right imbalance and scaled by a minimum frontal clearance, so the vehicle slows both in sharp turns and when something is close ahead.

Implementation

The control loop is configured to run at a fixed rate; see Verification & Evidence for how that figure is classified. A lidar watchdog tracks scan freshness and, once a scan is stale beyond its configured timeout, forces steering and propulsion to zero rather than continuing to act on outdated data. A stuck-recovery routine watches the minimum frontal distance and, once it stays too close for enough consecutive control ticks, triggers a blocking reverse manoeuvre – an ESC double-tap sequence with an escape angle chosen from the wider side gap – which the sonar thread can cut short if a rear obstacle is detected. Every tick is logged to CSV telemetry for later inspection.

Verification & Evidence

The control loop runs at a configured rate of 50 Hz: this is a source-level constant confirmed by static review of the published code, not a timing measurement taken on the running vehicle, and it does not by itself establish hard real-time or worst-case-deadline behavior. The safety mechanisms above – parameter validation at startup, the lidar watchdog, stuck recovery, and unconditional actuator shutdown – are likewise true by source review, as is the hardware interfacing: true. The public repository’s lint workflow: true, a style check, not a functional or on-vehicle test.

Results

The published source establishes a reactive navigation and control stack with a configured 50 Hz loop rate, lidar-based direction and speed laws, and layered safeguards inside the control loop (lidar-staleness watchdog, stuck recovery, actuator-stop routine in a finally block). No on-track lap-time, benchmark, or competition-placement claim is made here, and no hard real-time or guaranteed worst-case-timing property is claimed for the control loop.

Limitations

This case study describes only the navigation/control software as published in the repository, not the vehicle’s electrical or mechanical design, not the rest of the team’s contribution, and not a validated physical-system test report: the classification above reflects a static source review, not on-vehicle measurement or ROS/HIL-based validation, neither of which is established here. The watchdog and stop logic execute within the same main control loop; no independent watchdog process or hardware watchdog is established, so a freeze of that loop is not covered.

Key Takeaways

A reactive controller with no map is only as trustworthy as its failure modes: the watchdog and stuck-recovery logic execute within the main control loop to act on lost or stale lidar while that loop continues to run, but this does not establish protection against the loop itself blocking. Writing this case study also meant being careful about a configured constant versus a measured one – a 50 Hz loop rate in source code is not the same claim as a timing-verified 50 Hz on the physical vehicle, and about scope – describing one contributor’s software work inside a team competition without overstating it as the whole vehicle.

Artifacts / References

Public repository: github.com/mahdidou711/mahdidou711-covapsy.