Progress Review 9

Team B - BASTI

Broad Area Support for Triage and Identification

​

Presented by: Joshua Pen

Georgia Contributions

Regression Tests in

Georgia

Hardware

• Risk 1: Hard landings during testing in georgia
• Regression testing: Replaced Landing Gear
• PID tuning: Replaced Landing gear and Wooden Leg
• Risk 2: Unstable Flight High Winds
• Require re-tuning due to replacing motors and ESCs
• PID tuning for attitude to help stability when descending
• Risk 3: Missing BlueCube
• Our cube went missing in airlab
• Find an emergency replacement and re-upload configurations

Risk Matrix

Consequence

Likelihood

Software Integration with Lockheed Martin and Base Station

• In order to contribute as part of the team, we needed to horizontally integrate with the Lockheed Martin drones to provide near-identical communication functionality.
• We synced our DTC radios with Lockheed, alongside syncing our ROS2 message format and image stream to pass through the Lockheed UAV station, which then passes through to the UGV station.
• Finally, we translated our geolocation system to be captured by Lockheed’s ROS2 publisher as well, which would allow direct submission of UAV scorecard if requested on our end.

TAK Integration and Flight

• For the medic demo, and for communication to tag our current drone’s position, our drone published its own aerial GPS while in flight, which was then downlinked to the TAK server.
• During the medic demo, our team members assisted in aerial tagging of ground casualties, which appeared on the TAK display. We also assisted in coordinating medics to localize casualties via the TAK interface, creating a common picture that aided in rapid identification.
• We aim to expand the use of TAK for our FVD, as we believe that it provides a better picture of our action/decision framework.

VLM Geolocation

—— Designed and Implemented For Live Medic Support

• Real-time Video Processing: handles encrypted, high-definition video streams from the drone, providing ground teams with an immediate "eye in the sky"

​

• Vision Language Model Detection: vision model to automatically detect targets with 90+% detection accuracy —including casualties and personnel (validated with DARPA staff)

​

• High-Precision GPS Estimation: automatically calculates the target's exact geographic coordinates with the drone's own sensor information

​

• TAK Integration for Immediate Situational Awareness:
• Detected casualties appear instantly on:
• Ground tactical stations
• Medic ATAK phones/tablets

Georgia Performance

• In Georgia, four of our team members went to provide assistance and deploy our drone as part of the DARPA Triage Challenge. We successfully were able to qualify the drone past all the safety screenings, and performed as follows:
• In the night run, after a bit of a delayed start, we were able to climb to our standard altitude and perform spotting for the Spots on the ground, guiding them be able to find nearly all the casualties on the field via aerial tagging.
• In the day run, due to heavy occlusion in the environment, we were able to tag most of the casualties, but due to inaccuracy in the Spot’s GPS, the Spots’s final reports ended up mistagging a few location-wise. However, the drone was able to remain in the air the entire time.
• Our performance in the previous runs qualified us for the medic run, where we saw a marked improvement in medical performance, more specifically in reducing search time more than anything else, with all drones flying low to assist in spotting and tagging.

Post/Non-Georgia

Mid-360 Setup - Software

Livox-SDK2

https://github.com/Livox-SDK/Livox-SDK2

livox_ros_driver2

https://github.com/Livox-SDK/livox_ros_driver2

Fast-LIO2 (To be adapted)

https://github.com/hku-mars/FAST_LIO

Mid-360 Setup - Hardware

Future Work

Post-Georgia New Features

• Swarm Algorithm Proposition
• PR10:
• Swarm Node Deployed on Base Station.
• Acquire and set up second drone for manual remote control.
• PR11:
• Test Swarm Algorithm on Drones
• LiDAR SLAM
• PR10:
• Install LiDAR and Integrate LiDAR
• SLAM running on MRSD Drone
• Test: Able to build a consistent LiDAR-based map in a small, controlled flight area
• PR11:
• Able to navigate around trees, poles based on the real-time SLAM map
• Live Video Feed to Ground station for hemorrage detection, optionally respiratory distress

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

Flight time: 40min

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%.