Ezward
commented
3 years ago EspNow will not work for video; it has a a maximum message length of just 250 bytes. So let's keep the Why part of this ticket, but change the What. I'm going to close this issue.
I've created a new issue to try a different approach
First, let's measure the latency in our current setup where the Esp32Cam in configured as a station and then connects to some local access point. So in this setup, the client also connects to that access point and can then load the web application using the rover's ip address. So the web socket packets must pass through the access point in this configuration.
Then let's implement a scheme where we make the Esp32Cam an access point and connect directly to that access point to load the web application. That scheme eliminates the router as the middle man. This may also simply connecting to the rover if we can choose it's ip address on the network; then we can know a priori what that is; no messing with router ip-allocation. Once we implement that scheme, then measure the latency; hopefully eliminating the router will speed things up.
cgrrty
Why As discussed in issue #8, we would like to reduce the video latency between the rover and the gamepad in order to make FPV mode more usable. One potential latency is the protocol between the rover and the web application. The Open.HD project has addressed this issue in part by writing code to create a custom peer to peer connection between RaspberryPi endpoints using usb wifi adapters' radios. Espressif had created a similar peer to peer protocol between Esp32 endpoints called EspNow.
What Implement a peer to peer video protocol from an Esp32Cam to an Esp32 with a TFT display using EspNow. Measure the latency of transmitting a frame from the Esp32Cam to the endpoint. Compare the peer to peer latency with the web app's websocket latency.