Pypilot heading display

[nousian]

Sorry to be confusing... but there are 2 separate uses of udp sockets. One is for commanding the servo in manual control mode (slightly less latency) and may not be worthwhile.

The other use is used by upy_client, and a udp_port is sent to the server as a setting, eg: udp_port=23423

a) The server will then reply to watched values via udp on this port rather than tcp. All watch requests as well as setting other values are still sent via tcp, and the tcp connection should still be monitored. udp is connectionless and therefore not 2 way communication

Ok this clears it a bit.

b) units are in period.
c) If you send a period of 0, you would get the fastest rate.
d) you could run pypilot_client or watch "values" to get the keys

Will try.

e) ok. I would try getting it working with tcp first, and try udp if you really need it. 30 second delay makes no sense, 4 second delay also makes no sense. The udp vs tcp is a split second difference or generally you cannot tell. Play with other platforms and see... Find a way to flush the buffer. I did put the udp support in for a slightly more responsive esp32 control.
f) imu.heel is a lowpass version of imu.roll

Thanks, will try. I don't foresee problem or 30sec delay like someone - not me - had with tcp, but I have found udp works "nicer" with esp32. I have a hunch it is an issue with esp32 and its ip stack is not being that well fully optimized, but could be some other issues as well. I noticed this myself, I am feeding the heading from my DIY ublox F9 gnss rtk compass with esp32 to nmea 2000, with sending it from rtk receiver to esp32 via udp the end steering result is noticeably better than sending it via tcp. Have not measured the latency difference though, but it must be in the tens of milliseconds range I presume. With linux, tcp vs udp in local networks makes little difference.

And if/when I eventually manage to feed the heading to nmea 2000 to be used by other (commercial) autopilot, the less delay there is the better.