The LAM Research Challenge: My Journey in the Nationwide Systems Engineering Competition

Once the problem statement of the Lam Research Challenge was revealed, we immediately began our work. Unpacking the tools provided was an exciting experience in itself—everything from files and screwdriver sets to numerous small components we needed throughout the workflow. It felt like unboxing a treasure chest for innovation.

Development Board Selection

The first challenge was selecting our development board among - ESP32, STM, Arduino Nano, Raspberry Pi Pico.

• STM32 - Having experienced the complexities of working with STM in our curriculum, we ruled it out.
• Micropython - Since most of our team was well versed with python, our choice further narrowed down to ESP32 and Raspberry Pi Pico
• Pi Pico - As the entire team had already worked on the Pi Pico in the earlier round, it became our choice.

It presented us with a different choice, two development platforms that were based on the Pi Pico, one the rapid development board, the other being the universal robot controller board.

A quick search revealed these platforms were proprietary T-Works designs, with no documentation / examples available online. We leaned toward the Universal Robot Controller Board because it included an integrated servo controller, which seemed ideal for controlling the robot.

However, up realizing that we were provided with Serial Servos (not PWM-based), the Universal Robot Controller Board became a less optimal choice. The Rapid Development Board would have been better for the following reasons:

1. Higher number of exposed GPIOs
2. Lesser configurations required to get access to the GPIOs (we had to figure out, the jumper configurations to get the IOs working, initially they were setup as inputs to the DC motor controller)

Actuator Selection

With the board selected, we started working parallely on the software and the hardware. When selecting motors for the actuators, we discovered PWM-based servo motors were not an option for the joints. This left us choosing between:

1. Stepper motors.
2. Serial servos (reserved for joints), with PWM-based servos restricted to the end effector.

We opted for a configuration described in the provided diagram—a combination of two stepper motors and one serial servo motor. Unfortunately, this decision led to significant challenges:

• Serial Servo Challenges: With no prior experience, understanding and configuring serial servos proved extremely difficult. Despite extensive efforts (6 man-hours) using datasheets and library references, we couldn’t get them to function reliably.

Adding to the complexity, standard female-to-female jumper wires were not provided, requiring us to crimp the connectors ourselves. This added an additional layer of effort and time to an already challenging setup.

Faced with these issues, we decided to pivot, replacing the serial servo with stepper motors. This required modifying the chassis to meet torque requirements.

On the other end, the mechanical structure was partially ready and waiting for the Serial Servo to be mounted.

After the chassis was assembled, it became evident that it was originally designed to require a serial servo to meet the torque requirements. However, since we couldn’t get the serial servos working, we had to modify the chassis to ensure it could operate within the torque limits provided by the stepper motors. This modification was crucial to maintain the robot’s functionality while adapting to the available components.

With no pre-existing examples to guide us, we relied entirely on datasheets, schematics, and our problem-solving skills to decipher every crucial detail. This process added another layer of complexity but was essential to ensuring the motors functioned as intended.

By the end of Day 01, the base of the robot was operational, and we managed to rotate it within the final five minutes. The buzzer signaled the end of the day’s work, marking a small but satisfying milestone.

Kinematics & Integration

We started Day 02 by developing the GUI and software to control all the motors, focusing on creating an intuitive interface for seamless operation. This required synchronizing motor commands with the system's real-time behavior to ensure smooth functionality.

And parallelly, we worked on developing the kinematics of the robot, diving into calculations to determine the relationships between joint angles and end-effector positions.

Thanks to Prof. Venkatarangan MJ 's course, and brush-up just before the LAM Research Challenge, we were able workout the kinematics with ease. It was finally time for us to implement the Kinematics in software. Seemed simple, but another small tweak in the mechanical arrangement to get the torque requirements threw the kinematics out of the window.

It was time for us to get the robot moving without implementing the kinematics using brute-force approach.

We then determined the position of each CD using brute-force approach and implemented that on the software, to get the bot to move the CD from one rack to another.

By the end of the 2nd business day as the buzzer went off, we were finally able to lift and place wafers from one rack to another, completing the problem statement.