LAB · 01 / 09

MOVER in data

The capstone campus as data: what was measured, what was assumed, why each choice and what it delivered. data analysis · provenance · real glTF

Visual Light How it works ↓

How it works

Visual mode: warm sun and cool sky with shadows, ambient occlusion, bloom on the route and quality that adapts to your device. Light mode: no shadows or post-processing. The full data analysis is right below.

Sheet of each analysis

Objective, why, target variable, predictors, method, metric, validation and whether the objective was reached.

Picking the right source

Objective: Pick the data source able to produce a simulator map.
Why: A map without height per point has no profile or slope; starting from the wrong source would invalidate the rest of the project.
Target variable: Layers with 3D points useful to the pipeline.
Predictors / explanatory variables: Layer thematic group, entity count, points with Z.
Method: Programmatic DXF inventory (ezdxf) and classification by naming convention.
Metric: Used layers ÷ total; entities per group.
Validation: 2D plan discarded for having Z = 0 in every entity.
Objective reached?: Yes: 19 of 202 layers carry the whole map.

Measured or synthetic

Objective: Separate what was measured from what was assumed.
Why: The committee and team need to know which number to trust; mixing measured and assumed values without labels hides error.
Target variable: Origin of each element (measured × synthetic).
Predictors / explanatory variables: Map element, source, standard used.
Method: Provenance table generated by the pipeline.
Metric: Measured × synthetic elements.
Validation: Each synthetic value cites its standard (CONTRAN, traffic code).
Objective reached?: Yes: geometry measured, signage synthetic and declared.

The terrain the truck feels

Objective: Measure the truck route’s terrain.
Why: Grade changes braking and safe speed; assuming a flat road would give wrong control.
Target variable: Altitude and grade along the route.
Predictors / explanatory variables: Distance travelled, speed-bump positions.
Method: Grade = Δz ÷ Δs between neighbouring path points.
Metric: Elevation change (m) and grade (%).
Validation: Speed bumps placed by measured coordinates, not by hand.
Objective reached?: Yes: 846 m and 14.6 m of elevation change.

One station per metre

Objective: Replace fixed values with real sidewalk and slope measurements.
Why: Wrong sidewalks and slopes make the simulated car climb curbs or slide in bends.
Target variable: Sidewalk width and cross slope per station.
Predictors / explanatory variables: Road, position along the axis, Z of both curbs.
Method: One station per metre; 50% coverage rule to emit slope.
Metric: Median, p90 and coverage per road.
Validation: Roads below 50% complete stations stayed flat and declared.
Objective reached?: Yes: 7 of 9 roads with measured slope.

The object funnel

Objective: Decide which surveyed objects go into the simulator.
Why: Every object costs performance; only what the truck’s sensors can see is worth including.
Target variable: Objects per funnel stage (campus → 30 m → CARLA → web).
Predictors / explanatory variables: Category, distance to road, actor cap.
Method: Distance filter and cap; 8 m spatial sampling on the web.
Metric: Counts per stage.
Validation: Trees on buildings or roads removed before sampling.
Objective reached?: Yes: 1,743 → 1,104 → 733 → 415 trees.

Heights: measure where possible, declare where not

Objective: Give every building a height without inventing measurements.
Why: LiDAR and cameras see buildings; a wrong height changes the scene, and an invented one would look measured.
Target variable: Each building’s height and its origin.
Predictors / explanatory variables: Surveyed roof height, number of floors.
Method: Measured when a height exists; 2 floors × 3.5 m otherwise, flagged as assumed.
Metric: Measured × assumed buildings.
Validation: Assumed ones form a line at 7 m in the chart, visible as an assumption.
Objective reached?: Yes: 12 measured, 16 assumed and declared.

Ten rounds, each one measured

