Cheese was not developed through successful tests alone. Crashes, unstable curves, incorrect sensor readings, structural problems, failed solutions and inconsistent obstacle behavior provided some of the most useful engineering evidence in the entire project.
✦ ─── ⋆⋅☆⋅⋆ ─── 💥🧀🤖 ─── ⋆⋅☆⋅⋆ ─── ✦
--- A failed test is useful when it helps explain **why the robot failed**. During Cheese development, the team learned not to treat every crash as simply a "code problem." A collision can be influenced by: - ultrasonic geometry, - PID correction, - steering response, - curve entry, - curve exit, - robot mass, - wheel grip, - sensor timing, - battery condition, - or several of these at the same time. For that reason, failures were analyzed using:Failure → Evidence → Cause → Risk → Change → Retest → Result
This section documents the failures that most strongly influenced Cheese v4. --- # ❀ 4.2.1 Failure Analysis Method ────୨ৎ────────୨ৎ──── When Cheese failed, the visible result was only the beginning of the analysis. For example:Robot Hits Wall ≠ Automatically a PID Problem
A wall collision could originate from several interacting systems.
Real Open Challenge failure during testing. Cheese reaches an unsafe trajectory and collides instead of maintaining sufficient wall clearance.
This type of failure cannot be understood only from the final collision. The important engineering question is:What caused Cheese to enter the collision trajectory?
Possible contributors include the previous steering command, wall distance, correction timing, curve geometry and available recovery space. ---
Real curve-related failure recorded during Open Challenge development. This evidence helped evaluate how corner behavior affects the trajectory that follows.
The second failure demonstrates an important systems relationship:Bad Curve → Bad Exit Heading → Strong Correction → Wall Risk
A collision occurring after a corner may therefore have begun **during the corner itself**. These GIFs are kept in the repository because successful runs show what Cheese can do, while failed runs explain **why the engineering changed**. --- # ❀ 4.2.3 Failure Overview ────୨ৎ────────୨ৎ──── The most important failures were not isolated. Many affected several subsystems simultaneously.The visible failure is not always the root cause.
--- # ❀ 4.2.4 Excess Weight and Structure Did Not Work ────୨ৎ────────୨ৎ──── Cheese v3 had a measured mass of **888.8 g**. Cheese v4 has a measured mass of **666 g**. The approximately **222.8 g reduction** did not happen because the team wanted the lightest robot possible. It happened because testing showed that some structures no longer justified their mass.
Remove Unnecessary Mass — Not Necessary Strength
This produced the current 666 g v4 architecture. --- # ❀ 4.2.5 The Large Camera Structure Did Not Work ────୨ৎ────────୨ৎ──── The HuskyLens itself was not the failure. The oversized structure surrounding the earlier camera configuration became unnecessary as the design evolved. The older architecture required: - more upper support, - more mounting pieces, - greater height, - and additional visibility hardware. ### Response Keep the camera function but simplify the structure around it.
Current v4 HuskyLens position after simplifying the previous camera structure.
The lesson was:Keep the Function → Remove the Unnecessary Structure
This reduced mechanical complexity without abandoning obstacle vision. --- # ❀ 4.2.6 The Previous Auxiliary Lighting System Was Removed ────୨ৎ────────୨ৎ──── Earlier Cheese versions used auxiliary lighting around the sensing system. As the camera position and overall structure changed, keeping the old lighting architecture became less useful.
A solution can stop being useful when the rest of the system changes.
--- # ❀ 4.2.7 Structural Stress Became a Real Failure ────୨ৎ────────୨ৎ──── Mechanical stress was not only theoretical. A Technic pin physically failed during earlier development.
Physical evidence of a small structural component becoming a real failure point.
A small mechanical failure can become a large navigation failure.
The lighter v4 structure reduces unnecessary structural load while retaining essential supports. --- # ❀ 4.2.8 Ultrasonic Placement Did Not Fully Work ────୨ৎ────────୨ৎ──── Wall-following software depends on the measurements it receives. If the physical ultrasonic geometry is poor, changing PID values alone may not solve the problem. ### Earlier issue The ultrasonic arrangement was not always positioned optimally relative to the field walls. ### System chainPoor Sensor Geometry → Poor Distance Data → Incorrect Error → Incorrect Steering
### Response The v4 sensors were repositioned lower and organized into a three-ultrasonic architecture.
Improve the Measurement Before Asking Software to Correct It.
--- # ❀ 4.2.9 Constant Correction Produced Unstable Movement ────୨ৎ────────୨ৎ──── One major Open Challenge problem was unnecessary steering correction. If Cheese tries to correct every small distance difference, it can begin oscillating.Small Error → Correction → Overshoot → Opposite Error → Correction → Zig-Zag
This is especially dangerous at speed. ### Response The Open controller evolved toward a **minimum-correction PID philosophy**.
Safe Position → Small or No Correction
This reduced the need for constant steering activity. --- # ❀ 4.2.10 Normal PID Alone Did Not Prevent Every Wall Collision ────୨ৎ────────୨ৎ──── The real collision GIFs demonstrate why normal PID correction could not be the only safety mechanism. As the robot approaches a wall, the consequence of waiting becomes progressively more serious. The response therefore evolved from one correction layer into several.Risk Increases → Protection Increases
This is more useful than waiting until Cheese is already at collision distance. --- # ❀ 4.2.11 Steering Alone Could Not Recover From Every Front-Wall Situation ────୨ৎ────────୨ৎ──── A particularly important failure happened when Cheese became too close to a wall. At that point, requesting a stronger steering angle did not necessarily solve the problem. Why? Because the robot physically lacked enough room to turn.No Space → Steering Cannot Create Space
### Response The Open software introduced front-wall reverse recovery.
Detect Danger → Confirm → Reverse → Create Space → Resume Navigation
This was an important change in thinking. Moving backward is not automatically a failure. Sometimes reversing is the action required to **recover from a failure state**. --- # ❀ 4.2.12 Corner Execution Could Create the Next Failure ────୨ৎ────────୨ৎ──── One of the most useful lessons from Open testing was that a corner does not end when the steering returns toward center. The robot still carries the heading and position created by that turn. The recorded collision evidence demonstrates why this matters.
Wide / Incorrect Turn → Poor Exit Heading → Wall Approaches → Late Correction → Collision
This means a crash on the straight after a curve can actually originate from **corner geometry**. ### Response Curve tuning focused on: - steering strength, - turn duration, - curve width, - exit heading, - wall clearance, - and the transition back to normal PID. ### LessonA Good Corner Must Prepare the Robot for What Comes Next.
--- # ❀ 4.2.13 The First Color-Sensor Light Shield Did Not Work ────୨ৎ────────୨ৎ──── Ambient light caused problems during early color-sensor testing. The first response was an improvised physical cover around the sensor. The idea was reasonable:Block External Light → Stabilize Floor Reading
But testing revealed a new problem. The cover was close enough to the floor that it could **drag against the mat**. So the solution to an optical problem created a mechanical problem. ### What happened
Fix A Problem → Discover New Problem → Reject Fix → Find Better Solution
--- # ❀ 4.2.14 Raw Color Events Did Not Produce Reliable Curve Counts ────୨ৎ────────୨ৎ──── Detecting a color once was not enough to prove that Cheese completed a physical curve. A false or duplicate event could change the entire run. ### Duplicate count1 Physical Curve → 2 Counts → 12 Reached Early → Parking Early
### Missed countCurve Missed → Count Below 12 → Parking Late
### Response The curve counter evolved to validate: - opposite-color progression, - a color-change time window, - steering confirmation, - post-color steering, - and cooldown.
Detection ≠ Valid Event
A sensor reading becomes useful only after the software determines what that reading means physically. --- # ❀ 4.2.15 Parking Failed When Earlier Systems Failed ────୨ৎ────────୨ৎ──── Parking initially looked like a final independent action. Testing showed that it is actually dependent on the entire previous run. For Open:Correct Curves → Correct Count → Correct Finish Timing → Correct Parking Activation
If Cheese reaches 12 counts early, parking can begin early. If a curve is missed, parking can begin late. If the robot approaches the finish with a poor heading, it can stop at an angle. ### Current Open result Open parking is functional and normally reaches the correct region, although final alignment can still be slightly angled. ### Obstacle Challenge Obstacle parking remains a later development problem because obstacle avoidance changes the robot's trajectory before it reaches the final area. The lesson became:Parking Is Not Only the End of the Run — It Is the Result of the Run.
--- # ❀ 4.2.16 Obstacle Detection Alone Did Not Solve Obstacle Avoidance ────୨ৎ────────୨ৎ──── The HuskyLens can currently recognize both competition pillar colors.Correct Detection ≠ Successful Avoidance
A successful obstacle maneuver requires:Detect → React Early → Steer → Clear Pillar → Recover → Continue
Current failures can occur when: - detection happens too late, - the pillar enters the field of view at an unfavorable angle, - avoidance steering is too weak, - Cheese contacts or carries the pillar, - or recovery leaves the robot in a bad position for the next obstacle. This is why the current obstacle work focuses on **physical maneuver reliability**, not only recognition accuracy. --- # ❀ 4.2.17 Post-Obstacle Recovery Did Not Work Reliably Enough ────୨ৎ────────୨ৎ──── Passing one pillar is not sufficient. Cheese must also be ready for the next pillar. A successful first avoidance can still lead to a later failure if the robot exits at the wrong heading.Avoid Pillar → Bad Exit → Next Pillar Appears Late → Late Reaction → Failure
This has made post-obstacle recovery one of the most important remaining tuning problems. The desired behavior is:Avoid → Clear → Recover → Stabilize → Detect Next Pillar
This demonstrates why Obstacle Challenge development cannot be divided into isolated pillar maneuvers. Each maneuver creates the starting condition for the next one. --- # ❀ 4.2.18 Battery Condition Made Some Tests Misleading ────୨ৎ────────୨ৎ──── One frustrating testing problem was that the same software did not always produce exactly the same physical response. Battery condition can influence: - propulsion strength, - steering response, - acceleration, - reverse recovery, - and timing. This can create:Same Code + Different Battery State → Different Physical Behavior
Without considering battery condition, the team could incorrectly change a software constant to compensate for a temporary power-related behavior. ### Response Battery condition became another variable considered before changing software. ### LessonNot Every Different Result Means the Code Changed.
--- # ❀ 4.2.19 Newer Code Was Not Always Better ────୨ৎ────────୨ৎ──── Testing before competition also produced an important software-engineering lesson. A newer version of the code could contain more features while being **less trustworthy** than an older tested version. During development pressure, some newer iterations did not perform reliably enough. This meant an older version sometimes became the safer option.Newest Version ≠ Best Competition Version
The best version is the one that has been sufficiently tested and understood. --- # ❀ 4.2.20 Failure → Cause → Change → Result ────୨ৎ────────୨ৎ──── The main development failures can be summarized as:Every Important Failure Should Teach Us What to Test Next.
--- # ❀ 4.2.21 How Failure Shaped Cheese v4 ────୨ৎ────────୨ৎ──── Cheese v4 was not designed from a blank page. Its architecture is a physical record of previous problems.Add More Until It Works
to:Understand the Failure → Change the Correct System → Test Again
--- # ❀ 4.2.22 Why We Keep Failure Evidence ────୨ৎ────────୨ৎ──── Successful testing footage proves capability. Failure footage proves engineering development. The two collision GIFs are therefore intentionally kept in the documentation.Success + Failure + Redesign = Engineering Evidence
A repository containing only successful tests would hide an important part of how Cheese was actually developed. --- # ❀ 4.2.23 Current Problems We Are Not Hiding ────୨ৎ────────୨ৎ──── Not every problem documented in this section belongs only to the past. Some remain active tuning areas.An Engineering Log Should Show the Real State of the Robot.
--- # ✦ Engineering Lessons from Failure ─── ⋆⋅☆⋅⋆ ─── ### 1. A crash is the result, not necessarily the cause The event that created the collision may have happened several moments earlier. --- ### 2. Software cannot completely compensate for poor physical data Sensor geometry must be improved before increasingly aggressive corrections are added. --- ### 3. A solution can create a new failure The color-sensor cover reduced external light but introduced floor contact. That made removing the solution the correct next decision. --- ### 4. Successful detection is not successful navigation The HuskyLens can correctly identify a pillar while the physical maneuver still fails. --- ### 5. Recovery is part of the maneuver Avoiding a wall or pillar is incomplete if Cheese cannot return to a useful trajectory afterward. --- ### 6. More complexity is not automatically more capability Some of the strongest v4 improvements came from removing components. --- ### 7. The newest code is not automatically the best code A simpler tested version can be more valuable than an advanced unreliable one. --- ### 8. Failure evidence belongs in engineering documentation The unsuccessful tests explain why the successful version exists. --- # ✦ 4.2 What Did Not Work — Final Reflection ─── ⋆⋅☆⋅⋆ ─── The most important thing that failed during Cheese development was not one sensor, one piece of code or one mechanical component. It was the assumption that every problem should be solved by **adding more**. Testing showed that: - more structure did not automatically create more stability, - more steering did not automatically improve navigation, - a larger camera mount did not automatically improve vision, - one correct sensor reading did not automatically represent a valid event, - correct obstacle recognition did not automatically produce correct avoidance, - and a successful avoidance did not automatically create a successful recovery. Cheese v4 became stronger because failures were treated as information. The robot became: - lighter, - lower, - cleaner, - easier to inspect, - easier to calibrate, - and more intentional. The two real collision GIFs are an important part of this story because they show exactly why continued testing was necessary.Failure → Evidence → Understanding → Change → Better Robot
What did not work became the evidence that shaped what finally improved.
✦ ─── ⋆⋅☆⋅⋆ ─── 💥 → 🔧 → 🧀🤖 ─── ⋆⋅☆⋅⋆ ─── ✦
