Tag: status report

This week, we finished a rough full system integration. We exposed some faults that needed addressing, such as gantry pitch decoupling and audio bugs. We explored adding two axes to the gantry, improved the robustness of wiring connections, and are working to tie up any other loose ends to create a robust system for public demos.

As for our unit tests, we conducted the following:

1. Bat Swing -> Servo Actuation. Actuated servo based on different measured swing speeds. Adjusted base level measured on on our own strengths, made room for it to be adjustable.

2. Bat Swing Strength. Measured the servo’s torque, the bat’s strength, and the swing power (ball distance traveled).

3. Scoring Detection. Measured detection (trigger/no trigger) for each pocket, revised pocket design. Measured correct base state changes for each scoring type with different runners on base. Created routing scheme for balls to route to bottom of board.

4. Pitch Coupling and Decoupling. Coupling was tested by dragging our magnets under our surface by hand, with the ball coupled on top, we can test how strong the connection is between the magnet and the ball. This was important as it informed how strong to size our magnet. If our magnet didn’t couple well enough, we wouldn’t be able to produce fast and variable pitch movements (like a start-stop pitch, which requires high acceleration). But we also needed the ball to be able to decouple relatively easily. We tested this with the flick of our fingers on the same setup. If we could flick the ball off the magnet coupling, we were sure that the real flipper could do the same easily. This informed an upper bound for our magnet strength, since if the magnet was too strong, we wouldn’t be able to decouple it or hit the ball cleanly.

5. Pitch Speed. This was tested by sweeping parameters of the gantry control software, FluidNC. It has a steps_per_mm and acceleration parameter, and we pushed it until we noticed motor whirring or extreme vibration. We were satisfied with the speed we were able to achieve. We were able to get up to ~250 mm/s for velocity. This was below our original target, but the eye test suggests that our original target was way higher than necessary, and that these speeds suffice.

 

To test the full system, we ran through full game cycles of pitch -> hit -> score (-> pitch). The full system testing revealed some flaws, such as the aforementioned gantry pitch decoupling and audio bugs, as well as issues such as the ball getting stuck on wires below the table. This informed us on what needed revision this week to make our game a complete, fun playing experience.

This week we made significant progress towards the final goal for the project. We had a productive meeting with the professor to brainstorm and finalize details for the final product, and met as a team throughout the week to integrate our subsystems and conduct verification. As of now, we are working on finishing the the wirings, gantry system, and scoreboard. We are also working together to finish the slides for the final presentation in this upcoming week.

This week, our team made progress on both implementation and overall system design. We got the paddle working for both demos. We also designed the scoreboard and game logic, and also refined the under-game system that will support score detection and ball handling underneath the board.  Instead of the current cups being attached to the board, we are printing out cup holders which attach to the breakbeam holders to make the system more stable. We also ordered additional breakbeam sensors and GPIO expanders so we can add the scoreboard communication along with audio.

The biggest risks right now are integration and user testing. Even if each subsystem works on its own, the project could still run into problems if the paddle, scoring sensors, and scoreboard do not work smoothly together. We are managing this by unit testing and integrating parts together one at a time. A contingency plan is to simplify parts of the scoring layout or under-board design if needed so that the core gameplay works reliably first. For the suer testing, we need the whole system to be integrated and conduct many run throughs to properly tune the game for a good playing experience. For example, if the bat is too sensitive, it can trigger unecessarily. Another example could be if it is too hard to score a point, making the game les fun to play.

As a team, we will verify that each part of the system is working the way we intended before focusing on full gameplay. This means checking that the paddle swings when triggered, the breakbeams correctly detect the ball in each scoring hole, the scoreboard displays the right score, and the under-game system reliably routes the ball for detection. We will do this through repeated testing and by comparing the measured results to what we expect from the design.

The main design changes this week were refinements to the scoreboard logic and under-game system. We already had general ideas, but we now have a solid plan for integration and the parts are ordered. Going forward, we plan to continue integration, refine the under-board system, and test complete gameplay more thoroughly.