Sidewalk Detection

Sidewalk detection is the on-vehicle layer of Levy Vision. It uses computer-vision hardware from a third-party vendor (Drover AI or Luna Systems) installed on your scooters and bikes. When the on-board model decides the rider is on a sidewalk, the vendor sends us an event, and our policy engine decides what to do — warn, slow, or cut throttle.

This article explains how the pipeline works end-to-end. For the actual throttle-cut ladder, see Throttle-cut policy. For the vendor onboarding steps, see Vendor setup — Drover & Luna.

What you need

• Vendor hardware installed on the vehicles you want covered. Today we integrate with Drover AI PathPilot and Luna Systems. Captur.ai is supported only for parking-pose, not sidewalk detection.
• Devices provisioned in Safety > Vendor devices, with each vendor device serial mapped to a Levy vehicle UUID.
• A signed webhook secret stored against your subaccount so we can verify incoming events.
• The Sidewalk detection toggle turned on in Safety > Safety settings.

If any of these are missing, sidewalk events won't flow into the dashboard.

How the event pipeline works

On-vehicle cam → Vendor model → Vendor webhook
   → POST /api/webhooks/drover/events (or /luna/events)
   → HMAC signature verified
   → Payload normalized into a cv_events row
   → Policy engine (sidewalk-policy.ts) decides action
   → Throttle controller dispatches to IoT command path
   → Rider sees warning / speed reduce / cut on their phone

The latency from on-vehicle detection to rider notification is typically 2–4 seconds, depending on cellular conditions on the vendor module. The dashboard event row appears within that same window.

Configuring detection

Open Dashboard > Safety > Safety settings. The Sidewalk detection section has these controls.

Sidewalk detection enabled

Master toggle. With it off, vendor events still hit our webhooks (we don't drop them — they're logged), but no policy actions run and the rider sees nothing.

Vendor

Pick Drover or Luna. You can mix vendors across subaccounts but not within the same subaccount — the vendor mapping is per-subaccount.

Threshold ladder

The three thresholds control when each enforcement step kicks in. Each is a count of sidewalk events within the current ride.

We strongly recommend leaving throttle cut disabled for your first month. Watch events flow into the dashboard, tune the geofence allow-list (below), and turn cut on once false-positives are under 2%.

Geofence allow-list

Some sidewalk-shaped surfaces shouldn't trigger enforcement — protected bike lanes that look like sidewalks to the model, beachfront paths your city has explicitly allowed, plaza shortcuts the operator has signed off on.

To add an allow-list polygon:

1. Open Safety > Sidewalk hotspots (map view).
2. Right-click on the map to draw a polygon, or paste a GeoJSON polygon in the import dialog.
3. Mark the polygon as kind=allow and save.

Any sidewalk event whose location falls inside an allow-list polygon is logged but does not trigger a policy action. The event row shows the polygon name in the side-effects column.

Reading sidewalk events

Go to Safety > Events and filter event type to sidewalk_entry (the main event) or sidewalk_exit (companion event when the rider returns to the road).

Each row shows:

• Rider, ride, vehicle
• Vendor source (drover or luna)
• Confidence (set by the vendor model)
• Lat/lng, with a "View on map" link
• Side-effects column — which policy steps fired (warn, speed_reduce, throttle_cut)

For the geographic view, open Safety > Sidewalk hotspots. Events cluster on a heatmap so you can spot patterns — most fleets find one or two repeat-offender intersections that account for the bulk of events. Add an allow-list polygon if it's a known false-positive, or share the heatmap with your city contact as evidence of where you're enforcing.

Vendor reliability and failure modes

The vendor webhook is the weak link in this pipeline. We monitor it for you, but here's what happens when things go wrong:

• No events for 5+ minutes during peak ride hours — Sentry alert fires, enforcement is auto-disabled for the affected fleet until events flow again
• Late event (>30s delay) — event still logged, but no real-time enforcement; rider gets an after-the-fact warning push instead
• Replay attack — webhook signature verification rejects duplicate payloads using the vendor's event ID and our cv_events.external_event_id index
• Vendor signature mismatch — webhook returns 401, event is not logged; check the signing secret in Safety > Vendor devices

If you ever suspect the pipeline is silently broken (e.g., you know a rider was on the sidewalk but no event appeared), check the Troubleshooting article — the "no sidewalk events" diagnosis tree is there.

OEM compatibility

Throttle-cut is what your IoT protocol supports. Not every OEM accepts a mid-ride speed cap, so the policy engine falls through gracefully:

If a vehicle's IoT type doesn't support the configured step, the policy engine logs a skipped action and proceeds to the next step. You don't have to configure this per OEM — it's automatic.

What the rider sees

On the first event in a ride, the rider's app shows the Sidewalk warning modal — a full-screen overlay with a small map showing their last known location vs the detected sidewalk geometry, plus a "Move to the road" CTA.

On speed reduction, the modal updates to say "Speed reduced — return to the road". On throttle cut, they see the Throttle restore screen with a 30-second countdown and "I'm back on the road" button. See Throttle-cut policy for the restoration flow.

Going to GA

We recommend this rollout path for your sidewalk pilot:

1. Week 1–2 — devices installed, detection enabled, no throttle cut. Watch the events feed.
2. Week 3 — add geofence allow-list polygons for any obvious false-positive hotspots.
3. Week 4 — turn throttle cut on. Monitor rider complaints (under 2 per 1k rides is the target).
4. Ongoing — review the Safety > Sidewalk hotspots map weekly and share with your city contact.