Objective: Prove with numbers that each round improved the map.
Why: "Looks better" does not close a capstone; fixed indicators per round catch regressions the eye misses.
Target variable: Parking-spot position error, hole in the CARLA mesh, triangles.
Predictors / explanatory variables: Pipeline round (r1–r8).
Method: Same indicator table at the end of each round; emulation of CARLA’s generator.
Metric: Metres, m² and counts.
Validation: Validation in the final consumer (CARLA), not only in the own viewer.
Objective reached?: Yes: error 19.04 → 1.78 m; hole 1,124.8 → 0 m².

The lap in the simulator

Objective: Confirm in the simulator that the new map runs better.
Why: A map is only worth anything if the truck drives on it; a fair comparison needs the same lap, camera and weather.
Target variable: FPS, RAM, holes, steps, void, collisions, cross-track error.
Predictors / explanatory variables: Map round (r9 × r10).
Method: Controlled lap with 10 fixed ray-cast checkpoints.
Metric: r10 − r9 difference per metric.
Validation: Same parameters in both rounds; RAM sampled every 10 s.
Objective reached?: Yes: 100% of the route, 0 collisions, FPS 15.1 → 18.0, holes 4 → 0.

The result that did not work (yet)

Objective: Measure whether the LiDAR detects the real speed bumps.
Why: Claiming detection without measuring would be the project’s most expensive mistake; measuring shows what data is missing.
Target variable: Speed-bump event detected.
Predictors / explanatory variables: LiDAR events, positions of the lap’s 4 bumps, 4 m radius.
Method: Count of hits and false alarms.
Metric: Recall and precision.
Validation: First lap with real bumps on the path.
Objective reached?: Not yet: recall 2/4 and precision ~6%; next step is recording the raw LiDAR cloud.

One datum, one source

Every number in the map is either MEASURED in the topographic survey or SYNTHETIC from a standard, and the provenance table says which. In the model, blue buildings have measured height; orange, assumed.

Same frame

Route, trees and buildings come from different pipeline files and line up because they all go through the same survey-to-scene coordinate transform.

cena = (X − 232, Z − 741, −Y + 233)

Grade

The route colour is the grade between neighbouring points of the real path, on a diverging scale: blue goes down, grey is flat, orange goes up.

rampa = Δz / Δs · 100 %

Generated, not typed

A script reads the capstone tables (read-only) and generates this page’s JSON. The only hand-copied numbers are the CARLA lap report figures, with their source next to them.

MOVER told by its data

The autonomous truck’s digital twin started as a 172 MB CAD file. This page follows the data from the survey to the simulator lap: what each table answered, why each choice was made and what it delivered in numbers. Rule of the whole project: every value is MEASURED or SYNTHETIC, and the two are never mixed without saying which is which.

66,039entities in the survey

19layers used out of 202

1,217measurement stations (1 per metre)

1,743surveyed trees

0collisions on the live lap

Picking the right source

QuestionCould the file we had become a simulator map?

Decision and whyNo. The architectural plan was 2D: every Z equal to zero and heights only as loose text. Without height per vertex there is no road profile and no cross slope. We switched to the original survey DWG, converted to DXF, and read everything through a library (ezdxf), because the GUI importer froze on the 172 MB file. The layer naming convention became the key of the pipeline.

Result19 of the 202 layers carry the whole map. The chart shows why: most entities are buildings and altimetry, and there is no layer for crosswalks, traffic lights or STOP signs. The survey is topographic, not a road survey.

Source: saida9/analise/layers.csv

Analysis technical sheet

Objective: Pick the data source able to produce a simulator map.
Why: A map without height per point has no profile or slope; starting from the wrong source would invalidate the rest of the project.
Target variable: Layers with 3D points useful to the pipeline.
Predictors / explanatory variables: Layer thematic group, entity count, points with Z.
Method: Programmatic DXF inventory (ezdxf) and classification by naming convention.
Metric: Used layers ÷ total; entities per group.
Validation: 2D plan discarded for having Z = 0 in every entity.
Objective reached?: Yes: 19 of 202 layers carry the whole map.

entities
in used layers

Measured or synthetic

