AmbiV2X Developer Stack
An open vehicle-to-everything (V2X) development environment from application code to physical On-Board Unit (OBU) and Roadside Unit (RSU) hardware.
Ubuntu 22.04 LTS and ROS 2 Humble Hawksbill on the unit; C++ and Python against documented interfaces; SAE J2735 message development and IEEE 1609.x integration below that; a 3GPP Release 14 C-V2X development radio underneath; and optional AmbiSEC hardware security alongside. Built for teams that need to open the box.
A development environment, not a closed appliance.
Most V2X hardware arrives as a sealed unit. It transmits, it receives, it exposes a configuration interface, and what happens between the antenna and the API is somebody else's business. That is the right answer for a fleet rollout. It is the wrong answer for a research group, a university programme or an engineering team that has to build, inspect, extend, instrument and test the thing it is studying.
AmbiOBU and AmbiRSU are development platforms, and the AmbiV2X Developer Stack is the software environment that comes with them. Ambimat provides an open ROS 2-based application and development environment for both units, together with V2X protocol integration, the physical development hardware, and optional AmbiSEC security integration. 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.
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. Each layer can be studied, instrumented or replaced without rewriting the one above it — which is the entire reason for separating them.
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 middleware — ROS 2 on Ubuntu. Where research code lives.
- The standards and message layers — SAE J2735, IEEE 1609.3, IEEE 1609.2. Where interoperability lives.
- The direct V2X radio — 3GPP Release 14 C-V2X, vehicle to vehicle and vehicle to roadside, with no network in the path.
- The LTE cellular connectivity — a separate SIMCom A7672-series module for backhaul and telemetry. Not the same radio →
- The optional hardware security — AmbiSEC, integrated where a programme wants keys held outside application memory.
Ubuntu 22.04 LTS and ROS 2 Humble Hawksbill.
A long-term-support Linux and a long-term-support ROS 2 release, chosen so that a three-year research programme is not rebuilding its foundation halfway through.
| Capability | What it gives a development team |
|---|---|
| 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 |
One thing this page will not claim. ROS 2 is not a V2X protocol stack, and nothing here suggests it is. ROS 2 is the application and integration environment. The standards-level V2X communications layers sit below the application-facing ROS 2 interfaces — a J2735 message is not a ROS 2 message, and a 1609.3 data request is not a topic publication. The integration layer is what maps between them, and keeping that mapping explicit is what allows a protocol-focused researcher to work at one level while an application researcher works at another. The layered station model this mirrors →
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.
More than a Linux image.
The development package is defined per programme. Depending on the scope agreed, it can include:
| Category | Contents |
|---|---|
| Runtime | Ubuntu 22.04 LTS with the ROS 2 Humble runtime configured for the unit, and the C++ / Python toolchain around it |
| Workspace | A structured ROS 2 workspace, with AmbiOBU and AmbiRSU interface packages in it |
| Interfaces | V2X transmit and receive APIs, and Ambimat-developed message and service definitions for the integration layer |
| Libraries | The relevant libraries and headers a node needs to build against those interfaces |
| Documentation | API documentation, and developer and user documentation for the platform as configured |
| Sample code | Sample application code and application templates — including a worked vehicle-to-vehicle example and a worked vehicle-to-infrastructure example |
| Instrumentation examples | Logging and diagnostic examples, and recording and replay examples, so a team is not inventing its own measurement scaffolding first |
| Operations | Deployment instructions and test procedures for the configuration delivered |
| People | Engineering support from Ambimat — hand-holding through bring-up, integration and the first working experiment, rather than a download link and a forum |
The licensing boundary, plainly. Ambimat-developed application and integration components can be provided according to programme scope. 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 is structured to support, which is a different claim from conformance. The wording below is deliberate.
| Standard | Role | Position in the AmbiV2X environment |
|---|---|---|
| 3GPP Release 14 C-V2X | The direct V2X radio — LTE-V2X sidelink over PC5, broadcast, no base station in the path. The release history → | The current AmbiOBU and AmbiRSU development radio baseline is 3GPP Release 14 C-V2X, including power-saving modes. Release 15 is not the baseline; Release 16 and NR-V2X are not included. |
| 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 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 optionally with AmbiSEC for key custody. 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 → | Supports development around the J2735 message families. Candidate development messages include BSM (Basic Safety Message), 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 →
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.
Node and application API
A ROS 2 node calls the integration-layer API. 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; the 1609.2 security services sign it and check what arrives.
C-V2X radio
Adaptation onto the 3GPP Release 14 direct communication path, and out of the antenna.
Three consequences follow from drawing it this way, and they are the reason the diagram is on this page at all:
- ROS 2 does not replace the IEEE, SAE or 3GPP protocols. It sits above them. Everything below the second box is standards work that would exist whether or not ROS 2 were in the picture.
- 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 — and protocol-focused researchers can go deeper where the programme scope allows it. Which of those two a project needs is a scoping decision, not a limitation of the platform.
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 3GPP Release 14 C-V2X development radio with power-saving modes; a SIMCom A7672-series 4G LTE module for cellular connectivity; and optional AmbiSEC integration for key custody and cryptographic services.
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, ROS 2 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 uses the separate 3GPP Release 14 C-V2X 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, the same 9-axis IMU, the same SIMCom A7672-series LTE Cat 1 backhaul and the same 3GPP Release 14 C-V2X radio, under the same Ubuntu 22.04 and ROS 2 Humble environment. 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 ROS 2 environment as the on-board unit, running the V2X application.
J2735 and IEEE 1609.x
Encoded as a message from the agreed profile, carried and secured by the WAVE services.
C-V2X direct communication
3GPP Release 14 direct transmission from the roadside node.
AmbiOBU
The moving node receives, verifies and acts — the vehicle-to-infrastructure half of the experiment.
From simulated input to physical nodes, without changing the application.
The practical argument for a ROS 2-based architecture is that the same application graph runs against simulated state and against hardware.
- Simulated vehicle state and simulated roadside state feeding the same interfaces the real sensors feed
- Multiple application nodes in one graph, 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 — 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 graph 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 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 optional AmbiSEC layer 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 optional security layer — key storage, cryptographic services and PKI integration.
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.
Building a V2X research programme?
Bring the research question, the scale you want to work at, and how much of the stack your team wants to write itself. We will bring the development hardware, the ROS 2 environment, the V2X protocol integration and an honest view of which layers your programme should own. That work runs as a V2X development engagement.
Questions this page answers.
Does Ambimat provide V2X software, or only hardware?
Both. Ambimat provides an open ROS 2-based application and development environment for AmbiOBU and AmbiRSU, together with V2X protocol integration, the physical development hardware and optional AmbiSEC security integration. The standards-level V2X implementation is kept separate from the application environment so that each programme can define the 3GPP, IEEE 1609.x and SAE J2735 profile it needs. 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 with ROS 2 Humble Hawksbill. Both are long-term-support releases, chosen so a multi-year research programme is not rebuilding its foundation halfway through. Development is in C++ and Python, with packages and workspaces built by colcon and system dependencies resolved by rosdep.
Is ROS 2 a V2X protocol stack?
No, and this page does not present it as one. ROS 2 is the application and integration environment. The standards-level V2X communications layers sit below the application-facing ROS 2 interfaces: a SAE J2735 message is not a ROS 2 message, and an IEEE 1609.3 data request is not a topic publication. The integration layer maps between them, which is what lets an application researcher and a protocol researcher work at different levels of the same platform.
Which C-V2X release do AmbiOBU and AmbiRSU use?
The current AmbiOBU and AmbiRSU development radio baseline is 3GPP Release 14 C-V2X, including power-saving modes. Release 15 is not the baseline, and Release 16 or NR-V2X is not included.
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 uses the separate 3GPP Release 14 C-V2X radio.
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. The baseline is GNSS, a 9-axis IMU, a 3GPP Release 14 C-V2X development radio with power-saving modes, a SIMCom A7672-series 4G LTE module and optional AmbiSEC integration. Where a programme needs a bus interface or a sensor payload, that is programme-specific engineering rather than something the platform already has.
Which SAE J2735 messages are supported?
Candidate development messages include BSM (Basic Safety Message), 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. It is not a claim that every J2735 message is already implemented.
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 research team actually receive besides a Linux image?
According to programme scope: the Ubuntu and ROS 2 Humble runtime, the C++ and Python toolchain, a structured ROS 2 workspace with AmbiOBU and AmbiRSU interface packages, V2X transmit and receive APIs, Ambimat-developed message and service definitions, the relevant libraries and headers, API and developer documentation, sample application code and templates including worked V2V and V2I examples, logging, diagnostic, recording and replay examples, deployment instructions, test procedures, and engineering support from Ambimat. Ambimat-developed components can be provided according to programme scope; third-party and open-source components remain subject to their respective licences.
Can the environment run in simulation before hardware arrives?
Yes. The same ROS 2 application graph can run against simulated vehicle and roadside state and against physical units, so a team can build repeatable V2V and V2I scenarios, record and replay runs, study application timing, test message generation and decoding, and run positive and negative security experiments before moving one interface at a time onto hardware.
Last updated 2026-08-20 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: neel.shah@ambimat.com