P01: Card Shuffler

Team

• Adam Gajdoš - 3D modeling;
• Marián Jarník - team leader, electrotechnics, assembly;
• Róbert Karpiel - domain expert, project administration and documentation (EA / Prolaborate / WikiFactory / Joomla).

Motivation

A card shuffler is a device that is used to randomly rearrange a deck of playing cards. There are several reasons someone might want to use a card shuffler, for example:

1. Speed, efficiency, convenience: Shuffling cards by hand can be time-consuming. A card shuffler can quickly and efficiently shuffle the cards, making it faster to get to the game. Therefore it can be a useful tool for people who host regular card games or for those who play multiple games in a row.
2. Randomness: Many often-used methods of shuffling, such as "overhand shuffle", are extremely inefficient in producing truly random shuffles. Riffle shuffles approach randomness much more quickly, but they are also harder to execute.
3. Accessibility: Some people may have difficulty shuffling cards by hand due to physical limitations; a card shuffler can make it easier for them to participate in card games.
4. Reduced risk of cheating, professional use: Shuffling cards by hand can open the possibility of cheating, as a skilled person may be able to manipulate the cards. A card shuffler can make it more difficult to cheat by taking the shuffle away from the players' hands. In casino or professional card game tournaments, card shufflers are often used as well in order to ensure fair play and to prevent cheating.

Our major motivation was to speed up and automate the tedious preparation of card games so that players can use the time needed to sufficiently shuffle the cards more meaningfully. This way, we could automate (and make more interesting) especially those card-game-related activities, which are usually perceived as the least fun; furthermore, we wanted to raise awareness about the less intuitive facts about randomness in card and board games, such as the difference between various kinds of shuffles (and possibly use the end result in our own randomness-focused experiments).

Randomness in card shuffling

Not all card shuffling methods are equal; one of the most common methods used by beginners, overhand shuffling, requires about 10.000 shuffles to start approaching statistically insignificant levels of non-random bias. However, riffle shuffle, for example (shown in the upper right corner) only requires 7 to 8 shuffles to reach the same level of randomness.

External sources (papers) on the subject:

• Trailing the Dovetail to its Lair (7 shuffles) (paper, direct download)
• Shuffling Cards and Stopping Times (paper)
• The Overhand Shuffle Mixes in Θ(n^2 log n) Steps (paper)

Team vision

As part of working on this project, we wanted to focus mainly on and gain experience in the following areas:

• the basics of 3D modeling in general, 3D modeling tools and subsequent printing-related software,
• try out 3D printing and pre-print optimization in practice,
• creating a tangible product / prototype (as programmers / CS students, we usually only create software) that we could potentially later even use for our own statistical experiments.

Strategy and specification

At the beginning of the project, we identified / determined the following major steps:

1. problem analysis, getting to know similar existing solutions, specification,
2. 3D model design inspired by existing solutions,
3. identification and procurement of necessary external components (engine, gears) compatible with our model,
4. 3D Model printing, prototype assembly (incl. drive and power supply),
5. prototype testing.

Our final goal was to create a device capable of mixing standard decks of 52/32 playing cards mechanically (using the "riffle shuffle" method) powered by an electric motor and a battery.

Existing solutions

We drew inspiration from multiple existing 3D-printed card shuffler solutions, for example:

• Manual Playing Card Shuffler by RockstarAlchemist

Implementation

Initial design

We started by creating a v0.1 design sketch of the expected device:

As can be seen in the sketch above, the original design included a single motor and a gear/transmission mechanism for force transfer. In later phases, these choices were superseded by a two-motor design.

3D design

During the modeling phase, we went over the total of 7 full iterations of prototype design. We used FreeCAD as our 3D CAD modeling tool and PrusaSlicer for STL-to-G-code conversion and printing optimization. Select pictures of the last iteration of all parts can be seen below; STL files and full documentation are available at the WikiFactory repository.

Process of designing one section of the 3D model in FreeCAD (shuffler body):

Final iteration

Body

Card holders

Drawer

Axes

Fully assembled model

(FreeCAD + Assembly4 extension, incl. motor models)

External components

Outside of 3D-printed parts of our design, a single common 9-volt battery, electrical switch, two motors (LaskaKit LA143059) and necessary wiring to power the device were also used.

