Progress Review 10

Team B - BASTI

Broad Area Support for Triage and Identification

​

Presented by: Lance (Yufan) Liu

Progress Hardware

Hardware

Hardware

Hardware

Hardware

Hardware: Sourced and set up DJI Air 3

Progress

Software

Software Swarm Simulation

• Simulation in Unity developed for the purpose of visualizing and running games to converge onto optimal play strategy.
• Provides independent strategies that can exploit the agent’s speed and information gathering. To simplify the computation, we’ve reduced it to slow, high score, fast, low score.

Software Swarm Algorithm Refinement

We’ve worked to discuss and refine the specific algorithm to explore for the purposes of the DTC challenge.

• ESCHER nd Sandholm is best suited for our purp[ICLR-23], by McAleer, Farina, Lanctot, aoses.
• Significantly reduces the computation time and complexity of the algorithm, giving us viability by date of FVD in terms of convergence.

LiDAR SLAM and Navigation

• Mid 360 Integration
• Driver setup on Ubuntu PC & Drone
• Mounted device printed, DC-DC buck converter and 1-to-3 splitter ready
• FastLIO
• Unit-test on Ubuntu PC & Jetson Orin
• Further Algorithm Optimization for SLAM Frequency (Up to 100Hz)
• EgoPlanner
• Unit-test on Ubuntu PC
• Integration
• Built simulation environments in both Gazebo and Pegasus Isaac Sim for pre-flight test

​

SLAM Simulation – Gazebo

Mid 360 Mesh Mounted

GPU_LiDAR Plug-in

SLAM Simulation – Gazebo

SLAM Simulation – Pegasus Isaac Sim

Rotary v.s. Solid LiDAR modeling

Issues & Risks

Risk Matrix

Consequence

Likelihood

R1: Time Management and task priority. FVD needs to be built coherently on top of the existing SVD framework.

Mitigation: establish a clear and structured timeline for hardware assembly, software integration, and test flights.

Future Work

Future Work

• Priority: Manage the test flights to ensure that features displayed in the SVD and Georgia will be included in the FVD.
• Bonus objectives: Integrate Swarm and Obstacle Avoidance on to the robots.

Issue Logs

Issue Log: Cracked Propeller

Issue Log: RFD Connection Instability

Issue

• RFD900x connection was unstable after hardware replacement.

Root Cause

• The newly installed radio module was not fitted with a metal shield, leading to electromagnetic interference.

Resolution

• Added the metal shielding to the radio module.

Risks

Risk Matrix

Consequence

Likelihood

R1: Drone hardware damage during test flights before competition

Medium Impact: Not likely to happen because we have skilled flyers and technicians, but if it happens it affect the competition

Mitigation:

​

Bring spare parts (motors, ESCs, radios, props, cables).

Do pre-flight inspection and maintenance.

Prepare repair tools on site.

Spring UAV

Flight time: 14min

Technical: Subsystem Status

NEW CUSTOMIZED DRONE PLATFORM

1

2

3

4

Issue 1: Broken Cables

BROKEN COIL & MOTOR CABLES

Issue 1: Broken Cables

​

THIN CABLES’ WORN OUT & DAMAGE

Risk Matrix

Consequence

Likelihood

R1: broken cables

High Impact: Cause critical system failures & Integration Delays

Mitigation:

​

Remake all broken cables

�Organize cables with zip tie, heatshrink, and cable sleeves

​

Keep spare thin cables, especially data cables

Issue 2: Gimbal Anti-Vibration Damper Leak

Damper Oil Leakage!

Risk Matrix

Consequence

Likelihood

R2: Gimbal Anti-Vibration Damper Oil Leakage

Medium Impact: Low-quality data collection & Algorithm Validation Failure

Mitigation:

​

Source from manufacturer & Amazon

�Do not squeeze dampers

Issue 3: Jetson Orin Cooling Fan Not Working

Orin Cooling Fan Off

Risk Matrix

Consequence

Likelihood

R3: Orin Cooling Fan Off

Medium Impact: Delayed Autonomy Test

Mitigation:

​

Source from manufacturer & Amazon

​

Use Cable sleeve to protect orin cables

​

Switch Orin position below the top plate to cover its cables

Issue 3: Jetson Orin Cooling Fan Not Working

Issue 4: Inconvenience of Reaching Components

Difficult to Reach Components

Risk Matrix

Consequence

Likelihood

R4: Difficult to Reach Components

Medium Impact: Delayed Staging Time on Demo and inconvenience when troubleshooting

Mitigation:

​

Payload Layout Organization

Drone Overview

Issue 5: Rajant Radio Damaged

Rajant Radio Damaged

Risk Matrix

Consequence

Likelihood

R5: Rajant Radio Damaged

