{'fraction_non_alphanumeric': 0.026685393258426966, 'fraction_numerical': 0.0049157303370786515, 'mean_word_length': 5.012658227848101, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Two approaches in solving Rubik’s cube with Hardware-Software Co-design

Algorithms for solving Rubik’s cube have been an active research area since the first appearance of the cube in 1974. The challenge posed when solving the cube is to choose an algorithm that solves the cube for the minimum number of steps. Many algorithms are already implemented in software, but not many are tested with modern hardware-software methodologies, such as hardware-software co-design. Here, the challenge is to take into consideration limiting factors of hardware and implement the most efficient solution. In this paper, the hardware/software co-design is used to solve the random configuration of Rubik’s cube. Two algorithms are used: the Basic algorithm and the Kociemba algorithm. The Basic algorithm is easy to understand and implement but requires many more steps to solve the cube than the Kociemba algorithm. The Kociemba algorithm requires some pre-processing tasks, such as depth-first search and pruning trees, but can solve the cube in about 25 moves. Both algorithms are implemented and tested on a custom-made robot with mechanical parts, actuators, grippers and Intel’s DE1-SoC for drive control and implementation of solving algorithms. The robot successfully solved a number of random configurations. Performances (running time, number of moves needed for solving the cube) of both algorithms are measured and compared.