Assembly

Assembly of the 3D-printed parts went mostly according to expectations; however, the motor holders (which were reworked and diminished in one of the prototype iterations in order to cut back on material costs and printing time; see below) proved to be too small to reliably hold the motors, especially when turned on.

The originally intended wiring method (series) had to be also switched for a parallel alternative in order to even out motor speeds (see example videos at the WikiFactory repository).

Testing

Issues identified

During the final testing, one major issue was identified - the cards were not moved quickly / far enough to slide through the gap between the card holder and central shuffler area. Due to the gap being too large, too many cards managed to get into the gap at the same time and got stuck on occasion. Furthermore, some of the friction-induced kinetic energy was often wasted on card rotation instead of merely pushing the cards into the central area.

Some alterations were made to mitigate these issues, but only with partial success, such as moving the axes closer to the gap, limiting card rotation (see temporary solution below) and using various materials to increase their friction (masking tape, insulation tape, silicone or rubber bands). Due to time- and tool-related constraints, re-printing of the relevant 3D parts or ordering stronger motors was not possible in time.

Recommended solutions

We would recommend the following improvements to mitigate some of the issues faced:

• narrow the gap which the cards fall through to the central section (to force fewer cards to go through at any given time),
• introduce a more permanent solution to undesirable card rotation directly in the 3D model,
  • ideally movable/detachable/customizable, as card sizes differ.

p02

Deafinity

The doorbell for people with impaired hearing

Motivation

A doorbell for deaf individuals or those with hearing disabilities can greatly improve their daily lives by providing an alternative method of notification when someone is at the door. This can be especially useful for those who may not always be able to hear a traditional doorbell or may not have someone with them at all times to assist them.

Having various LED devices or vibrating devices placed around the house allows the homeowner to be notified in any room they may be in, rather than being limited to the sound of a doorbell which may not always be audible to them. This gives deaf or hard-of-hearing individuals more independence and allows them to feel more confident in answering the door on their own.

Additionally, a doorbell for deaf individuals or those with hearing disabilities can provide a sense of security by alerting the homeowner to someone at the door, even if they are not able to hear the doorbell. It can also be a useful tool for those who may receive frequent visitors and need an easy way to know when someone has arrived.

Overall, a doorbell for deaf individuals or those with hearing disabilities can significantly improve their quality of life by providing an accessible and convenient way to be notified of visitors at their door.

Using a Raspberry Pi for the Deafinity project can be a good choice for several reasons:

Cost: Raspberry Pi boards are relatively inexpensive, making them a cost-effective solution for the Deafinity project.

Versatility: The Raspberry Pi is a versatile computer that can be used for a wide range of projects. This makes it a good choice for the Deafinity project as it can potentially be repurposed for other uses in the future.

Connectivity: The Raspberry Pi has built-in Ethernet and WiFi connectivity, making it easy to connect to the internet and other devices. This can be useful for the Deafinity project as it may need to send notifications or signals to various devices around the house.

Community: The Raspberry Pi has a large and active community of users and developers, meaning there is a wealth of knowledge and resources available for those working on the Deafinity project using the platform.

Peripherals: The Raspberry Pi has many peripherals available, including LED displays, sensors, and motors, which can be used in the Deafinity project to provide notifications or signals to the homeowner.

Overall, the Raspberry Pi is a good choice for the Deafinity project due to its low cost, versatility, connectivity, and availability of peripherals and community resources.

3D Printing

The Deafinity project has used 3D printing to create two custom boxes: one to house the doorbell button and one to house the LED notification device. These 3D-printed boxes allow for a customized and tailored fit for the specific components used in the Deafinity project. The project required custom boxes to house the doorbell button and LED notification device, and 3D printing allowed for the creation of these tailored and precise fits.

In addition, 3D printing was useful for prototyping in the Deafinity project. It allowed for the creation of prototypes of the custom boxes and other parts, enabling the testing and iteration of different designs before committing to a final version.

Incorporating hinges into the 3D-printed boxes for the Deafinity project allowed for easy access to the electronic components inside while also providing a secure closure. This was made possible through the use of 3D printing, which allowed for the creation of these custom boxes in a single print.

