Repository navigation
EdgeFirst Radar Publisher v1.8.0
EdgeFirst Radar Publisher v1.8.0
Installation
Download Binaries
| Platform | edgefirst-radarpub | drvegrdctl |
|---|---|---|
| Linux x86_64 | edgefirst-radarpub-linux-x86_64 |
drvegrdctl-linux-x86_64 |
| Linux ARM64 | edgefirst-radarpub-linux-aarch64 |
drvegrdctl-linux-aarch64 |
| Configuration | radarpub.default |
# Download and install (ARM64 example for Maivin/Raivin)
wget https://github.com/EdgeFirstAI/radarpub/releases/download/v1.8.0/edgefirst-radarpub-linux-aarch64
wget https://github.com/EdgeFirstAI/radarpub/releases/download/v1.8.0/drvegrdctl-linux-aarch64
chmod +x edgefirst-radarpub-linux-aarch64 drvegrdctl-linux-aarch64
sudo mv edgefirst-radarpub-linux-aarch64 /usr/local/bin/edgefirst-radarpub
sudo mv drvegrdctl-linux-aarch64 /usr/local/bin/drvegrdctl
# Install default configuration (optional)
sudo cp radarpub.default /etc/default/radarpubWhat's Changed
The eth and net library signatures change without compatibility shims; radarpub ships as an application and these modules are internal to its binaries and examples.
Added
TARGETS_LATENCYandCUBE_LATENCY(--targets-latency,--cube-latency): sensor processing latency in nanoseconds subtracted from the receive time to estimate acquisition time, default 110 ms (EDGEAI-1942)
Changed
- The Zenoh sample timestamp equals
header.stamponradar/targets,radar/clusters,radar/cube,radar/infoandtf_static(EDGEAI-1942) radar/targetsis stamped from the kernel receive time of the first CAN frame of the target list instead of the time parsing finished (EDGEAI-1942)radar/cubeheader.stampis host time from the kernel receive time of the start-of-frame packet instead of the radar's power-on clock; the sensor time remains inRadarCube.timestamp(EDGEAI-1942)radar/clustersuses the stamp of the newest target list instead of reading the clock again (EDGEAI-1942)radar/infoandtf_staticare re-stamped at each republish instead of keeping the startup time (EDGEAI-1942)- Track lifetimes run on
CLOCK_MONOTONIC, so wall-clock steps no longer affect tracking (EDGEAI-1942) - Port 50063 uses the same batched
recvmmsgreceiver as port 50005 and waits on socket readiness (EDGEAI-1942) - Dependencies updated to their latest semver-compatible releases, including Zenoh 1.10.1
- Library API:
net::port5andnet::port63sendnet::Datagrams(packets with per-packet receive times) instead ofVec<u8>;eth::RadarCubeReader::readtakes the packet receive time;eth::RadarCubeandcan::Framecarryrx_time(EDGEAI-1942)
Fixed
- The 2 MiB UDP receive buffer is requested with
SO_RCVBUFFORCE, falling back toSO_RCVBUF; the defaultnet.core.rmem_maxsilently capped it at 208 KiB, dropping radar cube packets. A warning is logged when the granted size is smaller than requested (EDGEAI-1942) - Rustdoc build with
-D warningsfailed on an unescapedComplex<i16>in theRadarCubeReaderdocumentation - Documentation referred to the removed
drvegrd-rerunbinary; it now points to theradar_viewerandzenoh_viewerexamples
Removed
- Orphaned
src/rerun.rs, which no build target compiled since the viewers moved toexamples/in 1.6.0
Full Documentation: https://github.com/EdgeFirstAI/radarpub#readme