High Impact: Delayed Autonomy Validation

Mitigation:

​

Switch to Domo Tactical Radio

​

Submit backup radio documents to Darpa Beforehand

Airstack

Flight mode needs to validated for the new waypoint clicky mode.

Flight algorithms on paths through the corridor for entry/exit

Burst mode trigger

​

The current GPS and gimbal location needs to be logged.

​

High quality image is taken, high quality video is taken for 10 seconds at 24fps

​

Data is stored LOCALLY to an mcap when completed

​

Geolocation estimation

​

​

​

Upon completion of the burst mode, all data is packaged and sent as a singular data point back to the UGV base station, through the Dell and through the one-way switch.

​

​

Operator

Connect the Dell laptop to the UGV base station

Make a quick waypoint clickable interface to move across the field

Yawman add button that connects to the burst system and geolocation system

Repair and validate Yawman controller can actually control the gimbal

Synchronize MCAP data format* with Lockheed

Validate Foxglove UI to active mission/pub/sub low frame low fidelity livestream for operator action

​

Subsystem B.2: Software Subsystem

Technical: Key Challenges & Associated Plans

Mechanical Overhaul & PID Tuning for Stable Flight Performance

Streaming: Protect Control/Telemetry from Video Bursts

• Shared link: video may starve commands

​

Plan

• Video off DDS; use SRT data plane
• ROS 2 only for control (SensorDataQoS)
• Mark DSCP: control high priority, video best-effort
• Apply fq_codel/cake queuing discipline

​

Technical: Key Challenges & Associated Plans

General Loss & Jitter on Radio Links

• UDP loss → stutter if unprotected
• TCP → head-of-line stalls
• ​

Plan

• Use SRT over UDP (jitter buffer)
• Persistent listener on GCS (no handshake delay)
• latency=around 100 ms for smooth recovery
• Log RTT/loss/throughput; drive bitrate from stats

Project Management: Overview

• Agile Scrum
• Flexible framework for changing requirements
• Allows for continuous testing and validation
• Benefits
• Enhanced Team Coordination internally and with Airlab.
• Regular testing reveals risks early.
• Weekly retros and sprint checks dealt with blockers as quickly as possible.
• Regular updates allow every team member to stay informed, and thus reduce communication costs.
• Challenges
• Documentation Debt
• Increased Planning and Coordination needs
• Tools:
• Communication–Messages, Discord, Slack
• Documentation–Google Doc, Github
• Scheduling–Google Calendar

Project Management: Meeting Types and Structure

• Meeting Questions
• What is the progress on the current system?
• What are the major roadblocks?
• What are the next steps?
• Meeting Issues and Resolutions
• If team members fall behind schedule, redistribute the workload.
• Collaborate as a team to review available options for next steps and address them one by one.
• Identify alternative tasks to work on while the roadblock is being resolved.
• Bi-weekly sprint planning/retrospective meeting
• Duration: 1-2 hour
• Task Assignment for the following two weeks.
• Plan Work Schedule and Conduct a Retrospective
• Stand-up after MRSD and business
• Duration: 10-30 min
• Keep meetings brief and focused on progress updates and collaborative work.
• Streamline agendas to maintain productivity and avoid unnecessary prolongation.
• Meeting with Airlab and Lockheed Martin
• Duration: 1 hour
• Update team progress and requirements depending on changes in overall team strategy.

Project Management: Retrospective

• What went well:
• Team was actively involved in their individual aspect of the build cycle, and consistently updating to avoid blockers.
• In-person attendance was mixed, but participation toward the active goal was present.
• Participation was logged at in-person work hours at Airlab, or online through distributed code elements.
• Actionable items were logged and consistently updated on Discord for team clarity.
• Adaptive planning around the changing requirements for our team.
• Timely communication with Lockheed Martin and Airlab to stay aligned with the development progress.
• What needs improvement:
• Uneven work allocations.
• Scheduling conflicts with other work.
• Concentration of technical knowledge into few people - caused major blockers.
• Disorganized work documentation.
• Delayed communication.
• The team was often driven by extant problems or the requirements set, but often was driven by active subgoals that appeared in between larger milestones.
• Next Steps:
• Assess team members workload capacity.
• Delegate tasks based on workload.
• Re-organize google doc and create joint calendar for better work allocation.
• Promote collaborative tools.
• Reorganize code and documentation.
• Update Issue logs.

Schedule/Milestones 1: Georgia Phase

Focus on Overarching End Capability Sets, rather than Individual Features:

9/11: Progress Review 7

• Primary effort on the development and deployment of the new model of drone, which can triple our effective aerial time, which requires feature transfers from older model to newer model.

9/25: Progress Review 8