In addition, 3D printing allowed for the precise and accurate placement of the hinges on the boxes, ensuring that they functioned smoothly and effectively. This added a level of convenience and ease of use to the Deafinity project, as the boxes could be easily opened and closed as needed.

Overall, the use of 3D printing in the Deafinity project allowed for the creation of custom boxes with hinges in a single print, enabling a convenient and secure method of accessing the electronic components inside. This proved to be a valuable and effective use of 3D printing in the development of the project.

Assembly 

Doorbell

The doorbell component of the Deafinity project consists of a Raspberry Pi, a battery case, and a mechanical keyboard key housed in a 3D-printed box. These components were assembled as follows:

First, the Raspberry Pi and battery case were placed inside the 3D-printed box. Mounting brackets or other securing methods were used to hold these components in place inside the box.

Next, the mechanical keyboard key was mounted onto the exterior of the box, serving as the doorbell button. The keyboard key was then connected to the Raspberry Pi using the appropriate wiring and connections, allowing the doorbell button to trigger the Raspberry Pi when pressed.

Finally, the box was closed and secured, making sure that all components were securely in place and that the doorbell button was easily accessible from the outside.

Overall, the doorbell component of the Deafinity project was assembled by placing the necessary electronic components inside a 3D-printed box, connecting them, and securing the box to ensure everything was in place and functional.

Signal box

The LED signal box for the Deafinity project is comprised of a Raspberry Pi, battery case, breadboard, and LED, all housed inside a 3D-printed box. These components were assembled in the following manner:

The Raspberry Pi and battery case were placed within the 3D printed box and secured in place using mounting brackets or other methods. The breadboard was then connected to the Raspberry Pi using the appropriate wiring and placed inside the box. This allowed the Raspberry Pi to control the LED.

The LED was placed in the designated hole on the exterior of the box and connected to the breadboard using the appropriate wiring. The box was then closed and secured, making sure that all components were properly in place and functional.

The LED signal box for the Deafinity project was assembled by placing the necessary electronic components inside the 3D printed box, connecting them, and ensuring that everything was securely in place.

Who are we and what have we done?

We are the final year students at FIIT STU, Samuel Vanek and Dominik Puk.

As part of the Systems Thinking course, we have designed and created a "Messenger" project which is used to display a desired text between two people via a web application and a display in the form of a matrix LED display.

The solution consists of 3 parts:

• Fabricated box
• Web application
• IOT hardware

  Design of the solution

In the following chapter, we will present the design of our solution for the individual parts.

Component diagram

Our proposed solution consists of two main component parts:

• Local part - fabricated part + IoT hardware
• Web part

The Local part of our solution consists of the heart of our system, the ESP12. This ESP uses a matrix display to display information and also has a reset button. The devices will be stored in a fabricated box, which we will introduce later. It consists of three parts.

The Web part of the solution consists of a REST web service used for storing messages from the user part and sending them to the ESP12 for display if requested.

Web application

Design of the basic screen for sending messages to the local device.

The screen will have one text field where we can type in the text that is to be displayed on the device. The second will be a button that we can use to send the text itself.

Design of the box

Our box will consist of three parts:

• Box - LED matrix and ESP module components placed inside
• Front cover
• Rear cover

​

Design of the box in which the LED matrix and ESP module components will be placed, along with dimensions, can be found in the image below.

​
The top part of the image shows the box from the front. The LED matrix will be placed in the cutout. The pins of the LED matrix will be located in the cutout on the left, from where the wiring will lead to the back part to the ESP module. There will be circular cutouts with a depth of 1.1 cm in the corners of the box. The cutouts will be used to attach and easily remove the front cover.

The lower left part shows the box from the back. The ESP module will be attached to two columns on the left with screws. The pins and wiring from the ESP module will lead into the box, which is why there is a cutout in the right column on the bottom. The wiring from the column cutout leads to the cutout on the right, where it powers the LED matrix in the front. There are cutouts in the corners for attaching the rear cover.

The following image shows the designs for the rear and front covers, which attach to the box and create a whole for placing and protecting the components.

​On the left is the design for the rear cover. The cover is filled throughout. There will be holes in the corners for attaching the cover to the back of the box.