QuestionWhen the data does not exist, what goes in its place?

Decision and whyA cited standard, never a guess, and flagged as SYNTHETIC. Road paint and crosswalks follow the Brazilian Traffic Signs Manual (CONTRAN); the 30 km/h limit comes from the traffic code for local roads; the speed bump is 8 cm, within the standard’s usual range. This way the committee and the team know which number to trust.

ResultRoad geometry, sidewalks, slope, speed bumps and object positions are measured. Signage is synthetic. In the model above, the "Measured × assumed" layer shows the same split on the buildings.

Source: saida9/analise/procedencia.csv

Analysis technical sheet

Objective: Separate what was measured from what was assumed.
Why: The committee and team need to know which number to trust; mixing measured and assumed values without labels hides error.
Target variable: Origin of each element (measured × synthetic).
Predictors / explanatory variables: Map element, source, standard used.
Method: Provenance table generated by the pipeline.
Metric: Measured × synthetic elements.
Validation: Each synthetic value cites its standard (CONTRAN, traffic code).
Objective reached?: Yes: geometry measured, signage synthetic and declared.

largura de calcada	measured	variavel, 0 a 3,00 m
altura da calcada	measured	0,163 m = 0,111 + 0,052
superelevacao	measured	-2,8 % a +4,5 %
largura da sarjeta	measured	mediana 0,40 m (18 lados)
lombadas	measured	6 objetos, 1,45-1,71 x 9,3-12,6 m
sarjetoes	measured	2 objetos em R01
posicao dos props	measured	2 076 pontos
largura da pista	measured	4,6 a 9,7 m
eixo das vias	measured	9 roads, 1,1 km
pintura de faixa	synthetic	LBO contInua, LMS-1 2/4 m, LFO-1 amarela, 0,10 m
limite de velocidade	synthetic	30 km/h (o CARLA so tem placa de 30 a 130)
faixas de pedestre	synthetic	16 objetos nas aproximacoes
avental lateral	synthetic	shoulder de 1,5 m
altura da lombada	synthetic	0,08 m
altura/raio dos props no 3D	synthetic	arvore 2,6 m de tronco + copa de 2 m

The terrain the truck feels

QuestionIs the ring flat enough for a simple speed profile?

Decision and whyWe measured the altitude at every point of the real path (gate entry, ring and exit) instead of assuming a flat road. The grade between neighbouring points shows where the truck climbs and descends; the speed bumps sit at their measured positions.

ResultThe route is 846 m long with 14.6 m between its lowest and highest points. Control and the speed profile have to handle that climb, which is why the map carries the real elevation instead of a flat road.

Source: dados_origem/mapa/trajeto.csv (rodada 10)

Analysis technical sheet

Objective: Measure the truck route’s terrain.
Why: Grade changes braking and safe speed; assuming a flat road would give wrong control.
Target variable: Altitude and grade along the route.
Predictors / explanatory variables: Distance travelled, speed-bump positions.
Method: Grade = Δz ÷ Δs between neighbouring path points.
Metric: Elevation change (m) and grade (%).
Validation: Speed bumps placed by measured coordinates, not by hand.
Objective reached?: Yes: 846 m and 14.6 m of elevation change.

altitude (m)

grade (%) (±12 %)

distance along the route (m) · ● speed bump

One station per metre

QuestionUse a fixed 2 m sidewalk and a flat road, or measure?

Decision and whyMeasure. Each road got one station per metre with the sidewalk width on both sides and the cross slope taken from the Z of both curbs. Cross slope was only emitted on roads where at least half of the stations had both curbs measured: with one side only, a single curb would drive the result.

ResultMedian sidewalk of 1.61 m (p90 2.25 m), not 2 m. Median cross slope of -0.14 %, almost flat, between -2.65 % and 1.64 % in 90 % of the stations. 7 of the 9 roads got cross slope; the other 2 stayed flat and declared as assumed.

Source: dados_origem/analise/estacoes.csv

Analysis technical sheet

Objective: Replace fixed values with real sidewalk and slope measurements.
Why: Wrong sidewalks and slopes make the simulated car climb curbs or slide in bends.
Target variable: Sidewalk width and cross slope per station.
Predictors / explanatory variables: Road, position along the axis, Z of both curbs.
Method: One station per metre; 50% coverage rule to emit slope.
Metric: Median, p90 and coverage per road.
Validation: Roads below 50% complete stations stayed flat and declared.
Objective reached?: Yes: 7 of 9 roads with measured slope.

sidewalk width (m)

cross slope (%)

The object funnel

QuestionPut everything that was surveyed into the simulator?

Decision and whyNo. The truck’s sensors only see near the road, and every object costs performance in CARLA. A 30 m cut-off from the road and a cap of about 800 actors. Drains and gates were extracted but do not enter the scene. In the web model, trees that fall on a building or road are removed and the rest are spaced 8 m apart.

ResultOf the 1,743 trees, 1,104 are within 30 m of the road and 733 go into CARLA; the web model shows 415. The "Tree funnel" layer in the scene above shows where each one ended up.

Source: dados_origem/analise/props.csv

Analysis technical sheet

Objective: Decide which surveyed objects go into the simulator.
Why: Every object costs performance; only what the truck’s sensors can see is worth including.
Target variable: Objects per funnel stage (campus → 30 m → CARLA → web).
Predictors / explanatory variables: Category, distance to road, actor cap.
Method: Distance filter and cap; 8 m spatial sampling on the web.
Metric: Counts per stage.
Validation: Trees on buildings or roads removed before sampling.
Objective reached?: Yes: 1,743 → 1,104 → 733 → 415 trees.

on campus
within 30 m of the road
in CARLA

Bar length is the square root of the count, so small categories stay visible.

Heights: measure where possible, declare where not

QuestionDo all buildings have a height in the survey?

Decision and whyNo. 12 of the 28 buildings have a measured roof height. The others got 2 floors × 3.5 m and were flagged as ASSUMED, instead of an invented height that would look measured.

ResultIn the chart, the assumed buildings form a straight line at 7 m: the visual signature of the assumption. The measured ones range from 4.2 m to 17.4 m. For the truck it matters little (buildings are off the road), but for the LiDAR and the cameras it changes the scene.

Source: dados_origem/analise/edificacoes.csv

Analysis technical sheet

Objective: Give every building a height without inventing measurements.
Why: LiDAR and cameras see buildings; a wrong height changes the scene, and an invented one would look measured.
Target variable: Each building’s height and its origin.
Predictors / explanatory variables: Surveyed roof height, number of floors.
Method: Measured when a height exists; 2 floors × 3.5 m otherwise, flagged as assumed.
Metric: Measured × assumed buildings.
Validation: Assumed ones form a line at 7 m in the chart, visible as an assumption.
Objective reached?: Yes: 12 measured, 16 assumed and declared.

measured (12)
assumed (16)

area (m²) (log scale) × height (m)

Ten rounds, each one measured

QuestionHow do we know a round improved the map?

Decision and whyEvery round closes with indicators in the same table. Three lessons changed the method: when an error is too large (parking spots 19 m off), it is not tuning, it is a bug; a check measures a definition, and if the definition is not the defect’s the number passes and the defect stays; and the artifact has to be validated in its final consumer. The mesh we validated was never read by CARLA, so we started emulating its generator.

ResultMax. parking spot error from 19.04 m to 1.78 m (3 m limit). Hole in the CARLA mesh from 1,124.8 m² to 0. The mesh grew from 100 thousand to 448 thousand triangles while closing the pavement.

Source: saida8/analise/evolucao.csv

Analysis technical sheet

Objective: Prove with numbers that each round improved the map.
Why: "Looks better" does not close a capstone; fixed indicators per round catch regressions the eye misses.
Target variable: Parking-spot position error, hole in the CARLA mesh, triangles.
Predictors / explanatory variables: Pipeline round (r1–r8).
Method: Same indicator table at the end of each round; emulation of CARLA’s generator.
Metric: Metres, m² and counts.
Validation: Validation in the final consumer (CARLA), not only in the own viewer.
Objective reached?: Yes: error 19.04 → 1.78 m; hole 1,124.8 → 0 m².

Max. parking spot position error (m)

Hole in the CARLA mesh (m²)

Mesh triangles

The lap in the simulator

QuestionDoes the new map (round 10) run better than the previous one with the real truck driving?

Decision and whySame lap, same camera, same weather and 10 fixed ray-cast checkpoints in both rounds, so the comparison is fair. RAM started being logged every 10 s, and the world stopped being regenerated in every session.

ResultRoute completed at 100 % (843 m in 211 s), 0 collisions, 0 recoveries, 0 % wrong-way, mean cross-track error of 0.1 m. Offline tests from 321 to 353, no failures. Still pending: 4 solid-line crossings.

Source: RELATORIO_TESTE20.md (07/10/2026)

Analysis technical sheet

Objective: Confirm in the simulator that the new map runs better.
Why: A map is only worth anything if the truck drives on it; a fair comparison needs the same lap, camera and weather.
Target variable: FPS, RAM, holes, steps, void, collisions, cross-track error.
Predictors / explanatory variables: Map round (r9 × r10).
Method: Controlled lap with 10 fixed ray-cast checkpoints.
Metric: r10 − r9 difference per metric.
Validation: Same parameters in both rounds; RAM sampled every 10 s.
Objective reached?: Yes: 100% of the route, 0 collisions, FPS 15.1 → 18.0, holes 4 → 0.

metric	r9	r10	change
average FPS on the lap	15.1 fps	18 fps	▲ 19 %
server RAM (max.)	2.4 GB	2.17 GB	▲ -10 %
holes to the void on the road	4	0	▲ -100 %
largest step on the road	16.9 cm	5.1 cm	▲ -70 %
void in the corridor (offline)	177 m²	0 m²	▲ -100 %
edge notch (offline)	1.19 m	0.15 m	▲ -87 %
checkpoints passed	6 /10	7 /10	▲ 17 %

The result that did not work (yet)

QuestionDoes the LiDAR detect the real speed bumps?

Decision and whyMeasure before claiming. On the first lap with real speed bumps on the path, we counted how many of the route’s 4 bumps triggered an event and how many events fell within 4 m of a bump.

ResultRecall of 2 out of 4 and precision of about 6 % (3 of 48 events). The false positives repeat on the same straight of R01. Conclusion: the detector needs calibration with the raw LiDAR point cloud, which the summary logs do not keep. The next step is recording that cloud on a dedicated lap.

Source: RELATORIO_TESTE20.md §4

Analysis technical sheet

Objective: Measure whether the LiDAR detects the real speed bumps.
Why: Claiming detection without measuring would be the project’s most expensive mistake; measuring shows what data is missing.
Target variable: Speed-bump event detected.
Predictors / explanatory variables: LiDAR events, positions of the lap’s 4 bumps, 4 m radius.
Method: Count of hits and false alarms.
Metric: Recall and precision.
Validation: First lap with real bumps on the path.
Objective reached?: Not yet: recall 2/4 and precision ~6%; next step is recording the raw LiDAR cloud.

2/4recall · 50 %

3/48precision · 6 %

What each dataset contributed

Survey 3D points: the real road height, without which there would be no profile, slope or curb.
Stations every metre: measured sidewalks and slope, and the 50 % rule that decides when to trust them.
Provenance table: separates measured from synthetic and names the standard behind each assumed value.
Per-round indicators: turn "looks better" into a number and caught the bugs the eye missed.
Lap telemetry: FPS, RAM, cross-track error and collisions prove the new map is better inside the simulator, where it matters.
Detector count: showed the honest limit of what already works and which data is still missing.

Full MOVER case study →Open the published 3D model ↗