Skip to content

RPi: add a video stream IP address setting - #52

Open
rmackay9 wants to merge 3 commits into
ArduPilot:masterfrom
rmackay9:rpi-network-ip-param
Open

rmackay9 wants to merge 3 commits into
ArduPilot:masterfrom
rmackay9:rpi-network-ip-param

Conversation

@rmackay9

@rmackay9 rmackay9 commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

This adds the ability on the RPI target for the user (or person configuring the vehicle) to override the IP address that is sent in the VIDEO_STREAM_INFORMATION messages' URI thus making it easier for users to select the video they want displayed on the GCS.

The underlying problem on the RPi is the camera app sits behind mavlink-router, so MAVLink messages reach it from 127.0.0.1 and it cannot tell which of the Pi's IP addresses the GCS can reach.

In these cases, the RTSP URI sent in VIDEO_STREAM_INFORMATION comes from a fixed rule codified in route_local_ipv4() and interface_ipv4(). The rule is: prefer an address on 192.168.144.x, otherwise use the numerically lowest IPv4 address on the Pi. On my setup this results in rtsp://192.168.144.20:8554/video1 appearing in the video-stream-information but this is not actually accessible by the GCS. Instead we need to use either the WifiAP IP address (e.g. 10.0.2.1) or the VPN's (e.g. 10.147.17.100)

This PR adds a "Video stream IP address" setting ([network] video_ip_address) on the web interface's Network tab. When set, it is used in the RTSP URI; when blank, the existing automatic choice is kept. It applies without restarting the camera app.

Other changes:

  • Replaces the CAMERA_APP_VIDEO_ADDRESS environment variable which was only used on the RPI backend. This was added recently to resolve the same problem this PR fixes so we don't need it any more
  • The RPI's network tab loses 4 unused fields (Interface, Primary address, Secondary address and Gateway)

This PR doesn't affect other targets.

Testing:

  • Claude Code (host builds only, no hardware): added RPi host builds of the camera app and web service, with tests that the RTSP URI uses the setting (including changing it while the app runs) and that the web page saves and validates it.
  • I'll test on hardware before merging.

Claude helped me greatly in creating this PR

rmackay9 and others added 2 commits October 15, 2026 17:15
Replace CAMERA_APP_VIDEO_ADDRESS with [network] video_ip_address, the
IPv4 address advertised in VIDEO_STREAM_INFORMATION RTSP URIs. Blank
keeps the automatic choice. It applies without a restart. Adds an RPi
host build to test it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Show the new setting on host-OS targets and hide the interface and
address fields the camera app ignores there.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@AP-Review

AP-Review commented Oct 16, 2026 •

Copy link
Copy Markdown

Deprecated — see below for the updated review.

Previous review (2026-10-16)

Automated review note — AI-generated (Claude+Codex), validated against the live diff. Please sanity-check before acting.
Verdict: COMMENT

Reviewed at head 313194cdda.
Full report: https://firmware.ardupilot.org/Tools/APReview/DevCallReviews/PRReviews/ardupilot/ap_cameragimbal/52/1.html#prAP_CameraGimbal-52

Thanks Randy. This looks good: the new tests pass for me, and the live-reload test fails correctly when the reload_config copy is removed.

One small upgrade issue. CAMERA_APP_VIDEO_ADDRESS is now ignored entirely (camera_app/src/protocol/mavlink_server.cpp:645, https://github.com/ardupilot/AP_CameraGimbal/pull/52/files#diff-862008e059849dbb1a8cdab3af55eb729c57bbfe996836b8f379ad2c54d054bbR645). Anyone who followed the previous README and added the video-address.conf systemd drop-in will silently lose the override after updating. On a multi-network Pi the camera then goes back to advertising the guessed address to the GCS. I confirmed this by running the base and head route_local_ipv4 with CAMERA_APP_VIDEO_ADDRESS=10.9.9.9: base advertises 10.9.9.9, head advertises the interface address. Could you either keep getenv("CAMERA_APP_VIDEO_ADDRESS") as a fallback when video_ip_address is blank, or add a line near packaging/rpi_libcam_caddx/README.md:117 (https://github.com/ardupilot/AP_CameraGimbal/pull/52/files#diff-57a13d56b565ab46e64820b7f564b4fe3925995aedb46c54c76dd0c32be481ccR117) telling users to move the value into the web setting and delete the drop-in? Low severity, since the variable only existed for about 10 days.

Not tested: real Pi/libcamera hardware with a GCS, and the full make test suites.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@rmackay9

Copy link
Copy Markdown
Contributor Author

Thanks for the review, my AI and I have added a comment regarding the removal of CAMERA_APP_VIDEO_ADDRESS. As the AI Reviewer mentioned though the removal is low-severity because it's only been in there for 10 days and we haven't done a release since then. Also I'm the only user of the cm4 backend so far. I'd love more, but for now, it's just me.

@AP-Review

Copy link
Copy Markdown

Automated review note — AI-generated (Claude+Codex), validated against the live diff. Please sanity-check before acting.
Verdict: ACCEPT

Reviewed at head 701aec0af5.
Full report: https://firmware.ardupilot.org/Tools/APReview/DevCallReviews/PRReviews/ardupilot/ap_cameragimbal/52/2.html#prAP_CameraGimbal-52

Thanks Randy. The README note at packaging/rpi_libcam_caddx/README.md:123 (https://github.com/ArduPilot/AP_CameraGimbal/pull/52/files#diff-57a13d56b565ab46e64820b7f564b4fe3925995aedb46c54c76dd0c32be481ccR123) covers the CAMERA_APP_VIDEO_ADDRESS upgrade point from the earlier review. Nothing reads the variable any more, so the note is accurate. No code fallback is needed.

I re-checked at 701aec0. The RPi unit cases, test_rpi_video_ip_address.py (including live reload) and test_rpi_parameters.py all pass. The live-reload test still fails if the reload_config copy is removed. The mt11 web host still builds with the defaults static_assert. Nothing else to raise.

Not tested: real Pi/libcamera hardware with a GCS, and the full camera_app make test (it needs SS928 SDK headers we can't fetch here).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants