Ouster turns lidar observations into AI perception and traffic intelligence

Explore Ouster’s lidar sensors, Gemini perception, BlueCity traffic systems and Stereolabs ownership, with a practical site evaluation workflow. This is a public-source assessment with a proposed evaluation, not a hands-on test.

01 / ProductSensors, perception and operating applications are separate buying layers

Ouster supplies digital lidar sensors and software for understanding physical environments. Its products serve both developers building their own systems and operators who need interpreted events. That breadth makes it relevant to AI infrastructure, robotics and traffic operations, but it also means that the phrase Ouster deployment can describe substantially different projects.

Gemini detects, classifies and tracks people, objects and vehicles. Its documented package includes a perception engine, multi-sensor merging, event zones, diagnostics, visual configuration and a cloud portal. The sensor provides observations; Gemini turns those observations into a representation that another application can use. A buyer should determine whether it needs that packaged interpretation or intends to build its own.

BlueCity brings lidar and AI software into a traffic-specific system. It adds road-user detection, operational outputs and analytics around intersections and roadways. Meanwhile, Ouster's Stereolabs acquisition page states that the company acquired Stereolabs on 4 February 2026 and that it continues as a wholly owned subsidiary. Cameras, compute and vision capabilities therefore sit within the same corporate portfolio; they are not a separate company entry here.

02 / AudienceChoose whether you need observations or an operational answer

A robotics developer may need a point cloud that can be combined with other sensors. In that situation, hardware fit, data access and timing are central. A facility operator may instead need to know that a queue is growing or that an object crossed a defined boundary. That buyer should evaluate the complete event pipeline, including the action taken after detection.

A transportation agency has another requirement: usable information within an existing signal and traffic-management environment. An attractive 3D display is not enough if the operational output does not map to the agency's real decisions. BlueCity is the more relevant starting point when the task involves road users, traffic actuation and traffic analytics rather than general site monitoring.

The NVIDIA blueprint is useful when a developer is choosing compute and software around perception. The Samsara blueprint provides a comparison for organizations whose main need is connected operational visibility across fleets and equipment. The decision is not which company has the broadest AI message; it is whether spatial sensing is the missing input to the workflow.

03 / WorkflowA proposed site trial should follow one event from capture to response

Consider a distribution-site operator evaluating queue and movement monitoring at a shared entrance. Begin with a simple event definition: a vehicle enters a waiting area, remains there and then leaves through a designated exit. This proposed workflow is a way to evaluate Gemini, not a report of an installation performed by Sequenced.

Draw the site geometry before selecting hardware. Include fixed obstructions, expected vehicle heights and the places where people may overlap with vehicles. Ask the integrator to explain where a track can disappear and whether another sensor will observe it there. Multi-sensor coverage should be judged at the handoff between views, where a single object could otherwise become two records.

For a developer-led route, Ouster's SDK page describes Python and C++ libraries, sample data and ROS 2 resources. Use a recorded dataset first to establish that the team can read, visualize and retain the needed observations. This confirms a development path; it does not confer a Gemini license or prove an application-level detector works.

For Gemini, configure the waiting area and entry and exit boundaries. Record the meaning of a count, a dwell interval and a crossing event. Decide how the application treats an object already inside the area at startup. These definitions matter because two systems can report different queue metrics while both are behaving consistently with their own rules.

Run a bounded reference observation with staff labeling a sample of arrivals and departures. Include stopping on a boundary, reversing, closely spaced vehicles and a person walking beside a vehicle. Compare event identities as well as totals. A correct daily total can conceal a duplicated arrival followed by a missed departure, which would make the live queue state unreliable.

Then connect one downstream use, such as an operations dashboard or an advisory alert. Check the timestamp and identity attached to each event and the receiving system's behavior after a connection interruption. Keep this first integration advisory until operators understand the errors and recovery behavior. A useful pilot should show both successful observations and the cases it cannot resolve.

If the actual requirement is a public intersection, reset the evaluation around BlueCity. The product page documents traffic-controller integration and road-user analytics, but that is a different deployment context from the facility entrance. Use the agency's accepted movement definitions and controller configuration. Treat any change to signal operations as a separate acceptance step from collecting analytics.

04 / PricingHardware quotes and software licenses should remain visible

The current OS1 page offers a quote request, and Ouster sales is the route for discussing products. The inspected pages do not establish a universal public currency price for Gemini or an installed site. A supplier conversation should distinguish sensors, processing hardware, application software, installation and support.

BlueCity explicitly describes advanced analytics offered through a perpetual or scalable SaaS license. That is a meaningful commercial distinction, but the page does not establish one numeric tariff or every entitlement. Ask which analytics, retention functions and portal features are included in the offered license, and what continues to operate if the subscription or cloud connection changes.

Compare proposals over the same operating period and site scope. A low initial hardware amount can be misleading when software, mounting or field service sit elsewhere. Conversely, a complete managed installation may contain work that a capable engineering team plans to perform internally. The comparison becomes useful only when each party's responsibilities are explicit.

05 / DistinctionsThe portfolio covers both development and recurring operations

Ouster's SDK gives engineers a relatively direct route to raw sensor work, while Gemini and BlueCity move toward interpreted events and domain-specific operations. In our assessment, that range is the strongest reason to investigate the company. It lets a buyer choose how much perception and application work to own rather than assume every deployment starts from the same software layer.

The OS1 specification distinguishes maximum range from range at 10% reflectivity. That distinction is useful for buyers comparing sensors: the hardest required target can be much more consequential than a best-case distance. The same page positions OS1 among several sensor geometries. Coverage and target conditions should drive the choice before a buyer compares output density.

Stereolabs ownership expands the corporate offer, but common ownership is not evidence that every camera, lidar and software combination is a single supported package. The acquisition page describes continued subsidiary leadership and product continuity. A project should still obtain the compatibility and support scope for the exact configuration it intends to deploy.

06 / QuestionsPrivacy and performance depend on the installed configuration

Gemini's product page emphasizes spatial tracking without faces or license plates. The newer BlueCity material also describes native color data and edge blurring of pedestrians and cyclists. Those are different representations and privacy features. Do not apply a general claim about lidar anonymity to every current product configuration or to data combined with other systems.

For a proposed installation, inventory the outputs actually retained: raw observations, color imagery, object tracks, event recordings and aggregate reports. Determine which operators can access each output and whether the application needs it. This is a design question about the chosen configuration, not a claim that the public product page establishes the buyer's full data-handling obligations.

Vendor statements about accuracy, weather performance and installation times describe the company's claims. They do not replace a site acceptance test. A buyer should ask how performance was measured and whether the target types, mounting positions and environmental conditions match its own. Include ordinary congestion and occlusion rather than evaluating only unobstructed demonstration scenes.

Finally, establish the operational cost of a missed or duplicate event. A counting dashboard may tolerate a different error pattern from a live alert. The system's value depends on that consequence, not simply the quality of a rendered point cloud. Choose thresholds and escalation rules with the people who will use the output.

07 / DecisionMatch the product layer to the responsibility you want to own

Ouster is worth evaluating when a spatial observation needs to become a repeatable machine or operational decision. Start with the event, choose the hardware and software layer that supports it, and accept the complete handoff. Keep development access, software entitlement and installed behavior distinct throughout the buying process.