On the right is the design for the front cover. In the middle part of the image, the cover is shown from the front and its dimensions correspond to the front of the box so that the entire LED matrix is visible. In the top part of the image, the cover is shown from the back. The cutout in the middle is extended to fit a piece of plexiglass which will protect the LED matrix. In the bottom part of the image, the cover is shown from the top. There are cylindrical protuberances in the corners that will be inserted into the front of the box and secure the cover to the box.

Solution

In this chapter, we will describe the individual parts of the solution based on our design.

Fabrication

In this part of the solution, we will describe the process of fabricating the box model along with the iterations that arose from the deficiencies of the previous prototype. We created the box and cover model using the Blender3D modeling tool.

​

First iteration

Model of boxView case_model_1.stl @ Wikifactory

​

Front cover modelView predny_kryt_model_1.stl @ Wikifactory

​

Back cover modelView zadny_kryt_model_1.stl @ Wikifactory

​

The image below shows the first printed prototype.

Errors occurred during printing, resulting in the creation of the second iteration model. The design also had to be changed because it proved to be non-functional after implementation.

List of errors in the first prototype:

• Cylindrical protuberances on the front cover fell off during printing and also broke when inserted into the box

• Incorrect dimension of the thickness of the columns of the box. The columns are too thick, it is not possible to attach the ESP module to them because the pins of the module are obstructed by the columns.
• Printing error. The model separated during printing, resulting in the height of one corner of the box being smaller.

• Dimension of the height of the cutout for the LED matrix. The LED matrix is not securely placed in the box and has a large vertical clearance.​

  Second iteration of model

In the second iteration, we redesigned the front cover. Instead of protuberances, the cover will contain holes and will be attached to the box with screws. This solution does not provide easy manipulation and removable, but it is necessary in terms of strength and quality. The dimensions of the cover are retained from the first design.

​

We also reduced the height of the cutout for the LED matrix to 3.5, narrowed the columns in the back of the box, and corrected the error in the model that caused the corner to curve.

​

Final box modelView case_final.stl @ Wikifactory

​

Final front cover modelView predny_kryt_final.stl @ Wikifactory

​

3D printing of the individual parts took approximately:

• Box 8.5 hours
• Front cover 1 hour
• Rear cover 1.5 hours

​

Web application

As stated in the design, the web application provides input for the text to be displayed and a button to send the text itself. This text is then saved on the backend of our web application and is made available upon request from the local part.

Hardware

Node MCU ESP12 - node_techFun

Matrix 32x8 - matrix\_techFunConnection

Final product

Description of final product

The local device operates in two modes:

1. AP - access point
2. Non-AP - display

The device is always in AP mode at startup or reset. In this mode, we can connect to the device via WIFI. After connecting, a web page is offered to us, through which we can change the WIFI network to which the device should log in. After saving to this WIFI, the device will automatically log in and switch to the second mode. If the device is within range of the last WIFI network when turned on, the device will immediately switch to Non-AP mode.

In Non-AP mode, the device periodically queries a web service to retrieve the text to be displayed. This text is displayed cyclically on the matrix display. If no text is received from the web service, a default message is displayed.

Ideas for improvement

1. Adding plexiglass in front of the matrix display
2. Improved web application
3. Creating different modes that the user can switch between (displaying account status, displaying messages, displaying...)
4. Expanding for multiple devices

Quad Finder

Team members:

• Bc. Matej Kubena
• Bc. Miroslav Pavlák

Introduction to FPV

Issue

While flying an FPV (First person view) drone one can find themselves in an unfortunate circumstance that requires either an emergency landing to be performed or that can result in a crash. Such circumstances can be classified as:

• Loss of video signal:
  • Cross-channel interference
  • Signal attenuation caused by the environment
• Loss of Voltage:
  • Short circuit of onboard electronics

FPV drones do not come with RTH (Return To Home) functionality as standard as opposed to drones made by DJI. Thus in case of signal loss in most cases is the pilot powerless and can only hope that their drone will survive upcoming crash with the least damage possible.

In the instance in which the drone crashes in a dense forest environment, it becomes difficult for the drone pilot to trace the drone to it’s crash site without any active location monitoring. The task of retrieving the drone can be made all the more difficult by the fact that during the crash of the drone, the main battery can become disconnected thus effectively shutting off the power for the entire drone with all of its modules.

Solution

