Camera Feed
FREELive video via topic, MJPEG, or WebRTC
When to reach for it
Camera Feed shows the actual image, not a derived reading of it. Reach for it to frame a manipulator task, check exposure, or confirm the lens isn't fogged. For range data with no camera involved, Laser Scan (Pro) is cheaper on bandwidth. Free tier is locked to Topic Subscription: Transport itself is Pro-only, so MJPEG HTTP and WebRTC need an upgrade first.
Worked example: TurtleBot 4's OAK-D camera
The OAK-D publishes RGB preview frames as sensor_msgs/CompressedImage on /oakd/rgb/preview/image_raw/compressed. Point Topic Subscription at it and the widget detects the compressed schema, defaulting Max Frequency (Hz) to 15Hz. A raw sensor_msgs/Image topic decodes through a heavier path: if you land there instead and the feed feels sluggish, lower Max Frequency (Hz) yourself.
Watch out for
- Landing on a raw
sensor_msgs/Imagetopic triggers a persistent banner nudging you toward a/compressedsibling or a Pro transport. Look for one before assuming raw is your only option. - Show Topic Rate (Hz) is on by default. The amber pill next to it means the bridge is throttling delivery, not that the feed died.
- Camera Feed's picker and template previews show a synthetic frame, a triggered scan sweep in grid view, a still frame elsewhere, never your real footage, so you can't judge latency until it's applied.
Configuration fields
How the video reaches the phone.
WITH PROFree uses Topic Subscription, which routes frames through the protocol bridge. It auto-detects whether the topic is compressed (sensor_msgs/CompressedImage, fluid playback) or raw (sensor_msgs/Image, throttled for safety). WebRTC opens a direct peer connection for sub-100ms feel (the difference between "remote control" and "telepresence"). MJPEG HTTP taps any HTTP camera stream on the robot side without going through ROS at all.
The topic this widget reads data from. While connected, tap to pick from the topics the robot advertises.
Full URL of an MJPEG stream the robot serves, e.g. http://<robot-ip>:8080/stream. On the robot, run an MJPEG server such as ROS web_video_server.
WebSocket URL of your WebRTC signaling server, e.g. ws://<robot-ip>:8443. Needs a WebRTC sender plus a signaling endpoint running on the robot.
Cap on the WebRTC bitrate.
WITH PROAuto adapts to network conditions. Pinning to Low/Med saves data on a hotspot or LTE link; Max gives the cleanest picture on a strong WiFi connection. Useful when streaming to multiple operators at once.
Caps the topic subscription rate. The topic may publish faster; this throttles delivery on the app side to save CPU and bandwidth. Separate from the connection profile and from how fast the topic itself publishes; it only limits this widget. Quality presets other than Auto override it.
Caps how many frames per second this widget fetches from the MJPEG endpoint (the snapshot poll rate). Lower it to save bandwidth and CPU; the stream itself is unaffected.
Tradeoff between fidelity and load on the phone.
Show the received message rate (Hz) in the top bar, including the amber indicator when the bridge throttles delivery.
Also show the rendered frames-per-second in the top bar. Handy for spotting when decoding falls behind the received rate.