RobotX 2026 - Testing
RobotX 2026 > Testing
Team Inspiration utilizes local lakes, parks, and pools to prepare for the RobotX Competition
Upcoming Tests:
Drone and Boat Mission 1 Test at Lake Miramar
CV Data collection for Task 2
Task 1 USV and UAV Coordination
Lake Miramar lake data collection
Testing Strategy
The team utilized the systems engineering process throughout our testing, deriving action items and test cases from complex mission requirements, guiding our testing strategy.
Component tests are conducted to ensure reliability and functionality of individual features before integration into the overall system. Components include mechanical, electrical, and modularized software functions like object detection and payload actuation.
System testing is performed to verify mission capabilities involving multiple components. Sub system testing includes testing isolated maneuvers of the overall approach such as UUV perception, localization and interaction with an LED box on the pipeline.
System testing includes all the capability for a platform to complete a task. Vehicles are evaluated on their completion of the tasks.
Systems Testing
We have accumulated more than twenty hours of water testing on the current systems and eight hours of flight time. Access to a local reservoir is sustained through community relationships. The system launches and operates with two people, which is what makes weekly testing possible.
Land and pool testing are used for smaller tests or when the reservoir is unavailable.
Component Testing
Component testing is conducted to ensure individual components behave as expected before being integrated into the system.
For example, after we flooded our UUV Græy, we cleaned each component with isopropyl alcohol and conducted component testing on them. Because we had a flood, the UUV enclosure was opened frequently due to unexpected electrical failures in the thrusters. We located the root cause of the failures: low soldering quality and a lack of strain relief on the cables. We quickly applied changes based on the component testing results, and our system has remained reliable ever since.
Simulation Testing
We have been testing the UAV navigation in simulation before we take it out on the water. The setup is ArduPilot SITL in Gazebo Harmonic, with the VRX ocean, on the same MAVLink and ROS 2 stack as the Pixhawk. Three courses based on the RobotX 2026 tasks have been generated: a Safe Passage channel, an open-water survey, and a dogleg with a 90 degree turn.
Gazebo's sensors come out with no noise, so they are not a good test of the filter. We added the noise in MATLAB/Simulink. The GPS model uses Navigation Toolbox gpsSensor and switches between RTK-fixed, RTK-float, DGPS, and standard GPS. We built the same kind of model for the rangefinder and optical flow. Those readings go back into ArduPilot as GPS_INPUT, DISTANCE_SENSOR, and OPTICAL_FLOW, and the EKF fuses them.
FIND OUR TESTS BELOW
Crusader (USV), Ekko (UAV), and Graey (UUV) Lake Test - 10/25/26
Objective:
We tested all our vehicles at the lake. The main goal was Task 1 Advanced: the drone maps the buoy field and sends it to the boat, then the boat drives through without hitting buoys. We also tested Task 2, Task 3, and the sub’s GPS navigation.
Timeline:
14:25 – Boat battery check (15.5 V)
Task 3 – Water shooter too weak. Heading reset bug fixed on the spot.
15:27 – Swapped boat battery
15:38 – Task 1 Advanced success (6 min). Switched to faster settings.
16:06 – Boat hit shore and broke its thruster guard
16:10 – Tested drone auto search
What Went Well:
Drone and boat talked to each other well.
Boat followed its path on lake settings.
Buoys worked and none sank.
Handled strong wind.
What Could Be Better:
Use the checklist (forgot paddles and life vests).
Charge all batteries and track which are charged.
Bring spare parts and the drone launch platform.
Share the boat transmitter for emergencies.
Next Steps:
Set up drone-to-sub communication.
Print spare parts.
Graey (UUV) Lake Test - 10/24/26
Objective:
We tested the sub in a setting more like Singapore. We placed the pipeline in about 5 to 7 m of water. The goal was to test GPS navigation, sonar detection, and following the pipeline. The sub should stop at the red light, press the magnet onto the box, record the flashing sequence, then surface and flash it back. We also wanted to collect sonar and camera data and test the radio and controller.
Timeline:
11:00 – Setup
11:30 – GPS testing
1:00 – Test mission
4:00 – End of test
What Went Well:
We tested for a long time.
An experienced person handled the kayak.
The LED pipeline lights were easy to see.
We explained to a new ranger that we are a student group, which let us keep testing.
What Could Be Better:
The pipeline ended up too deep, and the sub could not find it.
Sonar did not work as well as planned.
People arrived at different times.
The sub was not ready when we arrived.
We spread out too much on the boat ramp.
No one took notes.
Practice changing code without AI help.
Next Steps:
Use the depth map. We need to paddle out about 40 m to reach the right depth.
Check the sub’s GPS heading near the shore and the slope.
Build a safety system that works every time.
Crusader (USV), Ekko (UAV), and Graey (UUV) Lake Test - 10/18/26
Objective
The goal of this test was to see if Crusader, our autonomous boat, could complete Task 1 (disruptive) and work together with our drone, Ekko. To do this, Crusader needed to run its mission using a behavior tree, talk to the drone, and avoid obstacles. We also wanted to collect camera data of the pipeline to help train our computer vision system to detect it.
Setup
Our team set up a field of buoys and a test pipeline near the Miramar Reservoir boat launch. Team members were assigned roles such as boat launcher, ground control, data collector, tether handler, kayaker, and safety checker.
Outcomes
Buoy setup was faster than our last lake test.
We recorded camera data for future testing and training.
The drone successfully sent the buoy location file (JSON) to the boat.
Systems that worked in our last test still worked this time.
The radio link between the boat and drone did not work as planned.
Our phone hotspot was not reliable. When it dropped, our RTK GPS accuracy fell from 2 cm to about 1 meter.
What We Learned
For our next test, we will prepare and rehearse the day before, bring more weights, rope, and walkie-talkies, and give radios to the people who need them most. We will focus on placing buoys precisely instead of quickly, keep task assignments the same on test day, and hang the pipeline in deeper water, away from the surface and the lake floor. We also plan to fix the boat-to-drone radio link and find a stronger internet connection so our GPS stays accurate.
Crusader (USV) Lake Test - 10/4/26
Objective:
Test Crusader’s navigation accuracy under lake environment (at a bigger venue similar to competition setting compare to a pool)
Test “NAV2” based obstacle navigation capability
Test Task 1 advanced with injected drone message
Outcomes:
Accomplish task 1 in ~3 min without hitting any buoys.
NAV2 replan the boat’s trajectory too often, parameters need retuned to increase Crusader’s speed when orbiting around the ENTRY and EXIT buoy.
Crusader (USV) backyard CV data collection - 9/21/26
Goal: Collect CV Data for the bouys
DON (UAV) Crash - 8/23/26
Goal: Pre-Qualify Don (and gain flight time for pilots)
What we Learned:
Need to elevate telemetry radio off the floor (Recommended tables and chairs due to damp grass and to support elevation of antennas)
Checklist to torque down fasteners (Heard propellor rattling during first flight of the day, ensure)
Have visible waypoint targets (Canopy stakes nearly invisible need cones to mark waypoints)
CRUSADER (USV) Object Tracker Test - 8/16/26
Goal: Testing object tracking capability on land
DON (UAV) Pre-Qual Crash - 8/12/26
Goal: Get Pre-qual #3 done for the drone
Team member’s personal reflection:
“Usually when we fly and test the different flight modes, we only fly around 5–20 m under the power line. I also had the GeoFence set to 30 m so it could prevent the drone from flying too far or toward the power line. Since Prequal 1 and Prequal 2 worked perfectly, I decided to get Prequal 3 done, which required the drone to fly around 35 m above the ground. On the first test, the GeoFence prevented the drone from completing the mission because it reached the 30 m limit and stopped in the middle of the air, which is what I had set the GeoFence to do. I decided to test it again by changing the GeoFence from 35 m to 50 m. What I didn’t realize at that time was that changing the GeoFence to 50 m did not only increase the altitude limit on the Z-axis, but also increased the horizontal GeoFence on the X and Y axes. Because of that, the drone was now able to fly much closer to the power line than before. The biggest mistake I made was that someone needed to manually arm the drone from the laptop, so I asked Chris to handle the laptop while I recorded the flight. I also decided to turn off the QGroundControl voice notifications for that flight, which was another mistake. During the mission, I was recording and zooming in on the drone because the Prequal 3 mission required us to show the drone spinning in mid-air. Because I was focused on recording, I didn’t notice that the drone had started flying off and going in the opposite direction from what I had set up. By the time Chris notified me, the drone was already getting close to the power line. I immediately put my phone down and tried to take control of the drone. Since it was already far away and it was dark outside, we couldn’t clearly tell whether the drone was moving upward or what direction it was actually going. I also didn’t realize that the controller was already in Loiter mode, so when I tried to control it, the drone was trying to hold its current position. At that point, I was switching between different flight modes and trying to figure out how to regain control. During that process, I believe I accidentally clicked the disarm button instead of landing button. The drone disarmed while it was still in the air, causing it to fall and crash.”
CRUSADER (USV) Pre-qual - 7/19/26
Goal: Pre-Qualify Crusader for the RobotX Competition
Crusader Proof of Readiness Submission
GRAEY Waypoint Testing - 6/26/26
Goal: Establish Jetson to VectorNAV connection
Goal: Graey will remain stationary while waiting for a modem message. Onyx will send a "YAW" command through the modem. Graey will only begin its yaw sequence if it receives the "YAW" message on the modem received topic. If no message is received before the timeout, Graey will not move