Bram van den Nieuwendijk 

This week I continued working on the assembly. I realized I needed to make some connection parts for the servo that rotates the top part because the adapter was missing. This meant I had to recut some new gearwheels, and the rotation of the top part is now working well. I also needed to change the wheels a bit to make them perfectly aligned with the encoders.  

To properly test the movement of the camera and the nozzle in the y-direction, I need the camera, which I couldn’t get my hands on this week, so this still needs to be tested. 

I also tried to make a watertight tank, which has been unsuccessful so far. This means I have to try some other methods, and I will be working on this next week. 

Sulaf Bozomqita: Week 13: Fail-Safe & Logging for Robustness

This week I focused on making the obstacle detection system more reliable and maintainable. After implementing predictive avoidance and adaptive speed control in Week 12, I realized the system needed two critical features: a recovery mechanism when the robot is stuck, and a way to analyze its behavior over time.

This week’s improvements:

One of the biggest improvements this week I made was a timeout fail-safe. This is added as a recovery mechanism if the avoidance segment takes too long, to prevent the robot from getting stuck in that state for too long. When this happens, the robot performs a recovery maneuver by backing up further before attempting to reroute. I made this to prevent deadlocks and to ensure that the robot can continue operating safely while resuming navigation.

In addition, I figured that making a logging system seemed like a natural progression this week. Every decision (stop, slow down, turn direction, PWM values) is now logged to a file for later analysis and tuning. This in my opinion makes things a lot more improvable and easier to adopt later. The logging systems logs everything to a file (robot_log.txt), and that includes:

• Any emergency stops
• Speed changes
• Turning directions
• PWM values

This makes it easier to analyze performance and fine-tune parameters later.

Code Updates & Testing:

Setting up the logging system, first and foremost:

Making the logging system for each of the maneuvers: so instead of printing it to the console, saving it into the file:

Logging for acceleration and deacceleration.

Logging for when detecting an obstacle and when needing to stop after detecting the obstacle, as well as when predicting the obstacle.

Logging for when deciding to turn, and for resuming after rerouting.

Setting up the failsafe system:

The timeout = time.time() + 5 sets a deadline of 5 seconds for the avoidance loop. The while … and time.time() < timeout is where the robot keeps backing up until the front sensor shows a safe distance, OR the timeout expires.

Then the if time.time() >= timeout is implemented for if the timeout expires before clearing the obstacle, then it logs a fail-safe message, and performs a recovery maneuver (backs up for 2 extra seconds).

These improvements make the system robust and transparent, by making a fail-safe, the system is almost ensured reliability even in unpredictable environments. As for the logging, it provides valuable data for debugging and optimization later on, which is essential for scaling and real-world deployment.

Output:

You might have noticed that the console output only shows the motions and nothing else, unlike before where I printed out everything to the console, like the action and warning messages. The reason for this is because the other messages (like obstacle detection, avoidance steps, warnings, and fail-safe triggers) are all logged to the file robot_log.txt using logging.info(), not printed, unlike the motion messages which are printed using printf, as shown in the console. So, the console only displays motor actions, while the detailed behavior (obstacle detection, avoidance decisions, fail-safe triggers) is stored in the log file.

Conclusion

This was hard but rewarding because I had to think about edge cases and long-term usability. Designing the fail-safe required careful timing logic, and setting up structured logging taught me how to make the system transparent for future improvements. Seeing the logs capture every decision felt like a big step toward professional-grade robotics. So even though this was slightly difficult with the failsafe especially, I do believe that this week pays off for future uses, especially with the logging for any analysis of the robot’s performance.

Rick Embregts 

Use logs to fine-tune acceleration and avoidance parameters.

Test fail-safe and logging on real hardware during extended runs.

This week the backup plan is mostly assembled, and components from the backup plan have been tested to see if they would work with the raspberry. However, we found out that our current raspberry is defective and can’t boot. Testing of the entire system is therefore postponed. The motors with encoders are still not available, and the battery carriage is not ordered. That is why we currently have motors installed without encoders. According to the teachers an other group has the motors, and they are trying to get the motors to us as fast as possible. 

Between all the subjects and trying to assemble the backup plan, the assembly of the main plan has also partly taken place. The SMD components have been soldered to the PCB. Next are the connectors and other components. However, the main focus shifted towards getting the backup plan operational. The foto’s below are from the assembly procces of the PCB.