Author: akim2

• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Although we stabilized it a lot, the dispenser still behaves unpredictably from time to time, not dispensing the card at all or dispensing it too hard. It happens either when the cylinder that is pushing the card forward is too close to the card or too far. We cannot do much about the problem of it dispensing cards too far. The good news is that it is quite rare.

The problem of cards not being dispensed at all is dealt with by simply retrying to dispense the card.

 

• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

The design of the dispenser changed. Now we do not use gears for the DC motor and instead directly rotate the cylinder with the dc motor. We also removed the top cylinder and instead are rotating the cylinder against a flat surface. This reduces the inconsistencies caused by the difference in thickness of the cylinder on every rotation.

The only cost to this is the additional budget spent on printing more parts. It ended up stabilizing the dispenser a lot, so we think it is worth it.

 

• Provide an updated schedule if changes have occurred.

Same as last week’s plan.

 

This Week’s Special:

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

We tested that the model detects the card well when situated in the exact production environment (i.e. in the dispenser). We figured that with constant lighting condition and fixed position, the model effectively “memorizes” the cards to classify them successfully. We found out that it achieves near 100% accuracy with an average of 95% accuracy.

• Weight Sensor

With prior knowledge of the coin being 11g, we tested if the weight sensor also shows linear behavior when we increment the number of coins on the sensor. While it followed the linear behavior pretty well, suddenly taking off the coins made the sensor failing to scale back to 0g, causing issues in future iterations.

• Tap Detection

Since there are essentially 2 moves the users will make with taps (double tapping and holding), we tested if the detector segregates these two moves correctly. Also, we identified that there were some false positive rates with both, 19% for double tapping and 3% for holding. As such, a tweak in testing method for fixed condition made reliable testing condition and made the false positive rates to 0.

 

I spent the whole week with the team trying to get the dispenser to work. The problem was that we needed the distance between the rubber-covered cylinders and the card to be very precise. Too close, the motor got stuck and did not spin. Too far, and the card did not get dispensed (or took too long to get dispensed, as the cylinder only touched the card occasionally).

After rebuilding the dispenser with wood and trying out different things with the motor and the cylinders, we decided to simply remove one of the cylinders and print a new dispenser with new cylinder that can be directly attached to the gear. This way, we could minimize the possible sources of errors.

And today, we were finally able to get the dispenser to dispense cards quite reliably. It still failed sometimes (which we suspect happens because the cylinder is not a perfect cylinder), but we found that we could simply retry dispensing, and it worked.

Now we can finally move onto trying the full game play with the implemented game state manager. Before that, we will need to connect all the inputs and outputs between the programs in RPI and Arduino, but that will not take too long, as we already tested linking the two through USB port and sending/receiving serial data.

Worked on making the dispenser work all week. It behaves very unpredictably right now, and that is the biggest problem I am facing. When it works, it dispenses the cards very accurately, but when it does not, it simply does not spit out the card (gets stuck). Tomorrow, I am making a last attempt on stabilizing it, and if does not work, I will just move on to the next part.

No time to take pictures,.

Lots and lots of CADs and laser cutting.

All the small misalignments between parts have been fixed using wooden pieces joined together with joints and hot glue. For example, initially, we decided to stick all parts onto the machine permanently, but we discovered that it would be better to have them be detachable. So, I made a detachable wooden case for each of them to hold them in place. There are more of these very small changes that were mostly done using laser-cut wooden parts.

This is the semi-final machine body we have for now. It is only half-functional, because the cylinder connected to the servo does not move the card far enough, making it impossible for the two cylinders at the exit to grab it firmly and dispense it. We are going to add two gears (1:1.4) to the servo and the cylinder to increase rotation.

We were actually supposed to be done with this part already, so we are behind schedule right now. Hopefully, the gears get printed quickly, because integrating the gears into the machine should not take long.

I did confirm that everything else in the machine works perfectly fine, so once the servo issue gets cleared, it should be ready to be tested and verified.

We have a lot to do by next week. Hopefully, the RPi and Arduino won’t cause any trouble as we connect them.

 

Verification:

I will need to test the dispensing accuracy and machine rotation accuracy along with their latencies. Both tests have been done roughly, but the full quantitative tests still needs to be done. The size of the machine already meets the requirement of 20.3 cm x 20.3 cm.

Those complete the hardware and machine body side of the requirements that we have set.

We’re mostly working towards finalizing the sub-components of the machine. We believe that integrating the components could cause various unforeseen challenges that could jeopardize the success of the project.

We assembled the parts in autodesk fusion 360 to get a general sense of how our assembled design will look like in real life. With that, we were actually able to catch a slight flaw in the design and were able to fix it. We can now use this as a guideline when actually assembling the parts.

One potential problem that we may face is that the gears we printed and the motors may not combine very well. The current plan is to simply stick the gears and servo’s plastic parts together with adhesive, but if that does not stick too well, we will need to find another way to make those work together.

 

Our design plan is concrete for now, and we are sticking with what we have. If we encounter unforeseen problems as we actually assemble parts and integrate systems, then we will definitely need to adjust accordingly, but for now, no change.

 

We’re currently following the updated schedule from last week.

 

Worked on finishing up the cad for the components. I finished up the platform for the card shuffler to sit on and exported the dxf file to laser cut. However, techspark was too crowded this Friday, so I am planning on visiting again tomorrow (Sunday) to cut it and assembled them. The positive side about this delay though, was that I was able to discover that the initial design of the platform had the angle too high and was able to fix it. If we went on with that design, it could have resulted in the cards from the shuffler falling out before they could get shuffled.

With that discovery, to make sure that our design looks good, I decided to assemble the parts in fusion 360 to get the full picture. Since I grabbed parts from the autodesk gallery, some parts are not exactly what they are (like the caster wheels, and the shuffler, which I just replaced with a simple box), but they do a good job of showing us the general sense of where we are going. Now with this as the guideline, I will probably have an easier time assembling the parts together.

 

When I assemble the parts tomorrow, if it looks like how it is here, then we are good. If not, then we are behind schedule, so I will need to speed things up.

 

We ordered the sd card for the RPI before break, but it got canceled by Amazon, so we reordered it recently. This has significantly delayed everything related to the main system. Right now we are coding it separately, since we already know it will be written in python.

We planned on using a 7mm mdf for the machine body, but it turns out that 3mm provides enough durability. So, we now have a significantly less heavy machine body, which will decrease stress felt by the servo.

Since we’ve been working on the systems that do not require the delayed parts (SD card), there aren’t any changes required for the schedule.

Machine body printed out.

This week, I cut out the main machine body of ACE, made of mdf. After consulting with a person working in Techspark, I realized that the thickness of does not need to be overly thick. So, I decided to use a 3mm mdf, which significantly reduced the overall weight of the machine. So, I think we can continue using the motor shield we have for now.

I have confirmed that the machine does spin properly, within the latency bound we have set as the design requirement. Right now, I have temporarily put the pieces together in tape, but they will soon be glued together. Once the dispenser gets printed, we can try placing it on the designated space and see if everything works out.

 

Roughly on schedule, with some parts ahead and some parts behind. It was unexpected that our order for the SD card got canceled.

 

• What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

No special risk at this moment. However, since our project requires a combination of many components. All parts must be prepared on time to have enough slack time. 

• Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

None

• Provide an updated schedule if changes have occurred.
  

Slightly behind in combining parts to the machine body. It must be done by next week.

• This is also the place to put some photos of your progress or to brag about a component you got working.

DXF file ready to be cut in techspark fablab.

This week, I worked on learning how to make dxf files for laser cutter and making it. It honestly took me a lot longer time to do this, as I had to get the dimensions right.

It also took some time because I wanted to make it in a way that lets me change the hinge size according to the thickness of the mdf I am going to use. This was to add flexibility in our machine body’s design in case we need the material to be less thick to reduce weight or thicker to made it stronger.

Although I did very selectively place the holes considering the size of inner components and their placement, how it actually looks when assembled in real life may be different. So the top part may need to change slightly, but the rest should be fine with what we have right now.

I am behind schedule right now, as I should have already cut this board out this week. So, I will need to do that right away on Monday and assemble them. Good news is that all parts (except for RPI sd card) has arrived, which means I should be able to construct the full machine body now.

I do see it taking some trials and errors, but I hope it won’t take too long. That is why we took some time to plan ahead after all: to reduce number of trial and error.