AmbiV2X Developer Stack
AmbiV2X is a vehicle-to-everything (V2X) software stack developed by Ambimat, based on existing ETSI ITS standards and India's draft AIS-230 framework. It runs on the AmbiOBU and AmbiRSU development platforms, so a team can evaluate V2X applications on physical On-Board Unit (OBU) and Roadside Unit (RSU) hardware.
Ubuntu 22.04 LTS on the NVIDIA Jetson Orin Nano Super, with AmbiV2X and ROS 2 Humble designed to coexist on it — AmbiV2X as the V2X communication stack and ROS 2 as the robotics application environment; a 5.9 GHz LTE C-V2X PC5 development radio underneath, with radio integration under development; and AmbiSEC hardware security alongside where it is populated when specified in the quoted configuration. AmbiV2X is not open source and not a public SDK: integration documentation, permitted access, licensing and software delivery scope are agreed individually for each customer engagement.
Ambimat's own V2X stack, on development hardware built for evaluation.
AmbiV2X is a V2X software stack developed by Ambimat, based on existing ETSI ITS standards and India's draft AIS-230 framework. It is not an open-source stack, a public reference implementation or an unrestricted SDK. Its verified capabilities support V2X application evaluation on the AmbiOBU and AmbiRSU development platforms. Integration documentation, permitted access, licensing and software delivery scope are agreed individually for each customer engagement; AmbiV2X source code, internal design and interface specifications are not published.
AmbiOBU and AmbiRSU are development platforms, and the AmbiV2X Developer Stack is the software environment that comes with them — Ubuntu 22.04 LTS on the NVIDIA Jetson platform, supplied with AmbiV2X, together with V2X protocol integration, the physical development hardware, and AmbiSEC security integration where AmbiSEC is populated when specified in the quoted configuration. The open-source parts of that environment, such as Ubuntu and ROS 2, are what they are everywhere else, under their own licences; AmbiV2X is not one of them. AmbiOBU and AmbiRSU are designed around the NVIDIA Jetson Orin Nano Super, with AmbiV2X and ROS 2 Humble designed to coexist on a common Linux compute platform. AmbiV2X provides the V2X communication stack; ROS 2 provides the robotics application environment for systems that consume V2X information. The ROS 2 integration interfaces and application components are on the platform roadmap, to be developed and validated — no AmbiV2X ROS 2 package ships today. How the two are designed to coexist → The standards-level V2X implementation is kept separate from the application environment, so each programme defines the 3GPP, IEEE 1609.x and SAE J2735 profile it actually needs rather than inheriting one. How the V2X stack differs between India, Europe and the United States is set out separately.
AmbiV2X is not a certified production automotive V2X stack. Ambimat does not operate the Root CA, and support for a development platform should not be read as certification of any particular production V2X deployment. The boundary, in full →
Seven layers, from application code down to the radio.
Read it downwards. The layering follows the standard ITS-station model: it shows where each job sits on the platform, not which parts a customer receives or may modify — that is agreed per engagement.
Five things in that diagram are deliberately distinct, and conflating any two of them is the most common way a V2X programme plan goes wrong:
- The application environment — Linux on the unit, with ROS 2 Humble running alongside AmbiV2X. Where research and robotics code lives.
- The standards and message layers — SAE J2735, IEEE 1609.3, IEEE 1609.2. Where interoperability lives.
- The direct V2X radio — 5.9 GHz LTE C-V2X PC5, vehicle to vehicle and vehicle to roadside, with no network in the path; radio integration and over-the-air validation are under development.
- The LTE cellular connectivity — a separate SIMCom A7672-series module for backhaul and telemetry. Not the same radio →
- The hardware security — AmbiSEC, which both platforms support and which is populated when specified in the quoted configuration, for programmes that want keys held outside application memory.
AmbiV2X and ROS 2 Humble on one Jetson platform.
Ubuntu 22.04 LTS is the baseline, and ROS 2 Humble is the long-term-support ROS 2 release for it. The two software environments are designed to share the NVIDIA Jetson Orin Nano Super, and they do different jobs.
| AmbiV2X | ROS 2 Humble | |
|---|---|---|
| Responsibility | The V2X protocol stack and its application interfaces: message generation, transmission and reception, and regional V2X profile handling | The robotics middleware and application environment: autonomy, perception, sensor processing and robot applications |
| What it talks to | Designed for other V2X stations over the direct 5.9 GHz C-V2X PC5 path; over-the-air operation and interoperability are not yet claimed | Other ROS 2 nodes on the unit or the local network, over DDS |
| What it does not do | It is not robotics middleware and does not replace ROS 2 | It is not a V2X protocol stack and does not replace AmbiV2X or the PC5 path |
| Status on the platform | Implemented and verified as a development reference in host-based software testing, and demonstrated over a laboratory network link between two engineering test hosts with live MAX-M10S positioning and signing on AmbiSEC test hardware. Validation on the Jetson platform itself is not yet claimed; over-the-air PC5 operation is under development, with target readiness in late November 2026. The status table → | Part of the platform architecture. The interfaces that connect it to AmbiV2X are on the platform roadmap, to be developed and validated |
What ROS 2 gives a development team once the integration interfaces are in place:
| Capability | What ROS 2 Humble gives the application side |
|---|---|
| Languages | C++ and Python development against the same node APIs, so a fast prototype in Python and a timing-sensitive component in C++ can coexist in one application graph |
| Packages and workspaces | ROS 2 packages and overlaid workspaces — the unit of code sharing between a lab, a supervisor and a collaborating institution |
| Build and dependencies | colcon for building and testing a workspace; rosdep for resolving system dependencies against the distribution |
| Communication primitives | Topics for publish/subscribe streams, services for request/response, actions for long-running goals with feedback and cancellation |
| Configuration | Runtime parameters, declared per node and changeable without a rebuild, plus launch tooling to bring a multi-node application up as one description |
| Middleware | DDS-based transport underneath the ROS 2 API, with discovery, and Quality of Service policies exposed per publisher and subscriber |
| Observability | Structured logging, a diagnostics convention, and live introspection of the running graph — nodes, topics, types, rates |
| Recording and replay | Message recording and replay, so a captured run can be replayed against a modified algorithm without going back on the road |
| Modularity | Application behaviour composed from separable nodes, so one component can be swapped, stubbed or simulated while the rest of the graph is untouched |
What exists today, and what is still to be built. AmbiV2X is Ambimat's V2X software stack; ROS 2 Humble is a separate robotics and application environment. The platforms are designed to support both. Their application integration remains on the platform roadmap and is not yet a delivered or validated AmbiV2X–ROS 2 bridge; no AmbiV2X ROS 2 package ships today. Integration documentation and permitted access are agreed for each customer engagement. One thing this page will not claim. ROS 2 is not a V2X protocol stack, and nothing here suggests it is — a J2735 message is not a ROS 2 message, and a 1609.3 data request is not a topic publication. The layered station model →
On Quality of Service. ROS 2 exposes QoS policies that a research application can configure per interface — reliability, history, queue depth, durability, deadline, lifespan and liveliness. That is a genuinely useful instrument for studying how an application behaves when messages are dropped, delayed or arrive late. It is a middleware configuration facility and this page treats it as one: it is not a deterministic automotive safety mechanism, and it is not a substitute for the timing analysis a production safety function would require.
Why a robot or research vehicle wants both.
ROS 2 gives a robot or research vehicle its own picture of the world, built from its own sensors. C-V2X adds information from beyond that picture: what other vehicles, robots and roadside infrastructure report directly over PC5, including from around corners and behind obstructions. Each use case below is a valid architectural application. The columns separate what the AmbiV2X codebase supports today from what still needs ROS 2 integration work, and from what also depends on hardware, interoperability validation or extra sensors.
| Use case | In AmbiV2X today | Needs ROS 2 integration work | Also depends on |
|---|---|---|---|
| Autonomous mobile robots exchanging V2X safety information with roadside infrastructure | CAM generation and reception, and the DENM event lifecycle, in the European development profile | Robot pose and motion from the ROS 2 graph into AmbiV2X inputs; received CAM and DENM content published to ROS 2 applications | Over-the-air PC5 integration; an AmbiRSU or other roadside station; deciding how a robot is represented as an ITS station |
| Research vehicles using ROS 2 for perception and autonomy, with AmbiV2X handling V2V communication | CAM and DENM, European development profile; the SAE J2735 BSM as a US engineering demonstration | Vehicle state from the ROS 2 graph into AmbiV2X; received V2V messages into the autonomy stack | Over-the-air PC5 integration; a source of vehicle data, since AmbiOBU has no CAN interface; the research vehicle itself |
| Cooperative perception, with external observations complementing local sensors | CPM, partially implemented | Mapping ROS 2 object detections into CPM perceived objects, and received objects into the robot's reference frame with consistent timestamps | Completing CPM; perception sensors, which are not standard AmbiOBU hardware; interoperability validation with other CPM implementations |
| Intersection-awareness applications consuming SPATEM and MAPEM | SPATEM and MAPEM encoding and decoding, and the receive-side signal-awareness example application | Publishing signal phase, timing and lane relevance to ROS 2 applications | Over-the-air PC5 integration; a roadside source of signal state; interoperability validation with third-party roadside units |
| Robotics and university research platforms combining direct C-V2X with ROS 2 applications | AmbiV2X with simulated inputs, recording and replay, in host-based software testing | AmbiV2X–ROS 2 application integration, scoped per engagement | Over-the-air PC5 integration for anything beyond the bench |
| V2X-assisted fleet coordination in industrial or campus environments | CAM and DENM generation and reception, verified in host-based testing; no fleet-coordination application | The coordination application itself, written in ROS 2, and the bridge it consumes | Over-the-air PC5 integration; authorisation to use 5.9 GHz on the site, which depends on the jurisdiction |
None of these scenarios has yet been demonstrated or deployed on AmbiOBU or AmbiRSU with ROS 2. They describe where the architecture is designed to go, and they are the reason ROS 2 is part of it. V2X information is an extra input to an application, not a validated control signal. Nothing here claims an autonomous-driving or safety-control function; using V2X data in vehicle or robot control would need its own validation. The V2X use cases themselves →
Agreed per engagement, in writing — not a public download.
Nothing on this page is a download link. What an evaluation or development engagement includes is settled before anybody starts building, and it is typically drawn from these categories:
| Category | What it means |
|---|---|
| Hardware | The AmbiOBU and AmbiRSU development platforms in the configuration quoted. Which setup to start with → |
| Platform software | Ubuntu 22.04 LTS with AmbiV2X on the unit under the agreed licence, and ROS 2 Humble alongside it |
| ROS 2 integration | The AmbiV2X–ROS 2 integration interfaces are on the platform roadmap, to be developed and validated; no AmbiV2X ROS 2 package ships today |
| Documentation | Integration documentation for the configuration delivered, at the level of access the engagement permits |
| Evaluation scenarios | Vehicle-to-vehicle and vehicle-to-infrastructure evaluation scenarios, as scoped for the engagement |
| People | Engineering support from Ambimat through bring-up, integration and the first working evaluation, rather than a download link and a forum |
The licensing boundary, plainly. AmbiV2X is Ambimat's own software. Its source code, internal design and interface specifications are not published and are not distributed by default; any access beyond the running software is a matter for the written agreement. Third-party and open-source components remain subject to their respective licences, and source code for third-party proprietary components is not Ambimat's to provide. Which components fall on which side of that line is settled during programme configuration, in writing, before anybody starts building.
The standards families a serious V2X environment has to address.
Stated as what the environment implements or is structured to support — both different claims from conformance. The wording below is deliberate.
| Standard | Role | Position in the AmbiV2X environment |
|---|---|---|
| 3GPP LTE-V2X | The direct V2X radio — LTE-V2X sidelink over PC5, broadcast, no base station in the path. The release history → | AmbiOBU and AmbiRSU are designed for 5.9 GHz LTE C-V2X PC5; radio integration and over-the-air validation are under development. Release 16 and NR-V2X are not included. |
| ETSI ITS Release 2 | The European facilities, networking and transport layers — CAM, DENM, SPATEM, MAPEM and CPM over GeoNetworking and BTP. Where they sit → | Available in AmbiV2X for the European development profile: CAM, DENM, SPATEM and MAPEM, verified in Ambimat's host-based software testing. CPM is partial. A development reference, not conformance-tested. The status table → |
| IEEE 1609.3-2020 | WAVE networking and transport services — the WAVE Short Message Protocol (WSMP), the WAVE Management Entity (WME), service advertisement, and the network and transport services beneath the application. Where it sits → | The US engineering demonstration carries the BSM. Beyond that, the environment is structured for integration with these services, with the target profile frozen during programme configuration. Being architected to integrate a protocol is not the same as certified conformance to it, and no conformance claim is made here. |
| IEEE 1609.2-2016 | The V2X security-services layer — signed and encrypted message formats, certificate handling, and the permissions model that decides what a sender was entitled to say. The credential architecture → | Provides an environment for development around 1609.2 security services, integrated with the application layers and with AmbiSEC for key custody where it is populated when specified in the quoted configuration. Secured (signed) V2X messaging is not claimed today. Ambimat is not a Root CA and does not operate a PKI; a production trust deployment is a separate, programme-specific undertaking. |
| SAE J2735-2022 | The V2X message-set dictionary — the shared data definitions that let two independently built devices mean the same thing. The message tables → | The BSM (Basic Safety Message) is encoded and decoded as a US engineering demonstration — not certified. Other candidate development messages include SPaT (Signal Phase and Timing), TIM (Traveler Information Message) and MAP (intersection and lane geometry). These are message families a programme can implement or integrate according to the agreed profile — not a claim that every J2735 message is already implemented. |
The phrasing across that table is not hedging for its own sake. A development environment that is structured for integration with a standard and a product that is certified conformant to it are two different things with two different price tags, and a research programme that confuses them discovers the difference at the test laboratory. How V2X conformance testing actually works →
What a developer can exercise today. Generate and receive CAM, DENM, SPATEM and MAPEM messages in the European development profile, and CAM and DENM in the India development build; run a receive-side signal-awareness example application; exchange a J2735 BSM in the US engineering demonstration; and repeat any of it from recorded runs. All of it is verified in host-based software testing today, and CAM and DENM exchange has also run over a laboratory network link between two engineering test hosts — over-the-air PC5 operation is under development, with target readiness in late November 2026 and is not claimed here. How each region fills the same layers is on the V2X stack page.
One message, traced from research code to the air.
Research application
The behaviour under study: an algorithm, a decision rule, a warning strategy, an HMI.
Application interface
The application calls the integration-layer API — directly, or from a ROS 2 node once the roadmap integration interface is in place. This is the level most application researchers work at.
Application message
The content is expressed as a SAE J2735 message from the agreed profile — a BSM, a SPaT, a TIM, a MAP.
Network, transport and security
WAVE networking and transport services carry it; IEEE 1609.2 is where signing and verification belong — secured messaging is being developed for AmbiV2X, not claimed.
C-V2X radio
Adaptation onto the direct LTE C-V2X PC5 path, and out of the antenna — radio integration under development.
Three consequences follow from drawing it this way, and they are the reason the diagram is on this page at all:
- No application framework replaces the IEEE, SAE or 3GPP protocols, ROS 2 included. It sits above them. Everything below the second box is standards work that would exist whatever the application is written in.
- Each layer can be investigated independently. A message-encoding study, a security-services study and a radio-behaviour study are three different experiments against three different boxes.
- Application researchers do not need to write modem-level code to do useful V2X work. Access below the application level is not a default: it is part of the commercial agreement, scoped per engagement.
The mobile V2X development node.
The moving participant in a V2X exchange, and the platform most application experiments run on. The full AmbiOBU page →
The current AmbiOBU development baseline is: GNSS — a u-blox MAX-M10S multi-constellation standard-precision receiver; a 9-axis IMU; a 5.9 GHz LTE C-V2X PC5 development radio, with radio integration and over-the-air validation under development; a SIMCom A7672-series 4G LTE module for cellular connectivity; and AmbiSEC support for key custody and cryptographic services, with AmbiSEC populated when specified in the quoted configuration.
Two things it does not carry, stated so that nothing on this site implies otherwise. Lidar is not standard AmbiOBU hardware. CAN is not standard AmbiOBU hardware — there is no vehicle data bus interface on the development baseline, and none is implied by the term “on-board unit”. Where a programme needs either, that is programme-specific engineering designed for the programme, not something the platform already has.
Position, motion and application state therefore originate from the sources the unit actually has: GNSS, the IMU, application software on the unit, simulation feeding the same interfaces, or programme-specific external integrations agreed as part of the engineering scope.
The LTE module is not the V2X radio.
AmbiOBU carries a SIMCom A7672-series LTE Cat 1 module. It is there for the wide-area, IP-facing half of the problem:
- Backhaul — moving data between a unit and a server
- Telemetry — reporting unit and experiment state while a trial is running
- Remote diagnostics — looking at a unit that is not on the bench in front of you
- Backend and IP services — including MQTT and other ordinary IP application protocols
- Experiment data upload — getting recorded runs off the unit and into analysis
- Remote support — Ambimat engineering reaching a deployed development unit during a programme
The A7672 cellular connection is separate from the direct C-V2X radio. It is a 4G LTE cellular modem. It does not provide PC5, it does not provide the direct V2X sidelink, and it is not the path any direct vehicle-to-vehicle or vehicle-to-infrastructure safety message travels over. Direct V2X on AmbiOBU and AmbiRSU is designed to use the separate 5.9 GHz LTE C-V2X PC5 radio described above.
That distinction is worth stating twice because it is the single most common misreading of a connected-vehicle specification: a unit with a cellular modem in it is not thereby a V2X unit, and a V2X unit is not thereby internet-connected. Two radios, two jobs. Why the wide-area half exists at all →
A programmable roadside V2X edge-development node.
The stationary counterpart, running the same runtime and the same integration layer. The full AmbiRSU page →
AmbiRSU runs the same development platform as AmbiOBU — the same NVIDIA Jetson Orin Nano Super compute with 8 GB LPDDR5, the same u-blox MAX-M10S GNSS receiver, the same SIMCom A7672-series LTE Cat 1 backhaul and the same 5.9 GHz LTE C-V2X PC5 radio direction, under the same Ubuntu 22.04 environment. A 9-axis IMU is standard on AmbiOBU and a separately quoted addition on AmbiRSU. The two differ in where they sit and how they are packaged, not in what they run. The common platform, side by side →
AmbiRSU is intentionally configurable beyond that shared baseline, and that is the point of it rather than a gap in it. Depending on programme scope it can integrate with traffic-signal and controller data, externally supplied intersection state, fixed-position information, road and environment sensors, roadside application software, backend systems, cellular or IP backhaul, and experimental instrumentation added for a particular study.
None of those is claimed as standard inclusion. Roadside interfaces, sensor payload and backend integration are scoped according to the target programme — an intersection study, a corridor trial and a laboratory rig want three different roadside units, and pretending otherwise produces a unit that fits none of them.
Infrastructure, controller or application
Signal state, intersection geometry, sensor data or roadside application logic — as scoped.
Runtime and application
The same environment as the on-board unit, running the V2X application.
J2735 and IEEE 1609.x
Encoded as a message from the agreed profile, carried by the WAVE services; securing it is the IEEE 1609.2 path being developed.
C-V2X direct communication
Direct LTE C-V2X PC5 transmission from the roadside node — radio integration under development.
AmbiOBU
The moving node is the intended receiver — the vehicle-to-infrastructure half of the experiment, over the air once PC5 operation of AmbiV2X is integrated.
From simulated input to physical nodes, without changing the application.
The practical argument for separating the application from the inputs is that the same application runs against simulated state and against hardware — and ROS 2's own simulation and recording tools work the same way on the application side.
- Simulated vehicle state and simulated roadside state feeding the same interfaces the real sensors feed
- Multiple application instances together, representing several participants before several units exist
- Repeatable vehicle-to-vehicle scenarios and repeatable vehicle-to-infrastructure scenarios — the same encounter, run again, with one variable changed
- Recording and replay of a captured run, so a result can be re-examined months later or handed to another team
- Application timing studies — where time is actually spent between an input and a transmitted message
- Message generation and decoding tests against the agreed profile
- Positive and negative security experiments, once the secured-message path is complete — valid material that should verify, and malformed or wrongly signed material that should be rejected. The detection classes this exercises →
- Debugging and visualisation of a live application while it runs
- Transition from simulated input to physical nodes, one interface at a time, rather than as a single risky cutover
Optional programme configurations extend that further. The on-board unit can be run on a 1:10-scale movable development platform so that relative motion is real rather than modelled, and full-scale vehicle and infrastructure integration is available as an engineering and research scope. A complete full-scale autonomous vehicle is not included with AmbiOBU — that is an integration capability a programme can commission, not part of the platform.
Development platforms, not certified production products.
AmbiOBU and AmbiRSU are development platforms. They are intended for research, proof-of-concept work, V2X application development, integration, trials and jointly developed programmes. They are not currently represented as certified production automotive products, and nothing on this page should be read as saying otherwise.
Production use can require separate validation, standards conformance, regulatory approvals, type approval, homologation and product certification, depending on the deployment and the jurisdiction it lands in. Those are real programmes with real cost and real calendar time, they sit with accredited laboratories and authorising bodies rather than with a hardware supplier, and a development platform is the beginning of that path rather than the end of it. What an Indian deployment would have to satisfy →
Stating this plainly is the point. A development platform that is described as a development platform is a usable foundation for a research programme; one that is quietly described as a product is a problem discovered late.
44 years of engineering, not a shipment.
Ambimat has 44 years of embedded engineering experience across multiple industry verticals. A V2X engagement is an engineering relationship rather than the despatch of a development kit.
| Area | What Ambimat can take on, according to programme scope |
|---|---|
| Definition | Requirements definition — use cases, message profile, radio and positioning strategy, the trust boundary |
| Hardware | Hardware development, and custom AmbiOBU and AmbiRSU engineering for a specific programme. The hardware engagement → |
| Software | Embedded-software development, ROS 2 applications and AmbiV2X–ROS 2 integration, and V2X protocol integration against the agreed profile |
| Roadside | Roadside integration — controller interfaces, mounting, power and backhaul for the RSU side of a programme |
| Security | Security integration, including the AmbiSEC layer where it is quoted, and the device side of the credential chain. The security engagement → |
| Prototyping | Prototyping and test planning — a working unit and a defined way to tell whether it works |
| Toward manufacture | Manufacturing engineering and supply-chain support. PCB fabrication and volume assembly run through qualified manufacturing partners coordinated by Ambimat, an arrangement the parent company describes itself |
| Compliance | Certification and compliance support — preparing hardware and documentation and supporting the submission. The testing and the approval sit with the accredited body, never with Ambimat |
| Deployment | Pilot deployment and engineering hand-holding through bring-up, first light and the first working experiment |
Where this fits.
AmbiOBU
The mobile development node this stack runs on, with its hardware baseline stated in full.
AmbiRSU
The roadside development node, and why its interfaces are scoped per programme.
AmbiSEC
The security layer both platforms support, populated when specified in the quoted configuration — key storage and cryptographic services.
Message sets
SAE J2735 and the ETSI messages, with IDs and rates — the profile a programme selects from.
C-V2X
What Release 14 is, what came after it, and why the direct sidelink needs no network.
Stacks and SDKs
The commercial V2X stack and SDK landscape a programme selects its standards implementation from.
Evaluating AmbiV2X for a programme?
Bring the research or product question, the scale you want to work at and the applications you want to evaluate. We will bring the development hardware, the platform software (AmbiV2X and ROS 2 Humble side by side on the unit), the V2X protocol integration and a written scope for access, documentation and licensing. That work runs as a V2X development engagement.
Questions this page answers.
Does Ambimat provide V2X software, or only hardware?
Both. AmbiV2X is a V2X software stack developed by Ambimat, and it runs on the AmbiOBU and AmbiRSU development hardware alongside ROS 2 Humble; AmbiSEC security integration applies where AmbiSEC is populated when specified in the quoted configuration. It is not open source and not a certified production automotive V2X stack. Integration documentation, permitted access, licensing and software delivery scope are agreed for each customer engagement. Ambimat does not operate the Root CA, and development-platform support is not certification of a production V2X deployment.
What operating system and middleware does the AmbiV2X Developer Stack use?
Ubuntu 22.04 LTS, a long-term-support release, chosen so a multi-year research programme is not rebuilding its foundation halfway through. The platform is designed for two software environments to coexist on the NVIDIA Jetson Orin Nano Super: the AmbiV2X communication stack, which handles V2X message generation and reception, verified in host-based software testing (over-the-air PC5 operation is under development, with target readiness in late November 2026); and ROS 2 Humble, the long-term-support ROS 2 release for Ubuntu 22.04, as the robotics application environment. The ROS 2 integration interfaces between them are on the platform roadmap, to be developed and validated; no AmbiV2X ROS 2 package, node or message bridge ships today.
Is ROS 2 a V2X protocol stack?
No, and this page does not present it as one. ROS 2 does not replace AmbiV2X, and AmbiV2X does not replace ROS 2. ROS 2 is the robotics application and integration environment, and the standards-level V2X communications layers sit below its application-facing interfaces: a SAE J2735 message is not a ROS 2 message, and an IEEE 1609.3 data request is not a topic publication. Their integration is on the platform roadmap, not a delivered or validated bridge.
Which C-V2X generation do AmbiOBU and AmbiRSU use?
LTE C-V2X. AmbiOBU and AmbiRSU are designed for direct 5.9 GHz LTE C-V2X PC5 communication; radio integration and over-the-air validation are under development, and the radio capabilities available for a particular evaluation are confirmed in the agreed configuration. Release 16 or NR-V2X is not included. PC5 is the direct path between nearby participants and is separate from the 4G LTE backhaul module, which does not provide PC5. Ambimat does not develop, sell or plan a DSRC or IEEE 802.11p product.
Is the SIMCom A7672 module the V2X radio?
No. The A7672-series module is 4G LTE Cat 1 cellular connectivity, used for backhaul, telemetry, remote diagnostics, backend and IP services such as MQTT, experiment data upload and remote support. The A7672 cellular connection is separate from the direct C-V2X radio and does not provide PC5 or the direct V2X sidelink. Direct V2X is designed to use the separate 5.9 GHz LTE C-V2X PC5 radio, whose integration is under development.
Does AmbiOBU have CAN or lidar?
No. Lidar is not standard AmbiOBU hardware and CAN is not standard AmbiOBU hardware; there is no vehicle data bus interface on the development baseline, and none is implied by the term on-board unit. The baseline is GNSS, a 9-axis IMU, a 5.9 GHz LTE C-V2X PC5 development radio (integration under development), a SIMCom A7672-series 4G LTE module for backhaul, and AmbiSEC support, with AmbiSEC populated when specified in the quoted configuration. The platform therefore does not read brake state, wheel speed, steering angle or gear position. Where a programme needs a bus interface or a sensor payload, that is programme-specific engineering rather than something the platform already has.
Which V2X messages does the AmbiV2X Developer Stack implement?
For the European (ETSI) development profile: CAM, DENM, SPATEM and MAPEM, with CPM partially implemented. For the US: the SAE J2735 BSM (Basic Safety Message) as an engineering demonstration; SPaT, TIM and MAP remain candidate development messages a programme can implement or integrate according to the agreed profile. All of it is verified in Ambimat's host-based software testing; over-the-air PC5 operation is not yet claimed, and none of it is conformance-tested or certified. The full status table.
Are AmbiOBU and AmbiRSU certified products?
No. They are development platforms, intended for research, proof-of-concept work, V2X application development, integration, trials and jointly developed programmes. They are not currently represented as certified production automotive products. Production use can require separate validation, standards conformance, regulatory approvals, type approval, homologation and product certification depending on the deployment.
What does a customer receive with AmbiV2X?
What is delivered is agreed for each customer engagement, in writing: the development hardware, the platform software with AmbiV2X under the agreed licence, ROS 2 Humble alongside it, integration documentation and evaluation scenarios as scoped, and engineering support from Ambimat. AmbiV2X source code, internal design and interface specifications are not published and are not distributed by default. The AmbiV2X–ROS 2 integration interfaces are on the platform roadmap; no AmbiV2X ROS 2 package ships today. Third-party and open-source components, such as Ubuntu and ROS 2, remain subject to their own licences. Getting started with an evaluation.
Can the environment run in simulation before hardware arrives?
Yes, and that is how AmbiV2X features are verified today: in host-based software testing against simulated vehicle and roadside state, so a team can build repeatable V2V and V2I scenarios, record and replay runs, and test message generation and decoding. AmbiV2X has also exchanged signed CAM and DENM messages between two engineering test hosts over a laboratory network link, with signing on AmbiSEC test hardware; over-the-air PC5 operation is under development, with target readiness in late November 2026.
Last updated 2026-10-22 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com