Physical AI Radar: an embodied AI morning brief with an evidence level on every item

Up to 8 embodied AI items a day from arXiv, vendor blogs and media, in eight lanes, tagged O/R/M, numbers quoted as published; open rules, reproducible offline.

Physical AI Radar is an automatically generated morning brief on embodied AI. Every day it picks at most 8 items from arXiv, vendor blogs, and industry media, assigns each to one of eight lanes, and tags each with an evidence level (official primary source, paper preprint, secondhand media report). The problem it addresses is simple: vendor self-reports, unreviewed preprints, and secondhand coverage are often read in the same feed, and numbers are often repeated out of context. The radar labels these kinds of sources separately, quotes numbers as they appear in the original, and keeps all of its ranking rules in the repository, so any issue can be rerun offline.

What it does every day

It publishes at 07:40 every day (Asia/Singapore, which is 23:40 UTC the previous day), when a scheduled job on the maintainer’s machine runs scripts/publish_daily.sh. The pipeline has several stages:

  • fetch: six cs.RO queries against the arXiv API (falling back to the category RSS feed when the API is unavailable), plus 10 official and media sources: AWS, NVIDIA (Technical Blog and Blog), Google DeepMind, Hugging Face, Toyota Research Institute, IEEE Spectrum Robotics, The Robot Report, Leiphone (雷峰网, a Chinese tech news site), and MONOist. It reads only declared machine-readable endpoints (Atom / RSS / documented APIs), does not scrape article bodies, and does not bypass paywalls.
  • distill: relevance threshold, lane assignment, number extraction, explainable scoring, and capped selection.
  • render / feeds / site: generates the daily issue in Chinese, English, and Japanese, the radar sections of the three READMEs, a weekly digest, Atom and JSON Feed, radar/latest.json, and the GitHub Pages landing page.
  • commit: commits only when the working tree has actually changed.

“At most 8 items” is a ceiling, not a quota: the 2026-09-28 issue carried only 4 items (3 [R], 1 [M]).

Classification and scoring: readable rules throughout

The eight lanes are defined in data/taxonomy.json: foundation models (VLA / WAM); data engines; training and self-improvement; simulation and evaluation; edge and real-time; safety, permissions, and compliance; systems and orchestration; and embodiment and supply chain. Each lane has a set of keywords and a weight (0.95 to 1.15). Items are classified by whole-word matching on the title plus abstract, so ppo does not match inside “support” and thor does not match inside “author”; the lane with the highest score (hit count × lane weight) wins. Items from general-purpose blogs and sources not dedicated to robotics must also hit at least one anchor term (robot, humanoid, VLA, world model, ROS 2, and others, 85 in total), or they are dropped.

The scoring formula is in docs/METHODOLOGY.md:

score = min(lane_hits, 6) × 0.35 × lane_weight
      + evidence_bonus        # O 0.60 · R 0.35 · M 0.10
      + Σ signal_bonus        # closed_loop 0.50 · real_robot 0.40 · numbers 0.30
                              # open_release 0.25 · latency 0.20
      + recency_bonus         # same day 1.0 · 1 day 0.8 · ≤3 days 0.5 · ≤7 days 0.25
      + (source_weight − 1.0)

Selection constraints: a minimum score of 0.9, at most 2 items per lane, and at most 8 items overall. There are also soft caps of 3 items per source and 4 per evidence level; the first pass respects every cap, and the second pass fills remaining slots subject only to the per-lane cap. Links published within the last 30 days are not selected again (URLs are normalized first, and arXiv links have their version suffix removed). There is also same-story deduplication: when a vendor’s original post and a media write-up cover the same event, only the higher-ranked one is kept. The repository says plainly that this bias is intentional: items with real-robot or closed-loop evidence rank ahead of items that only push benchmark numbers.

Numbers are quoted, never recomputed

distill.extract_numbers extracts percentages, multipliers, ms / Hz / fps, parameter counts, hours and demonstration counts, GB / W / kg / DoF, and so on. It shows at most 4 per item, each with a few words of surrounding original text (distill.number_context), so readers can judge for themselves what the number measures. The code does not guess metric names from nearby words. The example in the methodology is “raises success rate and tracking accuracy by at least 24% and 47%”: the metric name closest to 24% happens to be the wrong one. If the original number is wrong, the radar will be wrong too, which is why every item links to its source.

The translation policy is fixed as well: titles are never translated, English abstracts are shown as block quotes, and no machine translation is used anywhere in the pipeline. The “why it matters” line has three possible sources, in order of priority: human curation, agent drafting, and template assembly. Agent-drafted lines are labeled individually, and the page states which agent and model drafted them. Any number in such a line must already appear on that day’s page, and the line is reviewed by a separate model that took no part in drafting. Once all deterministic checks pass, it is merged automatically with no prior human review, and the page says so. The drafting and review agents have only read, grep, and glob permissions; they cannot run a shell or access the network.

How to use it

The feeds and data are static files on GitHub Pages, so no account or key is needed:

R=https://noteflowai.github.io/physical-ai-radar/radar
# Today's picks: evidence level, lane, title
curl -s $R/latest.json | jq -r '.picked[] | "[\(.evidence)] \(.lane)\t\(.title)"'
# Only items with checkable numbers
curl -s $R/latest.json | jq -r '.picked[] | select(.numbers | length > 0) | "\(.numbers | join(", "))\t\(.title)"'

latest.json also contains a fetch block recording which sources were tried and which responded successfully that day, the item count per source, and which sources did not respond. For example, in the 2026-09-28 issue all 11 sources responded, arXiv was read through the category RSS fallback, and the candidate pool held 433 items. python3 -m pairadar.health uses the last 14 days of records to identify sources that fail persistently.

Reproducing it locally requires only Python 3.10+, with no pip install:

git clone https://github.com/noteflowai/physical-ai-radar.git
cd physical-ai-radar
python3 -m pairadar --offline --out /tmp/radar   # no network; writes output elsewhere
python3 -m pairadar                             # fetches today's content (rewrites the repo in place)
python3 -m unittest discover -s tests

Running without --out rewrites the README, radar/, and assets/ in place; add --out if you want to inspect the output first.

Limitations

  • Summaries are extractive and may miss a paper’s real contribution. Lane and signal labels are only for initial screening and are no substitute for reading the original.
  • Lane assignment relies on keywords, so cross-disciplinary work will be misclassified. python3 -m pairadar.lanes flags items classified on a single keyword (thin) or with too small a margin over the runner-up lane (ambiguous). In other words, misclassification can be detected but not prevented.
  • [M] items often contradict each other on shipment volumes and market size; [R] numbers are self-reported by the authors; and for [O] items you still need to distinguish “available on the platform” from “deployed by customers”.
  • Standards and regulation items report only status and dates and do not constitute any safety argument.
  • Status: the code is released in versions, and the latest CHANGELOG entry is 1.2.0 (2026-09-27). Code is MIT-licensed and content is CC BY 4.0. Robot Reel and the radar are maintained by the same authors, so the radar’s curation baseline excludes their own projects.

Links

Related Posts