In order to accurately communicate the drone position with the drone operator, a GPS module can be used. It can be installed directly on the drone thus actively monitoring the GPS location of the drone. Then if the location data is transmitted to the drone operator, this data can be then helpful in the subsequent search for said drone with the knowledge of the last known position of the drone. Such GPS module can be also used to create an RTH functionality for the drone.

Another module that the drone will be equipped by is the buzzer module powered from the main battery. Although in the event in which a crash occurs and the main battery is disconnected, the buzzer will become useless. Thus an appropriate proposition is to power the buzzer with an external battery independent of the main battery of the drone.

Needed parts

For the implementaion of the proposed idea will be needed:

• GPS module - Beitian Dual BN-220 GPS
• Buzzer module - Finder JHE42B-S 110DBI Buzzer
• 3D printed mount for the listed modules

Proposal

GPS and the buzzer module with the external battery will be soldered to corresponding pins of the control unit of the FPV drone. Subsequently these modules will be installed onto the mount and attached to the frame of the drone.

Wiring diagram featuring the GPS module and the control unit

Wiring diagram featuring the buzzer module and the control unit

GPS and Buzzer Module Dimensions

Design of the Mount for the GPS and Buzzer Module

GPS Rescue Configuration

In the Sensor Input section under the Ports tab we will select the port UART3 (Universal Asynchronous Receiver-Transmitter is a computer hardware device for asynchronous serial communication) for the GPS module. Next we will set the bitrate at 57600bps. At last we select the Save and Reboot button.

In the Configuration tab we check the GPS field. As Protocol we choose Ublox and keep the rest default. Then select Save and Reboot.

In the GPS RESCUE section of the Modes tab, we chose the channel number according to the switch on the controller we chose earlier, in our case it is AUX 6. Then select Save.

In the OSD (On-Screen Display) tab we will add all of the elements listed below and position them according to ones prefferences. Then select Save.

• Flight distance
• GPS latitude
• GPS longtitude
• GPS sats
• GPS speed
• Home direction
• Home distance

Testing

In this section we will verify functionality our solution in real life, which is divided into multiple scenarios.

Senario 1: During this scenario, we will simulate a crash where the drone's main battery is disconnected. In principle, we just disconnect the drone from the main battery and wait for the buzzer to respond.

Result: After disconnecting the main battery, the buzzer started beeping within 40 seconds until it was manually turned off. Proof of concept is shown in this video.

Senario 2: In this scenario, we will test the functionality of the GPS module attached to the drone, whether the information provided by this module is shown on the display of the FPV goggles and whether the information about the current position is right. In principle, we take off at a pre-arranged location and note down information about the current location. Then we will verify them via the Google Maps web app.

Result: In the following figure you can see that the display of the FPV goggles shows all the information that we have configured using the BetaFlight program. In the next figure you can see a map with the current position of the drone, which corresponds to the real position of the drone at the time the picture was taken.

Scenario 3: In this scenario we will verify the functionality of the GPS Rescue functionality that we have configured on the drone, the functionality can be tested by flying far enough to cause signal loss or by using a switch that will trigger the GPS Rescue functionality.

Result: When the drone was 441 meters away from the initial take-off position, the signal was lost. Subsequently, the GPS Rescue functionality was activated and the drone switched to FAIL SAFE mode, when the drone took off to the default altitude and automatically began to return to the original take-off position. When the drone was at a distance of less than 50 meters from the initial take-off position, the FAIL SAFE mode was turned off and the pilot took full control of the drone. The sequence of these steps is illustrated in the following figures or in the video.

References

[1] BetianOfficial Store, „Aliexpress,“ Betian, [Online]. Available: https://www.aliexpress.com/store/2837118. [Cit. 6 November 2022].
[2] Goodluck338 Store, „Aliexpress,“ Goodluck338 Store, [Online]. Available: https://www.aliexpress.com/item/32919224534.html. [Cit. 6 November 2022].
[3] Beitian, „Banggood,“ Beitian, [Online]. Available: https://files.banggood.com/2016/11/BN-220%20GPS+Antenna%20datasheet.pdf. [Cit. 6 November 2022].
[4] blueRC, „iFlight Nazgul5 - GPS Modul Einbauen und in Betaflight einrichten - Tutorial mit Testflug,“ Youtube, [Online]. Available: