Project File / 21st National Undergraduate Smart Car Competition · National Finals Second Prize
CongCar Smart Vehicle Project Experience
A team autonomous-vehicle project. I participated continuously in architecture discussion, scene-logic refinement, on-vehicle debugging, and validation for real-time perception, path following, and scene decisions on RK3588.
- Autonomous vehicle
- RK3588
- Computer vision
- Real-time systems
- Control
CongCar is a team project for autonomous driving on a closed course. An RK3588 upper computer continuously runs image acquisition, semantic segmentation, object detection, bird’s-eye path processing, scene decisions, and chassis control, communicating with the lower controller over serial.
The team received the Second Prize at the national finals of the 21st National Undergraduate Smart Car Competition. This page describes my participation, the engineering problems I worked through with the team, and the limits of the available evidence; it does not present the team result as individual work.
Role and scope
Most later code changes were committed from a teammate’s computer and repository. Git authorship therefore does not capture all design discussion, debugging, and validation work. I continuously participated in upper-computer architecture and scene-logic discussions, analysed observed course behaviour, took part in logic and parameter adjustments, and verified decisions during vehicle testing.
My particular focus included the risk and parameter logic for pedestrian handling: separating object detection from entry into a vehicle-risk region; considering vehicle-centre offset, detection persistence, stopping conditions, and resume conditions. I also participated in discussion and field debugging of line following, forks, and traffic-sign behaviour. The multithreaded framework, model deployment, scene implementations, and control modules were maintained by the team; I do not claim to have implemented them independently.
System architecture
The upper-computer software uses C++, OpenCV, and RKNN. Its processing chain consists of camera acquisition, semantic segmentation, object detection, bird’s-eye path extraction, shared PathFollower control, scene constraints for obstacles, pedestrians, forks, and traffic signs, and serial commands to an STM32 lower controller.
Tasks are separated and share the newest available state so that control does not wait for a backlog of old frames. For a moving vehicle, model FPS alone is insufficient: data freshness at control time, continuity across scene transitions, and recoverable abnormal behaviour are equally important.
The on-course dashboard relates vehicle behaviour to current perception, bird’s-eye paths, speed, and model status. Local inference FPS is not treated as a substitute for end-to-end system behaviour.
Engineering decisions
Shared path following
Keeping centre-line extraction and steering logic separately in normal driving, obstacle, pedestrian, and fork scenes led to divergent parameters and coordinate conventions. The team consolidated bird’s-eye paths, look-ahead references, and control calculations in PathFollower; scenes contribute only their constraints, such as masks, follow-edge choice, stopping, or resuming. This reduces duplicate logic and preserves control state across scene changes, while increasing the need to test a shared-module change across all affected scenes.
Traffic signs within explicit state boundaries
Traffic-sign handling is more than text recognition. The later implementation uses explicit stages for approach, backup, waiting for a visual-language decision, and driving again. A direction needed once for the course is saved and reused in later occurrences. Once a right turn is determined, a bounded blind-driving action with fixed speed and steering is used until the course is recaptured and normal path following resumes.
Pedestrian detection as a risk state
Stopping for every one-frame person detection is vulnerable to distant targets, targets outside the intended path, and transient false positives. The pedestrian scene therefore combines bird’s-eye projection of the detection box, planned path, risk region, follow edge, and state duration. I participated in analysing and tuning vehicle-centre offset, the risk region, and resume conditions. Stopping and resuming are deliberately asymmetric: potential risk is held conservatively, while restarting requires more stable evidence. Standardised measurements such as false-stop rate and resume-time distribution are not yet available.
Validation and current limits
Vehicle and course tests were the primary validation environment. Perception output, bird’s-eye paths, reference points, and control state were visualised together to distinguish perception, path, scene-transition, and control issues. Work generally followed a cycle of observation, hypothesis, logic or parameter adjustment, and retesting on the vehicle.
The national second-prize result shows that the integrated perception, decision, and control loop completed the competition task. It does not establish stability under every condition. Further work should add unified end-to-end timestamps, replayable failure cases and configurations, repeated metrics by speed and scene, and clear boundaries between software stop, active braking, and hardware emergency stop.