Technical Analysis

Phase III has seen the team make considerable strides in the technical development of the LEGOworks LEGO sorting device. Phase I consisted of mostly rough sketches of concept generations and the team had just started to delve into the analysis regarding mechanical, electrical, and software components. At this stage, the team has refined SolidWorks renderings and motion studies to bolster mathematical and analytical calculations regarding the integral sub-components of the device. Though the electro-mechanical components are integral to the device, the logic framework for image processing contributes to the majority of the “brains” of the product. In this field, the team has also taken critical steps to realize the functionality of the device.

Mechanical

In order to determine what angle the inclined conveyor belt should be set to, the team opted to conduct a mathematical analysis ahead of creating an alpha prototype for the subsystem. The goal was to find the maximum angle at which the conveyor belt could operate without the LEGO pieces sliding down the inclined slope. To do this, the team created a free-body diagram of a singular LEGO brick on the inclined slope, as seen below in Figure 14, and used it to determine the maximum angle at which the brick would be unable to overcome the force of static friction.

Unfortunately, not all of the information necessary to make the calculations are available. As such, the team had to make some assumptions. The first assumption was for the mass of the brick. The team chose to use an medium-sized LEGO gear, piece 612214-50, to represent the LEGO pieces in the set for all mathematical calculations. A picture of this part is shown below. This is because it is one of the most plastic-intensive pieces in the Mindstorms sets, while still maintaining a shape that would allow easy calculations to approximate its mass.

LEGO bricks are made from Acrylonitrile Butadiene Styrene (ABS), which has a density of 1.055 g/cm³. The height and radius of the brick were measured using a tape measure, as was the radius of the holes running through the face of the brick. Using this information, the team calculated the mass of the brick.

V = ro2h - 4ri2h

V = (0.5)2(0.3) - 4(0.125)2(0.3) = 2.896cm3

m = V = (1.055)(2.896) = 3.055g

In order to complete the calculations for the free-body diagram, a coefficient of between the brick and the conveyor belt was needed. Since no amount of research yielded a value for the coefficient of friction between ABS and flexible PVC, the material used for the conveyor belt tread, the group decided to make estimations based off of existing information about the materials. The coefficient of friction between ABS and another object generally ranges from 0.11 - 0.46. The coefficient of friction between two plastic surfaces tends to range from 0.3 - 0.4. Using this information, the team estimated that the coefficient of friction between ABS and the conveyor tread to be approximately 0.35. This was then used to calculate the maximum angle of incline for the conveyor belt, as shown below.

mg*cos = mg*sin

= arctan(0.35) = 〜20०

This told the team that they cannot work with an angle above twenty degrees, or else the bricks will roll down the slope without some sort of external method of keeping them in place. This information was later incorporated into the alpha prototyping of the sub-assembly, where an incline angle of fifteen degrees was used.

For the motor analysis, brushless motors were chosen to increase efficiency and life expectancy since they output more torque and do not wear out over time, unlike brushed motors. A 12V DC power supply has been selected to power all components within the assembly for added safety. The capacity of this supply will allow each motor to draw 5 amps. Any motor chosen must be able to operate on 12V DC and less than 5 Amps. Spur gears will be preferred so that the system can be manipulated by hand when the machine is off. Worm gears are typically self-locking, so it would be impossible to move any driven components by hand if the motors aren’t geared with spur gears. Since space is a concern for this project, the motors will need to be small so that they don’t interfere with placements of other components. Some motors have an output signal that tells a computer how fast it is spinning. This is important so that the software can keep the motors spinning at the correct speeds so that the system stays synchronized. Without this signal, the software would be blind to the motor speed, and driven components could operate out of synch which would reduce efficiency, or cause items to pile up within the system. A chart of the required motor specifications is shown above.

The final aspect of motor selection is the torque requirement. The torque required for each motor to move a Lego from the start of the belt to the end of the belt can be calculated by the equation below, which is a function of diameter, external force (which is assumed to be negligible), friction, mass, and gravity.

For the purpose of this calculation, the team will assume a load of 100 LEGO parts and that the external force is negligible. F is an external force which is simply any forces outside of the conveyor setup that may need to be accounted for. For example, if your load was very tall you may need to consider wind resistance. Under normal circumstances, the force F is negligible and can be set to 0.The roller diameter of the team's proposed design is 15mm, or 0.015m. The team also knows from the weight analysis that the average weight of a LEGO brick is 3.055g, or 0.003055kg. This means that 100 LEGO parts would have an approximate load of 0.3055kg, similar to a conveyor full of LEGO pieces. From the incline analysis, the team also knows that the coefficient of friction between the belt and the bricks to be 0.35. With all this taken into consideration, the team can now calculate the torque required by the motor to overcome frictional forces.

T = 1/2D(F+Wg) = 12(0.015m)[0+(0.35)(0.3055kg)(9.81ms2)]

T = 0.00786Nm

This answer allowed the team to conclude that the minimum required motor torque to move 100 LEGO pieces across the conveyor belt is 0.00786Nm.

Software

There are a few technological barriers to consider when deciding on the image processing hardware and software. The most obvious challenge is the data size of the image or video frame which needs to be maintained at a high resolution to ensure system accuracy. For this device, LEGO pieces will be identified by their shape and size. This means that the image depth and resolution must be at a high degree to successfully identify the pieces.

The image process must operate on an image depth that can distinguish size and shape, as well as factors like edge detection. The camera bay and conveyor belt have been chosen to have white color so the camera can easily detect the colored LEGO as the object in question as it continues down the belt. A couple issues to note is that some LEGO pieces are very similar in size and shape, so there may be situations where shadows or reflections on the LEGO parts are classified as the wrong sort. Although the device can control how many pieces are in front of the camera at a time, the way the parts enter the camera’s field of view cannot be easily controlled. The detail and depth of the image will have to be sufficient enough to accommodate these challenges. The resolution does not need to be super high resolution, but needs to be great enough to detect edges of the LEGO against a solid white background. It would not be optimal for each picture taken to be high resolution, since this would add additional file size to the pictures being sent to the computer and ultimately slow down processing speed. To find a medium, the team determined that a VGA format (640x800) should be a sufficient resolution to support the project. Some common color depths in various camera display applications are 16-bit high color and 24-bit true color. Since the color of the parts is not a deciding factor to the sort, the team decided that a 16-bit high color should be a good depth under the circumstance that color would be more necessary to help the camera find the LEGO in the image. With a resolution of 640x800 and a color depth of 16-bits, the arrives at an image size of 1,024,000 bytes, or 1000Kb. This means that the raspberry pi, in conjunction with TensorFlow must have enough onboard memory to hold an image of this size, which easily checks out. The chosen software is able to run effectively at this level of data intake to ensure the team of its reliability.