• Primary effort on advanced geolocation system, which uses intrinsics on a stable platform to give much more accurate ground GPS locations.
• Secondary effort on robustification for Georgia operations.

(Milestone) 9/27: Team Departs for Georgia

• All systems need to be packed and ready to use in Georgia in a live setting, followed by unpacking and rapid deployment.

Schedule/Milestones 2: Feature Development

10/09: Progress Review 9

• Development of the VIO/LIO initial odometric hardware and validation of functionality.
• Integration with the Spot and Lockheed team for mesh network capability.

(Milestone) 10/19: System Development Review

• Integration development of the VIO/LIO to support odometric/photogrammetric behavior on the Orin in a live setting.
• Collaborative teaming algorithm development on a simulated two-dimensional mission space.

10/30: Progress Review 10

• VIO/LIO integration and initial prototype GPS-denied functionality on the drone.
• Collaborative teaming algorithm deployment on the drone.

Schedule/Milestones 3: FVD Preparation

11/13: Progress Review 11

• Robustification of both the VIO/LIO system and the collaborative teaming algorithm via field testing and iteration.

(Milestone) 11/17: Fall Validation Demonstration

• Demonstration of upgraded GPS-denied drone, alongside drone collaboration and improved algorithmic behavior.

11/26: Fall Validation Demonstration Encore

• Iteration on previous demonstration.

Project Management: Risk Management

Risk Matrix

Consequence

Likelihood

R1: Missing Autonomy Stack Code Integration

High Impact: Cause critical system failures & Integration Delays

Mitigation:

​

Weekly 3-hour Cowork Time for Integration

​

Define Code-freeze & review Time

​

Upload Data on Drone to Team Shared Storage Right after Data Collection

Project Management: Risk Management

Risk Matrix

Consequence

Likelihood

R2: Instability of New Robot Platform

High Impact: damage of expensive components, and interruption of tests/demos

Mitigation:

​

Keep Spare Motors/Props/Battery/Escs/Orin�

Optimize Drone Design and 3D-printed Components��Perform Pre-flight Maintenance and Checklist before each Run

Project Management: Risk Management

Risk Matrix

Consequence

Likelihood

R3: Insufficient Budget

High Impact: Expensive Components Do Not Have Replacement.

Mitigation:

​

Seek Components Loans from Other Teams or Labs.

​

Prioritize Essential Purchases (props, motors)

Project Management: Risk Management

Risk Matrix

Consequence

Likelihood

R4: Team Member Schedule Conflicts

High Impact: Reduced Working Efficiency, Delayed Milestone, and Increased Safety Incidents

Mitigation:�

Ensure Team Cowork Time and Establish Clear Schedule Early��Encourage Subteam Work and Rotation Rest

Project Management: Risk Management

Risk Matrix

Consequence

Likelihood

R5: Testing Environment Availability

Medium Impact: Delayed Demo and Algorithm Validation

Mitigation:

​

Secure Weekly Full-team Test

​

​

Q&A

SVD Course Setup

In 25 min

​

3 dummy casualties

​

Detect all & survey 1

SVD Encore Course Setup

In 25 min

​

3 dummy casualties

​

Detect all & survey 1

Hawkins Site

Drone Components

SVD Encore Procedure

3 test dummies/actors scattered in Mill19 test field.

Launch all ground control systems, and commence autonomous takeoff of the drone.

Drone begins in mapping mode, surveying the entire area within the designated geofence.

​

01

​

02

​

03

04

Drone streams back approximate GPS locations of detected casualties to the ground operator.

SVD Encore Procedure

Drone returns for a battery swap.

​

Redeploy drone in waypoint mode. Go to the first patient, and localize them. Display published GPS coordinates.

​

Drone performs an orbital pass around the patient in step 6. Begin onboard algorithms, and camera locks on the patient.

​

​

05

​

06

​

07

08

Stream algorithm data back to the viewing gallery, including reID, pose estimation. Return when complete.

Updates in SVD Encore

Real-time Detection Visualization Demo

Casualties’ Ground Truth GPS Location Available

01

​

02

​

SVD Autonomy Objectives

• Drone flies safely and detects all 3 dummy casualties.�
• Surveys first detected patient from 6–10 meters standoff distance.�
• Estimates patient GPS position within 5 meters of ground truth.�
• Responds to 8 Foxglove commands (arm, disarm, takeoff, search, Estop, survey, autoland, geofence mapping) within 1.5 seconds.�
• Onboard EO and IR videos recorded at 30 FPS.�
• Maintains video transmission latency below 3000 ms.�
• Transmits bounding box data to Foxglove with packet loss below 1%.

SVD Safety Objectives

• Initiates hover within 0.5 seconds of E-stop.�
• Hovers upon communication loss.�
• Returns to home base when battery reaches 10%.