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
The team uses Software In The Loop (SITL) to learn vehicle behavior under different control modes and test high level mission behavior without physical dependency of a venue as big as a lake. We simulated vehicle behavior by executing the behavior tree mission logic in SITL. The team also utilized VRX with Gazebo and Simulink to aid our UAV testing.
FIND OUR TESTS BELOW
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