Improvements for the OPi image #19
Conversation
There was a problem hiding this comment.
The system performance on 24.04 seems diffrent. I'm running two OV9281 cameras with AprilTag pipelines at 1280x720 (decimation=2) and getting 35 fps with ~23 ms latency. When I check the CPU usage, it's only about 65-70% distributed across all 8 cores. This makes me wonder if there is a bottleneck in the pipeline.
install_opi5.sh
Outdated
| wget https://git.io/JJrEP -O install.sh | ||
| chmod +x install.sh | ||
|
|
||
| sed -i 's/# AllowedCPUs=4-7/AllowedCPUs=4-7/g' install.sh | ||
| sed -i 's/# AllowedCPUs=4-7/AllowedCPUs=0-7/g' install.sh | ||
|
|
||
| ./install.sh -n -q |
There was a problem hiding this comment.
Since you disabled networking support / NetworkManager via the -n in your previous commit, PhotonVision can no longer set the device hostname.
There was a problem hiding this comment.
This is temporary, and part of the reason this is still draft. I have some more commits that I'll push to improve networking on OPis.
There was a problem hiding this comment.
The latest pushes have re-enabled network management.
install_opi5.sh
Outdated
| # when the coprocessor isn't connected to the ethernet | ||
| cat > /etc/NetworkManager/conf.d/50-ignore-carrier.conf <<EOF | ||
| [main] | ||
| ignore-carrier=* |
There was a problem hiding this comment.
This might be dangerous on a robot network where ethernet cables can intermittently be unplugged.
There was a problem hiding this comment.
Can you share more details of the failure mode that you're concerned about? I'm testing different network setting to understand how they impact startup time and network behavior to try to find a configuration that provides the most stability and predictability, so understanding what could go wrong from your perspective would be a big help.
|
The latest push includes a revised network configuration that defaults to DHCP + link-local fallback. It also waits for a network connection (or a timeout) before starting the photonvision service. When connected to a network during the first boot, this increases the chances that photonvision will get a valid network connection name. The downside is that it can cause a 1 to 2 minute delay in startup when the coprocessor isn't connected to any network. I'm not sure if this is a real problem, since there isn't much point in using photonvision if it isn't connected to a network, but that remains to be seen. I think this is now ready for general testing and would like to get feedback on OPi5, OPi5 Plus, and OPi5 Pro if people are willing to do the testing. |
OPi5_CIDATA/user-data
Outdated
| - name: ubuntu | ||
| password: photon |
There was a problem hiding this comment.
we'll need to update our downstream documentation with the new login info
There was a problem hiding this comment.
pi/raspberry still works. This is a small change to the default ubuntu/ubuntu username so I didn't have to change the password every time I ssh'd in to a new image. I can change it back to ubuntu/ubuntu.
| # cat > /etc/netplan/00-default-nm-renderer.yaml <<EOF | ||
| # network: | ||
| # renderer: NetworkManager | ||
| # tell NetworkManager not to wait for the carrier on ethernet, which can delay boot | ||
| # when the coprocessor isn't connected to the ethernet | ||
| # cat > /etc/NetworkManager/conf.d/50-ignore-carrier.conf <<EOF | ||
| # [main] | ||
| # ignore-carrier=* |
There was a problem hiding this comment.
Why's this still commented out?
There was a problem hiding this comment.
Ignoring the carrier may change current behavior on the robot. I'm not sure that it's a problem, but I'd like to leave it commented out until I have a chance to test on a robot network to make sure that nothing unexpected happens.
| echo "Installing additional things" | ||
| sudo apt-get update | ||
| apt-get install -y network-manager net-tools libatomic1 | ||
| # set NetworkManager as the renderer in cloud-init |
There was a problem hiding this comment.
I've got some reservations about the approach using cloud-init.
The upstream image exposes these on a separate device partition for editing on Windows. That's all fine, but it would be confusing for these files to be present yet not honored after first boot. IMO either keep cloud-init and always execute it (with a boot performance penalty) or just remove it entirely.
There was a problem hiding this comment.
My understanding of cloud-init is that it doesn't regenerate the network configuration on every boot, but I'll admit that it isn't entirely clear to me from the documentation. In addition, when photonvision changes the IP to static, NetworkManager adds it's own configuration file to /etc/netplan which will override any changes made in the cloud-init setup files.
|
Looks like there are merge conflicts now? |
Easy fix. I've removed a few networking-related things from this PR because I'd like to do more testing. The image is working well and is ready for merging. |
This PR includes a significantly re-written
install_opi5.shthat:telling NetworkManager not to wait for a carrier signal (this significantly speeds startup when not connected to ethernet, but may not be needed)<- moved to a future PR for more testingdisabling networkd-wait-online<- moved to a future PR for more testingmanually configuring the ethernet with a static address so that it is recognized as an interface even if DHCP isn't available at boot<- not implemented as this is probably not the right approachThe benefits of these changes are pretty clear:
Since these are such large changes, it would be good to have people test this on Orange Pis. I've done a lot of testing on an OPi5, but I don't have an OPi5 Plus and I'm concerned that the network configuration will need to be modified for the dual ethernet ports.