Category: Team Status Reports

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.

This week, we worked to integrate our subsystems ahead of the interim demo presentation on Monday and Wednesday. Aiden finished up the physical build of the gameboard, including 3D-printed holders for break-beam sensors, which Vivian tested. Bing and Vivian successfully managed to control the servo by sending data wirelessly from the bat. As we transitioning to the integration phase of our project, we have also started collaborating on our team GitHub repository.

We are meeting up this weekend in preparation for the upcoming demo, in which we will demonstrate the gameboard and hitting subsystems, talk about our experiences with the development process so far, and lay out our plans for the upcoming month.

This week, we made significant strides in the physical fabrication and flipper-gameboard integration. Aiden revised the CAD models of the game board surface and frame, and consulted TechSpark’s woodshop lead for advice. Vivian tested the new servo and IR break beam sensors and successfully implemented a prototype game state machine with these two components. Bing continued development on the bat swing detection system.

We ran multiple hands-on tests this week that helped shape upcoming design decisions. We tested flipper-ball (hits), ball-magnet, and ball-surface (friction) interactions, and developed a full-scale surface prototype to evaluate the dimensioning of the board and pockets. We confirmed that the flipper was strong enough to hit the ball, but the ball doesn’t travel as far as we wish. We are going to try with a spherical game ball instead of the current design, which is a puck. We also concluded that the magnet was strong enough.

Looking ahead, we are focusing on pulling together a cohesive interim demo for next week, and we will likely focus on physical fabrication and integration of at least a prototype of all subsystems minus the pitch (gantry).

This week, we met as a team to work towards finishing the prototype for our project. Aiden and Vivian spent time in TechSpark to attach the 3D-printed flipper to the newly-arrived servo which should soon be ready for a demo, while Bing worked towards developing a prototype for the bat swing detection. We also made some design changes regarding the surface of the game board, opting for hardboard rather than acrylic due to cheaper costs and ease of fabrication. Additionally, we also discussed our ethics assignment in preparation for the upcoming ethics activity on Wednesday.

Unfortunately, we have also encountered road blocks in the past week in the form of exams and component issues, which slowed down our development process. Although we are currently behind in terms of progress, we are working hard to complete a working demo out as soon as possible. We will keep updating our Gantt chart as frequently as we can to reflect the state of our project and adapt accordingly.

This week, we formalized and integrated our subsystem designs to make a planned final vision, which was captured in our Design Report. Until now, a lot of our ideas had been hypothetical. This report forced us to rigorously analyze tradeoffs and defend our design with a mathematical basis. In addition, we updated our Gantt chart to adapt to logistical challenges and developed some prototypes for the flapper subsystem.

 

The following paragraphs discuss  how we are considering factors of public health, safety, and welfare, social, and economic. Part A was written by Aiden, Part B was written by Vivian, and Part C was written by Bing.

 

A. Globally, there has been a shift towards screen-based, single-player entertainment. Our solution addresses the downsides of this shift directly by making our playing experience physical and social.

Our game is intuitive and accessible. Our desire for simplicity enables an experience that anyone can quickly pick up and enjoy,  with intuitive inputs such as button presses and a bat swing. The components we use are easily accessible and affordable, and there is a plethora of open-source projects online that can be used for additional context. Our product is also designed to have a small footprint, which enables users to easily set up our board in a variety of environments, such as classrooms, arcades, community centers, and even homes.  — Aiden

 

B. Our product solution is designed to create a game experience that is accessible, familiar, and enjoyable for a broad range of users. Because games are often played in shared social settings, cultural values such as inclusivity, fairness, and ease of participation are important considerations taken into account within our design. The system is made to be playable by anyone, regardless of prior sports experience or familiarity with similar arcade games. In our game, this is illustrated through simple physical interactions, visual feedback, and straightforward scoring logic so that the product can be understood quickly without long instruction manuals. By lowering barriers to entry, the game better serves users and supports a fun community bonding experience. — Vivian

 

C. From the standpoint of environmental considerations, we of course plan to limit any unintended adverse affects that it may have on the environment. Although we have good reason to believe that the main purpose of our product would not have direct negative effects on the environment, we still take into consideration the power consumption, building materials, and longevity of the product. In terms of power consumption, the system should use the same amount of power as a typical electric appliance based on our design, which we believe is reasonable. We also plan to construct the main body of the system out of composite wood, which is highly sustainable. We understand that the electrical components of the gantry, microcontrollers, and sensors rely on materials that are obtained through environmentally destructive ways, however, the use of those components is strictly necessary and shall only remain as such. Finally, our product is designed to be played over and over again for as long as possible, and thus waste should be minimal. — Bing

 

This week, Bing crushed our Design Review presentation. After class, Hyong, our advisor, pointed out a critical component to our game, one which we identified ourself to be make or beak: the batting experience.

We aren’t trying to make this a baseball simulator, but we still feel we can achieve an intuitive, skill-based batting experience, similar to how other arcade baseball games do. Pitch delivery will be predictable, with just enough variability in speed and movement to make it difficult. Bat swing to flapper actuation will be accurate and low latency. Scoring outcomes will depend on how well-timed swings are.

A few risks that we discussed this week were:

1. Pitch speed: Our current pitch system will be powered by belt-driven linear actuators that are powered by NEMA17 motors. By increasing our motor driver strength and operating at the upper end of current ratings, we believe we will get RPM from the motors and thus sufficient pitch speed. If not, we have discussed a machine similar to the “JUGGS machine” that is used to sling American footballs, using 2 DC motors and wheels. Another alternative would be to rely purely on gravity for the ball to fall fast, and increase the game board slope.
2. Ball return: After a ball falls into a scoring pocket, it needs to be routed back to the “Pitcher’s Mound”. This is a challenge, since we want the ball to fall through the playing surface so that it can be detected by break-beam sensors, so it will need to climb back to the surface plane while avoiding under table obstructions like the Gantry. We discussed a few different methods to resolve this, including chute like paths for the ball to fall through the surface, then come back out down below, relying on the fact that the game board will be angled towards the batter. Once the ball pops back on to the surface below, the gantry can drag the ball back to the mound. An alternative would be to have shallowed grooves rather than fall-through pockets, again taking advantage of gravity and geometry to make a convenient pickup spot for the ball. If all fails, we can have a Air Hockey style puck drop-in and return, where the pitched needs to place the ball on the mound after it is returned to them below in a slot.

Little has changed with our design, as we are still waiting to receive our first round of components. Our schedule has changed slightly, as the gantry equipment won’t come in until after Spring Break. Thus, Aiden will shift his focus to the Coupling Mechanism and Game Board for now. The schedule here reflects that: gantt_chart_2_21

We look forward to beginning the development of some of our subsystems and finalizing the designs for others.

This week, we spent most of our time together finalizing the designs of our individual subsystems, and updated our project planning into a more detailed day-to-day Gantt Chart (linked here). We also submitted our initial orders for the components that we will be using for the project.

During our meeting with our capstone advisor, we received some follow-up feedback regarding the design of our project, and we feel confident in continuing with our current plans, while of course being cautiously flexible about any potential changes that may arise in later weeks. For now, we will keep working to deliver the product that we have promised: a fun, engaging, and immersive baseball arcade game.

As to how we are keeping in considerations of public health, safety, and welfare, social factors, and economic factors:

Our product is designed to provide a fun, physically engaging game that revives the spirit of retro arcades while combining it with exciting technology. From a safety standpoint, we mitigate hazards associated with a moving ball, moving mechanisms, and electrical power by implementing physical barriers and clear zones around any electrical components. The play area will include a defined batting box to prevent injuries in the swinging area and software safety implementations that prevent motion when the game is paused, reset, or when a fault is detected. We also plan to include an easily accessible emergency stop and a conservative safe state. Electrical safety is addressed with proper insulation and connections, keeping accessible surfaces at safe voltages.

From a public health /well-being perspective, the game encourages social play and stress relief through an interactive two-player experience. We also consider accessibility and user welfare by designing the interface to be simple and inclusive with clear visual cues and game states. The play experience doesn’t require advanced athletic skill and is easily enjoyed by all. —Vivian

In terms of social factors, the baseball theme of the game lends itself to a more North and Central American-centric audience. Given our mission to create a fun experience for all, we are designing the game with intent to appeal to a universal audience—with snappy mechanics and relatively simple rules—so that it could be enjoyed by all groups of people regardless of their experience or knowledge in baseball. In addition, we are also aware that the physical nature of the game can pose a physical barrier for people with certain disabilities. Although the physical hitting aspect of gameplay is something we do not want to compromise, we will make the bat as lightweight as we can in order to allow as many people as we can to engage with our game. —Bing

For economic factors, our system has been designed to fit with room to spare under our $500 budget, making it far more accessible than other arcade machines which typically cost thousands. Similarly, our components have been selected with easy of access in mind, as many of them are commonly used for hobby projects. These components have a lot of free and open-sourced peripherals that go with them, such as Bluetooth packages for our MCUs and build instructions for the aluminum extrusion hardware for our gantry. Many of our components have been purchased from Amazon for convenient, fast, and trustworthy sourcing. —Aiden

In week one, we had the idea of re vitalizing a vintage arcade game since modern video games are increasingly dependent on virtual connection. This led us to some ideas such as virtual pool or a sports simulator, but we ultimately liked the idea of creating our own game from scratch (whilst taking some inspiration from pinball). This would bring back some of the nostalgia we felt was missing from modern video games and encourage in person competition while adding a new spin. We settled on creating a baseball style pinball game, where a real-life swing would control the paddle. Additionally, a gantry would propel the pitch to add complexity.

We currently are just scoping out the project and deciding what we need for each part. Since we are in the design stage right now, it is imperative that we each have a good idea of how our parts work , what we need for each component, and how they fit together. This way, we can leave ample time for testing and have a clear roadmap. There are currently no changes to the project idea as we haven’t ordered materials yet or run into technical problems.