Posted on

Sizhe’s Status Report for 4/27

This week, we have worked out the PCB and have found the design is flawed. Thus, I have redesigned the PCB and placed the order. Furthermore, I’ve dedicated time to clean up the interface code with Arduino to prep for the final build out next week in case we need to modify it further.

In term of schedule, we are on track as we will be finished with integration and build out by next week.

By next week, we will hopefully have a successful final product that can register go pieces correctly and the gantry system should also work accordingly.

 

 

Posted on

Zipiao’s Status Report for 4/20

This week, my primary focus was on the software component of our project, where I completed a significant feature: updating the game state based on the detection of new pieces by the hall effect sensors on the physical board. I achieved this through a two-step process involving a Django API, which is activated by our Flask server that handles the movements of the gantry system and monitors the sensors. When a new piece is detected, the API logs an event in our local SQLite database with a ‘consumed=false’ flag. On the front end, AJAX is used to periodically check for these unconsumed records, ensuring that the game state is updated with minimal latency.

This implementation confirms the completion of all major software components, although some minor UI issues remain. These will be addressed next week as we refine the interface for our final demonstration.

In terms of new knowledge acquisition, I found that thoroughly reading electronic component specifications and watching YouTube tutorials on stepper motors were extremely beneficial. This approach not only ensured that our hardware was assembled correctly but also facilitated a quicker practical application of theoretical knowledge.

Posted on

Team Status Report for 04/20

This week, the team’s main focus is on the construction and testing of the PCB board for the hall effect sensor matrix. In addition, we completed the software APIs and logics to deal with the event when a new piece placement is detected by the hall effect sensor, which marks completion of the major software features (gantry movement of opponent’s placement and board update given a new physical piece placed) .

Due to the spacing of the PCB design, we have to solder on multiplexer without header pins to ensure the minimal distance required between the surface and the electromagnet for the movement system to function. Such restriction lead to escalating difficulty in soldering on components without shorting, slowing down the testing process and destroying multiple components during the process. To solve this problem, we decided to decrease the size of the board for the final presentation, while Sizhe made improvements on the original PCB design to be used for the final demo product.

Next week, we will focus on constructing and assembling the final parts once we receive the new improved PCB boards.

Posted on

Shuailin Pan’s Status Report for 04/20

This week, I mainly focused on modeling, cutting and assembling the final outer chassis of the entire system. I also helped with standardizing soldering practice for the hall effect sensor with Sizhe to ensure minimal variance for each piece so that we can avoid connection issues and minimize detection difference.

Schedule and risk wise, due to the consumption of the components, we are only on track for a working 6 by 6 board for the presentation next week. However, Sizhe designed a new improved PCB that is optimized for soldering ease and pathing which we will use for the final product.

Next week after the presentation, I will help with soldering the new PCB boards, further testing, and internal wire management for the final demo product.

Posted on

Sizhe’s Status Report for 4/20

Over the past two weeks, my focus has primarily been on developing a hall effect sensor matrix. After finalizing its dimensions, I completed the PCB design and have spent the past two weeks assembling it. The soldering process has proved more time-consuming than anticipated, particularly due to the challenge of soldering the small hall effect sensor components onto the PCB. Shuailin and I aim to complete most of the assembly by the end of today. Additionally, I’ve dedicated time to coding the interface between the hall effect sensor matrix and multiplexer, rather than addressing individual sensors separately.

In terms of our schedule, we find ourselves slightly behind, having entered the slack weeks. Nonetheless, we’ve made significant progress, having completed all individual components of the project, with assembly scheduled for tomorrow. The primary concern at this stage is integration.

By tomorrow’s end, I anticipate having a functional prototype ready for demonstration at the final presentation next week. Subsequently, we’ll focus on refining the entire system to ensure seamless operation ahead of the final demo during the following week.

 

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

Throughout the process, I’ve discovered that PCB design proves crucial for customized projects. A well-executed PCB not only reduces complexity but also enhances overall aesthetics. Additionally,  documentation and adept project management plays an important role.

I mainly relied on online videos for source of new knowledge and I have found learning by doing is immensely helpful. Purely learning by listening or watching simply wont do the trick as one can quickly forget afterward. However, practical experience and making mistakes help us grow faster.

Posted on

Shuailin Pan’s Status Report for 04/06

This week, I purchased and tested a new 12V electromagnet for the movement system due to the subpar performance of the 5V one. I also measured and modeled the chassis for the entire system to get rid of the old unstable mock prototype.

Design wise, the only update is the switch from the 5V electromagnet to a 12V one to act as the movement system.

Schedule wise, the team is mostly focusing on the software and PCB circuit design as planned. Feeding system has yet to be integrated to the software, but the software logic should be easy.

For next week, I will update the software for feeding system, print out the acrylic chassis for the entire system and assemble it with current built parts. I will also help with PCB design if needed since it’s the most risky aspect of our project currently.

Posted on

Team Status Report for 04/06

Our most significant risk is the design of PCB because the still do not have a physical product that we can test on yet.

Design wise, we figured out the viability of the current design through the interim demo. No re-designing need to be made at this point.

Schedule wise,  we caught up with the progress yet we still need to finalize the design of the circuity component. We currently don’t have any change of plan.

Next week, we will start working towards the final polished product

Posted on

Sizhe’s Status Report for 4/06

This week, I was mainly working on fine tuning the code that communicates between a python web app and a python program that interfaces arduino. The team and I successfully made the player move to actually control the remote gantry system and the python program can successfully detect the sensor rising edge and place a piece on the web app board.

After weeks, we finally catch up with almost everything. The only thing that puts us at risk is the customized PCB as I just figured out the exact dimension this week but don’t have time to make adjustments to the original design yet.

By the end of next week, I hope that I can finalize with PCB and place the order by next Thursday. Meanwhile, I will continue to work on the communication code to generalize for the 9 by 9 matrix of sensors. The team and I will also look into laser cutting and assembling components for the final product.

Posted on

Zipiao’s Status Report 0406

This week, I made great strides in my capstone project by optimizing the Magomoku game’s software, successfully integrating game logic with the Python-controlled gantry system and hall effect sensor data. I revamped the game state management, replacing the error-prone system with a more reliable JSON-style data structure for tracking game status, staying on track with my project timeline.

Next week, I’ll focus on enhancing the web app, adding user-friendly features like game state change notifications and illegal move alerts. I’ll also improve the UI to include real-time player turns, game history, and support for various game modes, aiming to boost user engagement and experience

Posted on

Zipiao’s Status Report 3/30

This week, I mainly focused on the assembly as testing of the gantry system. I assembled the two NEMA 17 linear actuators and figured out the connection of the stepper motor, the CNC shield, arduino, and the A4988 motor drivers. I made sure that the actuators are tuned to a status that it can move smoothly. I also fine tuned the arduino code for driving the motors at a decent speed. This job to make sure that the two actuators can operate smoothly is a crucial milestone for us to move forward. We will demonstrate the simple movement of pieces onto the board with one actuator in the demo. The progress is as expected.

I will likely get the gantry work for more delicate control (i.e. moving the x-y gantry from (a, b) to (c,d) next week, and also connecting the interface (software) and route the piece placement to the motors.