ros-mobile-bridge 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +28 -0
- package/LICENSE +201 -0
- package/README.md +174 -0
- package/ROADMAP.md +85 -0
- package/SECURITY.md +46 -0
- package/dist/index.cjs +2288 -0
- package/dist/index.cjs.map +1 -0
- package/dist/index.d.cts +737 -0
- package/dist/index.d.ts +737 -0
- package/dist/index.mjs +2275 -0
- package/dist/index.mjs.map +1 -0
- package/package.json +94 -0
package/CHANGELOG.md
ADDED
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to `ros-mobile-bridge` will be documented in this file.
|
|
4
|
+
|
|
5
|
+
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
6
|
+
|
|
7
|
+
## [0.1.0] - 2026-05-20
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- Initial public release. `IProtocolClient` interface and two implementations: `FoxgloveClient` (Foxglove WebSocket v1, binary + JSON, CDR decoding) and `RosbridgeClient` (rosbridge v2 JSON over WebSocket, no `roslib` dependency).
|
|
12
|
+
- `ProtocolManager` factory with URL sanitization (strips `ws://`/`http://` prefixes, trailing `:port`, validates via `URL`).
|
|
13
|
+
- Per-subscription adaptive throttle driven by JS-thread lag (`SubscriptionBandwidth`), observable via `getSubscriptionStats`. The throttle curves themselves are overridable per-client via `ProtocolClientOptions.presetOverrides` — host applications shipping to a different device profile than the library's default tuning can supply their own bucket curves without forking. `BucketDef` and `ThrottleMode` are public types; `DEFAULT_PRESETS` is exported for consumers building extensions on top of the defaults.
|
|
14
|
+
- Per-subscription circuit breaker (`CircuitBreaker`) with exponential cooldown, manual retry, and disable. Observable via `getBreakerState`, `getBreakerNextRetryAt`, `onBreakerStateChange`.
|
|
15
|
+
- Control-priority publish outbox: `PublishOptions.priority: 'control'` for E-Stop, dead-man's-switch, and gesture-driven publishes that must not be starved by incoming-message parse work.
|
|
16
|
+
- `publishZeroTwist()` convenience for safety-critical disconnect / background paths.
|
|
17
|
+
- `ensureAdvertised(topic, schemaName)` to pre-advertise channels before time-critical first publish.
|
|
18
|
+
- Service discovery for both transports: `getAvailableServices`, `onServicesChange`.
|
|
19
|
+
- Schema templates: `getSchemaTemplate(schemaName)` derives default JSON from ros2idl, ros2msg, or JSON Schema declarations carried inline by Foxglove WS (returns `null` for rosbridge, which does not carry schemas inline).
|
|
20
|
+
- Diagnostics readers: `getMaxLagMs`, `getLagStats`, `getLagHistoryCsv`, `clearLagHistory` for consumers building "currently throttled" badges and bug-report exports.
|
|
21
|
+
- `DEFAULT_PORTS` constant: `{ 'foxglove-ws': 8765, rosbridge: 9090, zenoh: 7447 }`.
|
|
22
|
+
- Apache 2.0 license, security disclosure process, and contribution guidelines.
|
|
23
|
+
|
|
24
|
+
### Roadmap (not in this release)
|
|
25
|
+
|
|
26
|
+
- `ZenohClient` ships as an unimplemented skeleton (every method throws). `ProtocolManager.connect` throws a clear "Zenoh support is planned for v0.2.0" error for `protocol: 'zenoh'`. The class is not exported from `index.ts` in v0.1.0.
|
|
27
|
+
|
|
28
|
+
[0.1.0]: https://github.com/AuriLabsTech/ros-mobile-bridge/releases/tag/v0.1.0
|
package/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for describing the origin of the Work and
|
|
141
|
+
reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright 2026 Benjamín Arratia
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/README.md
ADDED
|
@@ -0,0 +1,174 @@
|
|
|
1
|
+
# ros-mobile-bridge
|
|
2
|
+
|
|
3
|
+
Protocol adapters for connecting JavaScript and TypeScript runtimes to ROS 2 robots. One `IProtocolClient` interface, two transports today (Foxglove WebSocket v1 and rosbridge v2), Zenoh on the [public roadmap](./ROADMAP.md). Runs in React Native, browsers, Node.js, and Electron from the same build.
|
|
4
|
+
|
|
5
|
+
- Apache 2.0 licensed.
|
|
6
|
+
- Zero React Native imports, zero Expo, zero Node-only globals. The package code uses only `WebSocket`, `TextEncoder`/`TextDecoder`, standard typed arrays, and standard timers.
|
|
7
|
+
- Foxglove WebSocket v1 with CDR binary decoding (ros2idl, ros2msg) and JSON.
|
|
8
|
+
- rosbridge v2 implemented directly over `WebSocket`, no `roslib` dependency.
|
|
9
|
+
- Adaptive throttle driven by JS-thread lag, per-subscription circuit breaker, control-priority publish outbox. Each one is observable through the public API, never hidden.
|
|
10
|
+
- 100% typed public surface. `IProtocolClient` is the contract; everything else is implementation detail.
|
|
11
|
+
|
|
12
|
+
## Install
|
|
13
|
+
|
|
14
|
+
```bash
|
|
15
|
+
npm install ros-mobile-bridge
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
Or with yarn / pnpm:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
yarn add ros-mobile-bridge
|
|
22
|
+
pnpm add ros-mobile-bridge
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Node.js consumers need a WebSocket polyfill (Node 22+ ships one natively, earlier versions need `ws` or similar). React Native and browsers have `WebSocket` globally.
|
|
26
|
+
|
|
27
|
+
## Quick start
|
|
28
|
+
|
|
29
|
+
```typescript
|
|
30
|
+
import { ProtocolManager } from 'ros-mobile-bridge';
|
|
31
|
+
|
|
32
|
+
const manager = new ProtocolManager();
|
|
33
|
+
|
|
34
|
+
const client = await manager.connect({
|
|
35
|
+
protocol: 'foxglove-ws',
|
|
36
|
+
host: 'robot.local',
|
|
37
|
+
});
|
|
38
|
+
|
|
39
|
+
const unsubscribe = client.subscribe('/odom', (msg) => {
|
|
40
|
+
console.log(msg.topic, msg.data);
|
|
41
|
+
});
|
|
42
|
+
|
|
43
|
+
client.publish('/cmd_vel', 'geometry_msgs/msg/Twist', {
|
|
44
|
+
linear: { x: 0.5, y: 0, z: 0 },
|
|
45
|
+
angular: { x: 0, y: 0, z: 0 },
|
|
46
|
+
});
|
|
47
|
+
|
|
48
|
+
await manager.disconnect();
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
`port` defaults to the protocol's standard (`8765` for `foxglove-ws`, `9090` for `rosbridge`); `secure` defaults to `false`. Override either when you need to:
|
|
52
|
+
|
|
53
|
+
```typescript
|
|
54
|
+
const client = await manager.connect({
|
|
55
|
+
protocol: 'rosbridge',
|
|
56
|
+
host: 'robot.example.com',
|
|
57
|
+
port: 443,
|
|
58
|
+
secure: true,
|
|
59
|
+
});
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
## Concepts
|
|
63
|
+
|
|
64
|
+
### `IProtocolClient`
|
|
65
|
+
|
|
66
|
+
The single interface every transport implements. Methods are grouped into six concerns: lifecycle (`connect`, `disconnect`, `isConnected`), topic discovery (`getAvailableTopics`, `onTopicsChange`), subscribe and publish (`subscribe`, `publish`, `ensureAdvertised`, `unadvertise`, `publishZeroTwist`), reliability surfaces (the circuit breaker family and `getSubscriptionStats`), services (`callService`, `getAvailableServices`, `onServicesChange`), and schemas (`getSchemaTemplate`).
|
|
67
|
+
|
|
68
|
+
A consumer can write against `IProtocolClient` once and pick the transport at runtime.
|
|
69
|
+
|
|
70
|
+
### Control-priority publishes
|
|
71
|
+
|
|
72
|
+
`PublishOptions.priority: 'control'` routes a publish through a small outbox that drains at the top of every incoming WebSocket message handler. Designed for safety-critical messages (`/cmd_vel`, E-Stop, action cancel) that must not be starved by incoming-message parse work when the JS thread is loaded with camera frames. Defaults to `'data'`.
|
|
73
|
+
|
|
74
|
+
```typescript
|
|
75
|
+
client.publish('/cmd_vel', 'geometry_msgs/msg/Twist', zeroTwist, { priority: 'control' });
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Adaptive throttle and circuit breaker
|
|
79
|
+
|
|
80
|
+
Both reliability features are observable. Read the current throttle bucket per subscription:
|
|
81
|
+
|
|
82
|
+
```typescript
|
|
83
|
+
const stats = client.getSubscriptionStats('/camera/compressed');
|
|
84
|
+
if (stats && stats.adaptiveMinIntervalMs > 0) {
|
|
85
|
+
console.log(`/camera is currently capped at ${stats.bucketLabel}`);
|
|
86
|
+
}
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
Watch breaker state changes:
|
|
90
|
+
|
|
91
|
+
```typescript
|
|
92
|
+
const unwatch = client.onBreakerStateChange('/camera/compressed', (state) => {
|
|
93
|
+
if (state === 'tripped_auto') {
|
|
94
|
+
showFallbackUi();
|
|
95
|
+
}
|
|
96
|
+
});
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
Manual breaker controls (`breakerRetry`, `breakerDisable`) let consumers expose user-driven recovery in their UI.
|
|
100
|
+
|
|
101
|
+
### Host-app injection
|
|
102
|
+
|
|
103
|
+
Construct clients with `ProtocolClientOptions` to receive latency callbacks, route logs, and tell the throttle which mode the user picked:
|
|
104
|
+
|
|
105
|
+
```typescript
|
|
106
|
+
manager.setClientOptions({
|
|
107
|
+
onLatency: (rttMs) => metrics.recordLatency(rttMs),
|
|
108
|
+
logger: console,
|
|
109
|
+
getThrottleMode: () => settings.throttleMode, // 'performance' | 'auto' | 'efficient'
|
|
110
|
+
});
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
These are optional. The library has sensible no-op defaults.
|
|
114
|
+
|
|
115
|
+
### Diagnostics
|
|
116
|
+
|
|
117
|
+
The event-loop lag monitor is the signal the adaptive throttle reads. Consumers can read it too, for diagnostics:
|
|
118
|
+
|
|
119
|
+
```typescript
|
|
120
|
+
import { getMaxLagMs, getLagStats, getLagHistoryCsv } from 'ros-mobile-bridge';
|
|
121
|
+
|
|
122
|
+
console.log(`current max JS-thread lag: ${getMaxLagMs()} ms`);
|
|
123
|
+
console.log(getLagStats()); // p50, p90, p99, count over ~2 min
|
|
124
|
+
console.log(getLagHistoryCsv()); // full history dump for bug reports
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
## Why implement the protocols directly?
|
|
128
|
+
|
|
129
|
+
`ros-mobile-bridge` speaks the Foxglove WebSocket v1 and rosbridge v2 protocols directly over the runtime's global `WebSocket`. It does not wrap `roslib` or the `@foxglove/ws-protocol` SDK.
|
|
130
|
+
|
|
131
|
+
The reason is the reliability layer. The adaptive throttle drops messages before they are parsed, the control-priority outbox flushes safety-critical publishes at the top of every incoming message handler, and the per-subscription circuit breaker responds to JS-thread saturation as it happens. All three need direct ownership of the WebSocket message loop. A client library that parses and dispatches messages for you sits in exactly the spot these features need to own. (`roslib` also pulls in Node-only dependencies that break under React Native.)
|
|
132
|
+
|
|
133
|
+
This is a narrow kind of "from scratch." The genuinely hard parts, CDR deserialization and ROS 2 schema parsing, still come from Foxglove's MIT libraries (`@foxglove/rosmsg2-serialization`, `@foxglove/ros2idl-parser`, `@foxglove/rosmsg`). The hand-written code is only the transport, framing, and dispatch layer the reliability features depend on, which also keeps the runtime dependency surface to three permissively licensed parsing packages.
|
|
134
|
+
|
|
135
|
+
Implementing the protocols directly means each transport supports a deliberate subset. Today that is publish/subscribe and service calls on both; ROS parameter access and connection-graph introspection are on the [roadmap](./ROADMAP.md).
|
|
136
|
+
|
|
137
|
+
## Supported runtimes
|
|
138
|
+
|
|
139
|
+
| Runtime | Status | Notes |
|
|
140
|
+
|---|---|---|
|
|
141
|
+
| React Native (Hermes) | Tested in production | Uses RN's `WebSocket` |
|
|
142
|
+
| Browsers (evergreen) | Tested | Uses native `WebSocket` |
|
|
143
|
+
| Node.js 22+ | Supported | Native `WebSocket` |
|
|
144
|
+
| Node.js 18–21 | Supported with polyfill | Set `globalThis.WebSocket` to a `ws`-compatible implementation |
|
|
145
|
+
| Electron (renderer) | Supported | Browser `WebSocket` |
|
|
146
|
+
|
|
147
|
+
## API stability
|
|
148
|
+
|
|
149
|
+
The package follows semver. Pre-1.0, breaking changes are restricted to minor version bumps (0.1.x → 0.2.0); after 1.0, only majors break. See `CHANGELOG.md` for migration notes.
|
|
150
|
+
|
|
151
|
+
## Documentation
|
|
152
|
+
|
|
153
|
+
- Type-level docs: every public symbol carries TSDoc, surfaced through your editor.
|
|
154
|
+
- Generated reference: `https://aurilabstech.github.io/ros-mobile-bridge/` (published from `main` on release).
|
|
155
|
+
- Examples: `examples/` in this repository.
|
|
156
|
+
- Roadmap: [`ROADMAP.md`](./ROADMAP.md) — current milestone, what `v0.2.0` and `v0.3.0` will deliver, and what is permanently out of scope.
|
|
157
|
+
|
|
158
|
+
## Contributing
|
|
159
|
+
|
|
160
|
+
See [CONTRIBUTING.md](./CONTRIBUTING.md). The short version: discuss non-trivial changes in an issue first, keep the API small, write tests, follow Conventional Commits.
|
|
161
|
+
|
|
162
|
+
## Security
|
|
163
|
+
|
|
164
|
+
See [SECURITY.md](./SECURITY.md) for the coordinated-disclosure process. Email `security@aurilabs.tech` for private reports.
|
|
165
|
+
|
|
166
|
+
## License
|
|
167
|
+
|
|
168
|
+
Apache 2.0. See [LICENSE](./LICENSE).
|
|
169
|
+
|
|
170
|
+
## Acknowledgements
|
|
171
|
+
|
|
172
|
+
This library was extracted from the protocol layer of [Tinca](https://aurilabs.tech/tinca), an iOS and Android ROS 2 teleoperation app, after the layer had stabilized against real hardware. Tinca remains the primary integration test and a reference implementation for a sophisticated mobile consumer of this library, but the library is independent and intended for any JavaScript or TypeScript consumer of ROS 2.
|
|
173
|
+
|
|
174
|
+
Created and maintained by Benjamín Arratia (Auri Labs).
|
package/ROADMAP.md
ADDED
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
# Roadmap
|
|
2
|
+
|
|
3
|
+
`ros-mobile-bridge` follows a milestone-based roadmap. Each milestone targets a concrete release. Versions are not date-bound; they ship when the criteria for the milestone are met.
|
|
4
|
+
|
|
5
|
+
The library reached `v0.1.0` with two production-ready transports (Foxglove WebSocket v1 and rosbridge v2) extracted from a real mobile application's protocol layer. The next two milestones expand the transport set, harden the library against real-world parse-side attacks, and grow the community of consumers.
|
|
6
|
+
|
|
7
|
+
## v0.1.x — Stabilization (current)
|
|
8
|
+
|
|
9
|
+
The `v0.1.x` series consolidates the first public release. Patch releases address bug fixes reported by early consumers, documentation improvements, and the integration-test infrastructure that was deferred from the initial cut.
|
|
10
|
+
|
|
11
|
+
**In scope:**
|
|
12
|
+
|
|
13
|
+
- Bug fixes against real bridges (`foxglove_bridge`, `rosbridge_server`) reported by consumers.
|
|
14
|
+
- Integration tests under `tests/integration/` running pinned versions of both bridges inside Docker Compose.
|
|
15
|
+
- Documentation polish, additional examples (`examples/browser/`, `examples/react-native/` wired into CI).
|
|
16
|
+
- A follow-up refactor consolidating the structural overlap between the two transport clients into shared internal helpers (control-priority outbox, reconnect scheduler, listener-set fan-out, pending-service-call registry, breaker side-effect wiring). The two clients implement different wire protocols but share these support mechanisms; extracting them reduces the maintenance surface without changing the public API.
|
|
17
|
+
|
|
18
|
+
**Out of scope:** any breaking API change, any new transport.
|
|
19
|
+
|
|
20
|
+
## v0.2.0 — Zenoh transport
|
|
21
|
+
|
|
22
|
+
The `ZenohClient` skeleton already exists in `src/ZenohClient.ts` as roadmap-as-code. `v0.2.0` lands the real implementation.
|
|
23
|
+
|
|
24
|
+
**Deliverables:**
|
|
25
|
+
|
|
26
|
+
- Full `ZenohClient` implementation conforming to `IProtocolClient`, using `@eclipse-zenoh/zenoh-ts` as the transport dependency.
|
|
27
|
+
- ROS 2 topic name to Zenoh key-expression mapping following the `rmw_zenoh` convention.
|
|
28
|
+
- CDR decoding integrated for ROS 2 message payloads carried over Zenoh.
|
|
29
|
+
- `ZenohClient` exported from `index.ts`; `ProtocolManager.connect` no longer throws for `protocol: 'zenoh'`.
|
|
30
|
+
- Integration tests against a real `rmw_zenoh` setup (`zenohd` + `zenoh-plugin-remote-api` + a ROS 2 node) in CI.
|
|
31
|
+
- Documentation: a dedicated section in the README describing when Zenoh is the right transport choice versus the existing two, and a runnable example under `examples/zenoh/`.
|
|
32
|
+
|
|
33
|
+
**Why this matters:** Zenoh is the recommended middleware for the next generation of ROS 2 deployments (it underlies `rmw_zenoh`, which the OSRF has positioned as a serious alternative to the default DDS-based middleware). No existing JavaScript or TypeScript library provides a ROS 2 client over Zenoh that works in mobile and web runtimes. `v0.2.0` closes that gap.
|
|
34
|
+
|
|
35
|
+
## v0.3.0 — Hardening and community
|
|
36
|
+
|
|
37
|
+
`v0.3.0` is the security-and-community milestone. It assumes the library has been in use for several months across multiple consumers and that real-world inputs have surfaced edge cases the test suite did not anticipate.
|
|
38
|
+
|
|
39
|
+
**Deliverables:**
|
|
40
|
+
|
|
41
|
+
- A third-party security audit focused on parse-side hardening: malformed Foxglove WebSocket frames, malformed rosbridge JSON envelopes, malformed CDR payloads, oversized messages, prototype-pollution paths, and denial-of-service resistance under adversarial input. Findings addressed and documented in the `CHANGELOG.md`.
|
|
42
|
+
- A fuzz-testing harness in CI (`@fast-check/vitest` or equivalent) covering the parser entry points of all three transports.
|
|
43
|
+
- Public migration notes if any breaking API change is needed as a consequence of the audit; otherwise no breaking changes.
|
|
44
|
+
- Community onboarding work: contributor guide expansion, "good first issue" labels, response-time commitments documented in `CONTRIBUTING.md`, monthly maintainer triage cadence.
|
|
45
|
+
- A discoverable presence in the ROS 2 ecosystem: ROS Discourse announcement, link from `index.ros.org` if accepted, listing in `awesome-ros2`.
|
|
46
|
+
|
|
47
|
+
**Why this matters:** the library will by then be a parser of arbitrary input from untrusted bridges. Security-grade quality is what distinguishes a library a serious robotics company will adopt from a hobby project.
|
|
48
|
+
|
|
49
|
+
## v0.4.0 (provisional) — agent-driven introspection surface
|
|
50
|
+
|
|
51
|
+
Hobbyist and academic ROS 2 users increasingly drive their workflow through AI coding agents (Claude Code, Cursor, Codex, OpenCode). A natural extension is agent-driven configuration of mobile dashboards: the agent already knows the robot's topic graph because it just wrote the nodes, so it can wire widget configurations headlessly and hand the user a ready-to-use dashboard. Prior art in adjacent ecosystems (Marimo's `marimo-pair` skill for collaborative notebook editing, shipped via the cross-tool `skills` package manager) validates the pattern shape.
|
|
52
|
+
|
|
53
|
+
This milestone does **not** build an MCP server inside `ros-mobile-bridge`. Hosting an MCP server requires a runtime-specific transport (stdio on Node, HTTP on browsers / Electron) and would break the four-runtimes-from-one-build promise. Instead, the library exposes the introspection surface an MCP server would need; integrators (mobile apps, CLI tools, agent harnesses) build the transport layer themselves. The command-dispatch safety boundary lives in the integrator that owns the robot connection, not in the library.
|
|
54
|
+
|
|
55
|
+
**Deliverables:**
|
|
56
|
+
|
|
57
|
+
- `getAvailableParameters(): Promise<ParameterInfo[]>` and `getParameter(name)` on `IProtocolClient`, mapped through both Foxglove WebSocket and rosbridge wire protocols. Today the library exposes topic and service introspection but has no concept of ROS parameters; agents driving dashboard configuration may want them for parameter-display widgets.
|
|
58
|
+
- `getSchemaDefinition(schemaName)` returning the parsed message definition (full type information per field), complementing the existing zero-value `getSchemaTemplate`. Returns `null` for transports that do not carry schemas inline (rosbridge), matching `getSchemaTemplate`'s rosbridge fallback shape.
|
|
59
|
+
- Documentation: a dedicated guide page covering "building an MCP server on top of `ros-mobile-bridge`" — the introspection-only contract, the command-dispatch safety boundary (which lives in the consumer, not the library), and worked examples for stdio and HTTP transports.
|
|
60
|
+
- A reference adapter under `examples/agent-mcp/` showing how to wrap the introspection methods as MCP tool definitions, runtime-agnostic, leaving the actual server hosting to the integrator.
|
|
61
|
+
|
|
62
|
+
**Why this matters:** open-source plus AI-agent accessibility for non-experts is what distinguishes a serious robotics library from a thin protocol wrapper. No existing JavaScript ROS 2 client surfaces enough metadata for an agent to drive a dashboard end-to-end. `v0.4.0` ships the contract; downstream projects (including Tinca) ship the experiences on top.
|
|
63
|
+
|
|
64
|
+
## Beyond v1.0
|
|
65
|
+
|
|
66
|
+
`v1.0.0` is not date-bound. It represents the point at which the public API has stabilized enough that breaking changes become exceptional rather than routine. Reaching `v1.0` requires:
|
|
67
|
+
|
|
68
|
+
- At least six months of `v0.x` series usage across multiple consumers without API-breaking pressure.
|
|
69
|
+
- The security audit from `v0.3.0` completed with no unresolved high-severity findings.
|
|
70
|
+
- Documentation site complete: every public symbol with TSDoc, every public concept with a dedicated guide page, every transport with a runnable example.
|
|
71
|
+
- Stable performance characteristics documented (throughput per transport, memory footprint, supported message sizes).
|
|
72
|
+
|
|
73
|
+
Until those criteria are met, the library remains on the `v0.x` series and treats breaking changes as minor-version bumps per the convention documented in the `CHANGELOG.md`.
|
|
74
|
+
|
|
75
|
+
## Out of scope (permanently or for the foreseeable future)
|
|
76
|
+
|
|
77
|
+
This roadmap is opinionated about what the library is **not**:
|
|
78
|
+
|
|
79
|
+
- The library will not become a robotics framework. It will not own state machines, navigation primitives, motion planning, or any robot model.
|
|
80
|
+
- The library will not include UI components. Consumers build their own UI.
|
|
81
|
+
- The library will not implement bridge servers (e.g., a node that runs on the robot and exposes a WebSocket). Those exist (`foxglove_bridge`, `rosbridge_server`) and are out of this library's scope.
|
|
82
|
+
- The library will not auto-discover bridges on a network. Consumers provide the connection URL.
|
|
83
|
+
- The library will not implement transport protocols beyond ROS 2 wire formats. MQTT, Kafka, gRPC, plain HTTP are out of scope.
|
|
84
|
+
|
|
85
|
+
Out-of-scope items can become in-scope through a written proposal in `GitHub Discussions` and a substantive case for why they belong in this library rather than as a separate package or in the consumer code. The default answer is "no."
|
package/SECURITY.md
ADDED
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
# Security Policy
|
|
2
|
+
|
|
3
|
+
## Reporting a Vulnerability
|
|
4
|
+
|
|
5
|
+
If you believe you have found a security vulnerability in `ros-mobile-bridge`, please report it privately. **Do not open a public GitHub issue.**
|
|
6
|
+
|
|
7
|
+
Email: `security@aurilabs.tech`
|
|
8
|
+
|
|
9
|
+
Include:
|
|
10
|
+
|
|
11
|
+
- A description of the issue and its impact.
|
|
12
|
+
- Reproduction steps or a proof of concept, if available.
|
|
13
|
+
- The affected version(s) of the package.
|
|
14
|
+
- Your name and contact details (optional, for credit).
|
|
15
|
+
|
|
16
|
+
## Process and Timeline
|
|
17
|
+
|
|
18
|
+
- **Acknowledgement:** within 3 business days of receipt.
|
|
19
|
+
- **Triage and assessment:** within 7 business days.
|
|
20
|
+
- **Fix or mitigation for confirmed high-severity issues:** within 30 days of confirmation.
|
|
21
|
+
- **Coordinated disclosure:** we will work with you on a disclosure timeline. Public disclosure happens after a fix is released, or after 90 days if no fix is feasible. Earlier disclosure is possible by mutual agreement (for example, if a vulnerability is already being exploited in the wild).
|
|
22
|
+
|
|
23
|
+
A CVE is requested when applicable.
|
|
24
|
+
|
|
25
|
+
## In Scope
|
|
26
|
+
|
|
27
|
+
- The published npm artifact and its runtime behavior.
|
|
28
|
+
- Parse-side hardening: the library parses arbitrary input from any bridge a consumer points it at, so denial-of-service resistance against malformed Foxglove WebSocket frames, malformed rosbridge JSON envelopes, and oversized payloads is a first-class concern.
|
|
29
|
+
- Memory-safety issues (unbounded buffers, prototype pollution, etc.) in the library's own code.
|
|
30
|
+
|
|
31
|
+
## Out of Scope
|
|
32
|
+
|
|
33
|
+
- The `examples/` directory: those exist to demonstrate usage and are not part of the published package.
|
|
34
|
+
- The test infrastructure (`tests/`, `tests/_helpers/`, `tests/integration/`, `tests/manual/`).
|
|
35
|
+
- Third-party bridge software the library connects to (`foxglove_bridge`, `rosbridge_server`, future `zenoh-plugin-remote-api`). Report bridge issues to those projects directly.
|
|
36
|
+
- Vulnerabilities in transitive dependencies that do not affect this library's runtime behavior. Report those to the relevant upstream package.
|
|
37
|
+
- Misconfigurations in the host application that consumes this library.
|
|
38
|
+
|
|
39
|
+
## Supported Versions
|
|
40
|
+
|
|
41
|
+
| Version | Supported |
|
|
42
|
+
|--------|-----------|
|
|
43
|
+
| 0.1.x | Yes |
|
|
44
|
+
| < 0.1 | No (pre-release) |
|
|
45
|
+
|
|
46
|
+
We backport security fixes to the latest minor only. Older minors receive a CVE acknowledgement; consumers should upgrade.
|