This project was a VTSU electromechanical project at the start of our senior projects class with an initial assigned timeline of 7 weeks and a final timeline of 9 weeks. There were 2 professors (Andre St. Denis and Jeremy Cornwall) and there were 4 groups of 2-3 members each. My group was comprised of Ruby Sartwell and I. Each group was put together based on the solution ideas each person was interested as to ensure each group would end up with a different solution. Aside from the stated problem to be solved, this project was intended for us to practice splitting projects into multiple parts, integrating mechanical, electrical, and software components of a project together, and working on a team.
The problem to be solved in this project was to develop a device which would be able to lay dominos in user selected patterns within the constrains laid out below. Some
Constraints:
Must handle at least 50 randomly loaded dominos
Must place the dominos all in the same orientation
Allows the users to select a run shape:
Straight-line
S-Curve
Circle
Must “auto-trigger” the run after the last domino is placed
Must be safe to humans, furnishings and the room
No single new component costing more than $20
On the right is my bulleted list of responsibilities which will become clearer throughout the explanation of our initial design.
Our solution can be was an x-y gantry with a rotary feeding mechanism and a dropper capable of rotating the domino before placement. We broke this solution into 3 subsystems: dropper, gantry, and hopper then split them between us based on our experience in mechanical engineering, electrical engineering, and programming with my split listed off to the right. Below is some of the initial concept sketches for our solution.
I chose the belt layout of the Prusa Core One (Core XY) because I have that printer making it easy to use as a reference and Core XY reduces the load on the X carriage (carriage that holds the sub-systems which place the dominos)
The hopper would sit on the X carriage with the space of each slot being just large enough for a single domino with some tolerancing allowing for the gravity feeding to work reliably. After feeding into the queue slot, the orientation sensor (a color sensor) would identify what color the face in front of it was and feed that information back to the microcontroller (STM32 F072RB) for rotation decision making with the dropper sketched below.
This initial design for the dropper mechanism (labeled orientation before subsystem was determined) looked at using gears and a servo for rotation and a solenoid for the clamping mechanism. At this time I had not decided where I wanted to start with the z-positioning mechanism although was considering using a lead screw.
Rotary Dropper
Stepper Z-Motion
Servo Clamp
Servo Rotation
Placing Program
Automation
Patterns
CoreXY gantry design
Frame and Rails
Motor design
Programing
Weight distribution
Throughout the project a number of changes were made to the initial design. The first big change was identifying the sensor/queuing components should be in their own subsystem given the cumulative design complexity of the hopper. Below are the changes made to my subsystems (dropper and gantry).
Before modeling I decided on a few details (some changes some new):
Pulleys and timing belts instead of gears to easier get around the z-positioning parts.
The z-positioning mechanism would use a timing belt fixed to the rotation frame.
The pulleys snap in-out for quick swapping for prototyping and maintenance.
Most or all of the mechanism would be 3D printed allowing me more freedom to design & iterate on parts without using the labs due to having a Prusa Core One.
To quickly identify problems with my parts, I would start a print batch every few parts I modeled. This method allowed me to find problems between tolerancing and 3D-print-ability allowing me to have all but the electrical and belts assembled within 24 hours from starting the first CAD model.
Throughout the project there were some other changes made, most being small changes addressing tolerance, material saving and printability. The two major changes are described below.
The first change I made after printing off the first full set of components was switching the slot mechanism from a solenoid to a servo due to the limited space.
The last major change I made was changing the slot pulley to half the diameter of the drive pulley to address the servo being a ±90° and the domino rotation needing to be ±180°
A limitation to our gantry we were asked to work with due to costs was staying away from linear rail and other similar mechanisms. The solution I came up with for this limitation was using wheels which would ride within the channel of the framing as shown in the picture on the right.
Aside from small changes made to fix dimension and tolerance issues found through testing, the major developments were related to how the belts would interact with these parts. The positioning of the belts became the main problem to solve given all of the material which ended up in the same area as the belts were operating, leading to tuning the location of the belt redirections to maximize gantry range while preventing belt conflicts with the wheels. Additionally tolerancing became a serious issue with the belt idlers which can be seen as the cylinder around mid height just right of center on the y-carriage assembly, leading to taking the idler out when time constraints forced us to move onto other parts of the system.
Dropper Section View (last version), not including limit switches or belts.
Y-carriage parts shown in relation to the gantry frame.
Gantry assembly CAD model.
Even with the 2 weeks of extensions on this project, no group had all the functionality required by the assignment, with Ruby and I's functionality being the least of all the teams due to a few reasons detailed below.
The first issue we ran into was the timing belt mechanism used for rotation of the domino once they were in the dropper would not rotate past a few degrees in either direction. Based on my testing this was likely due to belt tensioning issues and was not resolved as to ensure the rest of the functionality could remain on time.
In addition to the timing belt issue causing issues for domino rotation, the servo proved to not rotate as intended anyways after the dropper was installed in the full system. After some testing it was identified that both servos (rotation servo and clamp servo) had their ground wire voltage raised by 1 volt from the microcontroller to the servos. In the testing we checked every electrical junction related to the servos with an oscilloscope to confirm this behavior alongside plugging the servos directly into the microcontroller board resulting in no issues.
Testing on the gantry showed the homing process logically working properly although it was observed the speed was too slow to continue testing without design changes (more than changing dimensions) occurring. This speed issue was caused due to deciding to not install the spacers which were planned to act as bearings due to tolerancing issues and the timeline closing.
While a majority the intended functionality could not be demonstrated, aside from the issues discussed above, the code (that was able to be tested), the mechanical assemblies, and electrical design worked as intended. The overall effort put in by Ruby and I from the design and testing to documentation of our work completed the intended purpose of the project to practice working on a team, splitting up a project into multiple parts, and practicing integration of mechanical, electrical, and software as well as the integration related to working on a team integrating team members contributions to the project.
On the right is a video of our final functionality demo.