Infinite Ride connects mobile apps, platform services and vehicle terminals. The phone provides interaction, navigation and media capture permitted by its operating system. The terminal provides display, vehicle drivers and observed state. The platform manages application identity, device licensing and business scope.
Choose the side you are building
| Goal | Integration | First step |
|---|---|---|
| Build instrument or vehicle firmware with the existing mobile app | Infinite Ride APP + hardware SDK | SDK and device setup |
| Build a branded Android / iOS app | APP SDK + platform services | APP SDK architecture and integration |
| Build both the phone and terminal | Both SDKs, with separate host and BSP adapters | Agree on model capabilities, then complete each side’s first connection |
| Evaluate a supported P4+C6 display board | Complete Core reference application | ESP32-P4 open example |
How an operation completes
Step-by-step notes
- Platform configures app and device capabilities
The platform registers application identity, manufacturer scope and device licenses. The APP obtains the model's signed configuration.
- APP SDK authenticates the primary connection
The current APP uses BLE discovery, PIN and first binding, then guides the user into the primary Wi-Fi connection.
- Hardware SDK validates and dispatches the command
The SDK checks the session, authorization and request validity, then delivers a command event to the terminal application.
- BSP executes and confirms the observed result
The terminal application invokes CAN, UART or GPIO drivers once, then reports the result and actual state through the SDK.
- APP refreshes state and available controls
The APP updates its UI using primary authentication, execution receipts and fresh vehicle state.
Platform configuration sets the authorized scope; terminal runtime capabilities determine actual support. Wi-Fi / Bluetooth indicators describe links. Vehicle controls also require valid primary authentication and vehicle state. See the four lifecycle diagrams for startup and shutdown.
What you can prepare from the website
These pages provide API contracts, copyable call examples and links to the open reference application. They let you evaluate responsibilities, platform requirements and porting scope.
Running on hardware requires a matching binary package, a registered application identity and a target device license through the integration team. SDK delivery is closed-source binary. Functions named board_* belong to your BSP. Example platform sessions must come from a real login response.
Work toward three milestones:
- Connection: BLE discovery and PIN, cloud binding, then primary Wi-Fi authentication.
- One complete feature: phone theme reflected on the LCD, or a vehicle command followed by an observed state report.
- Recovery and delivery: binding retained after reboot, vehicle selection, reconnects, foreground/background mirroring and target-feature acceptance on devices.
Terminology
| Term | Meaning on this site |
|---|---|
| Terminal / instrument | Terminal is the general vehicle-side device; an instrument is a terminal with a display |
| Managed | The moto_terminal_* interface wraps Core tasks and queues; it is not a cloud hosting service |
| Core | The moto_* interface lets the application schedule instances, threads and ports; it can reuse the SDK network runtime |
| BSP | Board support layer for radio, storage, display and vehicle drivers |
| owner | The bound device user; an “owner thread” is the application thread serializing Core work |
| generation | A lifecycle identifier for a link or asynchronous operation, used to reject stale results |
| Product version / ABI / package revision | Product identity, binary-interface compatibility and delivery-package changes; check all three together |
Continue with first connection, APP SDK integration or the changelog.