TECH KNOWLEDGE SESSIONS · SESSION CHALLENGES · 2026
Four challenges.
One discipline: evidence before claims.
A campus-security quadruped patrol pilot, a non-contact personal safety escort, an exoplanet review workbench and an agrivoltaic control concept — each presented with its limits, its safeguard rules and its named unknowns, in the same engineering-dossier format.
SIMULATED No robot is owned or operated by these projects. The simulators linked here are interactive spec visualizations — not telemetry, not live robots. The Go2 simulator is the artifact already built for the presentation deck (slides 39–42) and is hosted with it.
A non-violent, local-first personal safety escort
Spatial sensing, computer vision and local AI-assisted event interpretation behind a deterministic safety supervisor. The robot accompanies, warns, pauses, suggests a safe route and alerts a trusted human — it does not confront. SOURCED 19-slide pitch deck.
Product promise
“A second set of eyes that moves with you and helps you make a safer next decision.”
Initial deployment: supervised, controlled environments — not uncontrolled public streets.
Explicit limits
No striking, grabbing, chasing, restraining, weapon use or autonomous confrontation. AEGIS is not a replacement for trained security; the prototype is deliberately non-contact.
G1 EDU · 23-DOF
The retail (standard) configuration does not support secondary development — the wrong procurement target. The EDU configuration is the defensible starting platform; no dexterous hands are required for the escort MVP. VERIFY SKU Orin NX 16GB compute details confirmed with Unitree before procurement.
Sensing: start with the sensors already on the G1
RealSense D435i
RGB + stereo depth for visual semantics and camera geometry; intrinsics and extrinsics calibrated.
Livox MID-360
3D point cloud for range, surrounding geometry and mapping — measured geometry, not semantics.
IMU + joint state
Orientation, movement and internal state — is the robot itself stable and behaving as expected?
ZipDepth (optional)
6.1M-parameter monocular depth prior. Affine-invariant inverse depth — never the collision-distance authority.
The architecture the pitch defends
Computer vision
Separate jobs: a compact TensorRT person detector, ByteTrack for temporary track IDs (tracking is not identity), MediaPipe Pose for posture cues. No facial recognition, no “aggressive person” classification — observable events only.
Compute separation
The Orin NX runs perception; Unitree's internal motion controller keeps the robot balanced. Secondary development does not grant unrestricted access to the real-time controller.
Gemma event brain
A small local model (Gemma 4 E2B quantized to start) interprets selected multi-sensor events and returns schema-limited suggestions. It never sends joint commands; a deterministic supervisor validates or rejects every suggestion.
ROS 2 + SDK2 adapter
ROS 2 Humble as backbone, unitree_sdk2_python as the robot adapter, a custom G1 locomotion bridge. Nav2 is not plug-and-play for a humanoid — navigation is a tested integration, not a package.
How an escort mission works
Live simulation
The team simulator needs a wider screen for its console layout. Open it in a new tab.
Open the team simulator →Open the team simulator full-screen →
Console prototype SIMULATED
A supplementary console that visualizes the AEGIS mission loop itself: the eight mission
steps, the LocoClient verbs each step issues (verified against unitree_sdk2_python —
Lie2StandUp(), Move(…, continous_move=True), StopMove(),
Sit(), GetFsmId() readiness polling), the six observable events with their
Gemma→supervisor decision chain, and telemetry.
Decision logic — observable events, never inferred intent
| Event | Proportionate response |
|---|
No threat scoring based on identity, appearance, ethnicity, facial expression or presumed intent.
Safety engineering
Hard limits
Maximum speed and acceleration · minimum separation · geofence · allowed modes · no arm actions · timeout on stale perception.
Watchdogs
Heartbeat monitoring · sensor-health checks · command freshness · battery and thermal · communication-loss handling.
Human control
Independent operator stop · manual override · clear user consent · visible recording indicator · local-first data handling.
Fail-safe rule: when the robot cannot trust its position, sensors, controller
connection or user track, it stops or transfers control — it does not improvise.
Software StopMove() is not a hardware emergency stop; the purchased unit's real
e-stop behavior must be validated with Unitree.
Specification & verified SDK map
Verified SDK vocabulary SOURCED
Three corrections against common usage, verified against
unitree_sdk2_python: the Python SDK exposes Squat2StandUp()/Lie2StandUp()
(not StandUp() — that name exists only in the C++ header);
Move(vx, vy, vyaw) is one-shot unless continous_move=True; and readiness is
polled via GetFsmId() — public issue #175 documents Move() being ignored for
seconds after stand-up. WaveHand()/ShakeHand() exist in the SDK and are excluded
by the no-arm-action rule.
Evaluating quadrupedal robotics in university security systems
A hybrid patrol model: existing CCTV and human guards remain the backbone; a Go2 supplements them with mobile surveillance, scheduled inspections and data collection. A research dossier with a prototype, constraints and safety rules — not a deployment claim. FROM-DECK 44-slide deck.
The core tension: efficiency against limitations
What the Go2 introduces
Mobility, automation, real-time data collection and potential for intelligent monitoring — against fixed cameras limited to their installation points, and guards spending time on routine patrols.
Why conventional methods might be better
Advanced technology does not necessarily indicate improvement. Battery life (≈1–2 h standard, 2–4 h EDU long-endurance), human judgement, emergency response, weather and crowds, cost, privacy and technical dependency all remain limits.
Why it could be more effective (A–F)
A · Coverage
Moves between designated locations, inspects areas outside fixed-camera range, offers different viewing angles.
B · Automation
Follows patrol routes, runs scheduled inspections, collects visual data without a guard on every routine round.
C · Detection & reporting
Cameras and LiDAR provide environmental information; software can flag predefined events to a central team.
D · Consistency
Repeatable routes and schedules; patrol records show what was actually inspected.
E · Reduced exposure
Can inspect selected isolated or hazardous areas before personnel enter, with remote visual assessment.
F · Security intelligence
Visual and location records help identify coverage gaps and allocate resources.
The hybrid model — the strongest application
1 · Existing infrastructure
CCTV, access control and alarms provide established coverage.
2 · Robotic patrols
The Go2 supplements surveillance by inspecting designated locations.
3 · Central monitoring
Robotic and fixed feeds are reviewed together by security personnel.
4 · Human response
Trained staff verify incidents, make decisions and coordinate the response.
First prototype: capability map
Legs + SportClient
High-level locomotion commands — StandUp(), Move(vx, vy, vyaw), StopMove() — at controlled speed, stopping at checkpoints.
Motion sensors & telemetry
SportModeState and LowState subscriptions give estimated motion, orientation and battery state.
Front camera
Frames relayed to the campus computer for live viewing and analysis; frame rate and latency measured on the intended unit.
Local network interface
SDK2 DDS connection carries commands and telemetry; scheduling, video analysis and the guard dashboard run on the campus application.
What makes the patrol useful
Known viewing position
Each checkpoint has a marked inspection area and a reference image from a normal patrol.
Object detection
A detector looks for objects inside marked exit and walkway zones.
Visual comparison
Changes against the reference view — a gate left open, a new object — are flagged.
Evidence before alert
Evidence across several frames is required; repeat sightings of one issue group into a single case.
What security sees
Live feed
The dashboard shows the live front-camera feed and the last completed checkpoint.
Alert queue
Each alert carries the checkpoint, time, reason and a snapshot or short clip; staff confirm or dismiss.
Honest coverage
If the feed drops or a checkpoint cannot be verified, it is marked uninspected — never displayed as covered.
Control flow — one patrol loop
Constraints, ethics and safety research — eight areas, each a rule, a control and a verification
| Area | Rule | Control that enforces it | How it is verified |
|---|---|---|---|
| 1 · Physical safety | No contact with any person or animal; walking pace only (≈1.0–1.2 m/s); stop on perception or link loss; never leaves the geofence. | LiDAR + depth slow at 2 m, full stop at 1.5 m; the robot yields, never pushes through. Mass ≈15 kg — leg guards mandatory. Physical e-stop plus watchdog. | Every stop, bump and near-miss logged with the causing frame and reviewed weekly. A near-miss counts as a defect. |
| 2 · Privacy | Footage only for obstruction and change detection at checkpoints. Smallest field of view; faces and windows blurred at the edge. No face, gait or plate recognition, no audio. | Raw clips deleted after 30 days unless attached to a confirmed case; deletion is automated, not goodwill. Signposted checkpoints; named-staff access with logged views and second approval for exports. | Data-protection impact assessment signed before the first patrol; access and export logs audited. |
| 3 · AI reliability | An alert is a claim the system must defend: high confidence threshold, evidence across consecutive frames, one case per repeated issue. Three states, not two: clear / obstruction / inconclusive. | Inconclusive goes to a human and is never silently treated as clear. Reference images re-approved on a schedule; a persistent mismatch is a maintenance signal. | Per-checkpoint labelled test sets (day and night); recall, false-positive rate and latency published before deployment. A failing checkpoint is not deployed. |
| 4 · Human oversight | Every alert is confirmed or dismissed by a security officer. No alert alone triggers a sanction, a police call or a student file entry. | Named security lead, technical owner and data-protection contact — no anonymous operation. Dismissals recorded with reasons. | A monthly sample of dismissed alerts is re-reviewed — the human layer is audited, not assumed. |
| 5 · Cybersecurity | A hijacked robot is a 15 kg camera inside a campus — treated as a likely event. No default credentials, no internet-exposed port, no mandatory vendor cloud. | TLS for video and command streams; mutual authentication; signed firmware; distinct credential per robot; dedicated VLAN with no route to student or HR systems. Limits enforced on the robot, not the laptop. | Heartbeat and full command log; automatic safe stop on an unrecognised controller; compromised-robot playbook with campus IT; firmware changes detected at next boot. |
| 6 · Operations | Return to dock at 20% state of charge; missions planned on the shortest endurance configuration. Link loss, low battery, blocked path or stuck sensor all lead to stop → dock → uninspected. | Rain, wind, stairs, lifts, crowds, reflective floors, low light and GPS denial are explicitly out of scope. Failure log, maintenance calendar, spare parts budget, named reviewer. | The robot is never the only sensor on a route; CCTV and human patrol remain the fallback. A mid-route death is a coverage failure, not a detail. |
| 7 · Accessibility & acceptance | Must not obstruct a wheelchair, a pram, a guide dog or a person who is blind. Yields, stops at distance, quiet mode near residences. Predictable route and pace. | Consistent walking-pace behaviour with a visible marker; no sudden appearances or route changes. A feedback channel that answers. | An anonymous survey before and after the pilot measures whether people avoid a space because the robot patrols it. A negative result is a reason to stop. |
| 8 · Legal compliance | Processing follows applicable data-protection law: lawful basis, purpose limitation, minimisation, storage limitation, integrity, confidentiality. Surveillance of public space and biometric identification remain out of scope. | DPIA written before the first patrol — if it cannot be completed, the pilot does not start. Student and staff representatives consulted before, not after. Vendor contract states liability, data ownership and remote access. | Safety committee, IT security and the data-protection officer sign off. The pilot has a defined end date, a published result and a documented stop / continue / expand decision. Continuing by default is not allowed. |
Research questions a pilot should answer
- Can quadrupedal robots improve campus surveillance coverage compared with stationary CCTV?
- Can robotic patrols reduce the time security personnel spend on routine inspections?
- Does integrating mobile robotics improve incident reporting and response times?
- Is the long-term cost of robotic patrols justified by their operational benefits?
- How can universities introduce robotic surveillance without compromising student privacy?
Deployment gate & residual risk
The pilot starts only when every line is true
- Route, geofence and stop zones mapped and measured.
- Each checkpoint has a labelled test set and published recall / false-positive rates.
- DPIA and the student and staff consultation are signed.
- Cybersecurity and vendor data-flow reviews complete.
- Emergency stop, link-loss stop and return-to-dock tested and logged.
- Security lead, technical owner and data-protection contact named.
- Retention, deletion and access control enforced by the system, not only by policy.
- Existing CCTV and human patrol remain the fallback on every route.
What the pilot still does not remove
Even with all of the above, the robot can miss an obstruction, be fooled by a change in lighting and make a person feel watched. It lowers the cost of a patrol and the delay in reporting. It does not remove the risk, and it does not replace a human being in the response.
Opens in a new tab — the artifact's own security policy prevents embedding on other origins. Simulator values follow deck slide 39: patrol interval 2–15 min, endurance standard 1.5 h / EDU long 3 h.
A serious review tool for astronomers — not a planet gallery
ORBITAL is a desktop workbench (Rust core + Tauri 2 + React) for the unglamorous middle of exoplanet science: import a light curve, inspect it, and review candidate signals with evidence states instead of verdicts. SOURCED Product requirements document.
Review discipline — the design constraint that shapes everything
What the tool never does
No “Confirm planet” button. No planet probability, no habitability, mass or composition claims, no discovery assertions. The model never decides that a signal is a planet — it presents the evidence and its status.
What it does instead
Vocabulary is “signal candidate” and “needs review”. Every candidate carries an evidence checklist with explicit states — Evidence available / Needs review / Failed / Not available — and a provenance panel: source mission, dataset ID, method and version, configuration, run timestamp.
Candidate review — the screen the whole product exists for
| Evidence item | State | Basis |
|---|---|---|
| Period, epoch, transit depth | EVIDENCE AVAILABLE | Measured from the periodogram and phase-folded curve |
| Transit duration | NEEDS REVIEW | Duration measurement overlaps a data gap |
| Centroid shift check | FAILED | Target sits near a saturated neighbor; centroid test inconclusive |
| Follow-up imaging | NOT AVAILABLE | No follow-up observation scheduled for this target |
SAMPLE-DATA Screen content above is illustrative UI structure with invented values — it is not a real candidate. The PRD's own rule: a static mock must say “Demo data” and must not simulate a scientifically completed search.
Why there is no live demo on this page
Protect panels. Balance crop light. Optimize solar power.
One coordinated system for solar farms that combine crops and panels: SealSense estimates moisture risk and evaluates protective responses; AgroTrack sets tracker angles from crop-stage light needs, weather, solar output and farm electricity demand. SOURCED Conrad Challenge lean canvas.
Integrated system architecture — two modules, one decision engine
Lean canvas — the concept in competition limits
| Question | Answer (from the team's lean canvas, word limits kept) |
|---|---|
| Problem | Agrivoltaic farms must balance crop sunlight, electricity production and module durability; conventional tracking rarely combines crop-stage light targets, farm demand and moisture-risk monitoring in one controller. [33/40 words] |
| Solution | Moisture-risk sensing and prediction, a candidate protective response, crop-stage light targets, weather forecasts, solar-output estimates and farm demand — one controller coordinating tracker angles and protection within safety and energy constraints. [35/40] |
| Unique value | One coordinated system considering panel durability, crop light, weather and farm demand together, tested against separate monitoring and tracking tools. [36/40] |
| Customer segments | Agrivoltaic developers, commercial farms, cooperatives and solar operators using irrigation or cold storage; initial focus on high-solar regions. [33/40] |
| Key metrics | Moisture-risk precision and false alarms, protective actions and their energy penalty, crop-light compliance, kWh generated and matched to farm demand, yield, maintenance cost, net value per hectare. [34/40] |
| Revenue streams | Monitoring and controller subscriptions, retrofit hardware, installation and commissioning, licensing to developers or tracker manufacturers — pricing depends on verified improvements. [36/40] |
Technical caution — stated by the team, not softened here
Crop-aware agrivoltaic tracking and solar-module moisture research already exist; the hypothesis is their coordinated control. An external cover cannot be assumed to stop moisture already inside a module and may trap humidity or reduce power. The prototype is simulation-first; simulated outputs are labelled separately from measured results, and real crop-yield, degradation or panel-life claims wait for field validation.
More builds from the same bench
Only entries with verified live URLs are linked; the rest are names and one line — no dead links by policy.