Team: #4, StrikeCycle, by Ved Patel and Anvay Ajmera
Abstract: StrikeCycle is a robotic pin-resetting system that is able to change the most difficult part of bowling automation: getting the pins back after a throw! Instead of simply on large mechanical sweepers or fixed industrial machinery, to account for a global audience who wants to have a bowling system on a table, we use Hugging Face's LeRobot robotic arm trained with smolVLA to get individual pins from a pin holder and accurately place them back into their corresponding positions on the lane.
- Our main mission is to utonomously reset bowling pins after a player’s throw by picking up individual pins from a holder and placing them precisely at specific locations on the lane. Aside from the obvious application in bowling, StrikeCycle can be used in numerous fields, including but not limited to:
- Translating hazardous/sensitive equipment
- Resetting objects in interactive environments (arcades, training setups, labs)
- Robotic assistance in constrained spaces where large automation is impractical
- We redesigned the bowling pins themselves to be robot-friendly while preserving the visual and functional aspects of the game.
Each pin is optimized for stable grasping, reorientation, and placement, minimizing tipping and placement failures.
Instead of sweeping fallen pins indiscriminately, the robot performs individual object manipulation, making the reset process interpretable and engaging for spectators.
.
- Teleoperation / Dataset capture
(there are videos here, if its not loading look in assets)
- How generalizable is your implementation across tasks or environments?
- Our model is very generializable. With the same setup, you can transport any object the same way we did. This can include vials, boxes, and even radioactive substances. This can be done simply by downloading our model and finetuning on a specific domain.
- Flexibility and adaptability of the solution
- Even with slight deviations of the starting position and ending position, the model is able to learn to correct for these errors. An example of this is turning a pin on the ground slightly. Turning it would cause the model to turn a little bit more to consempate.
- Types of commands or interfaces needed to control the robot
- To control the robot with AI, you need to download lerobot and run a simple inference command. This simple solution is enough to run the core of the robot, this is because our robot runs nativally on lerobot model implementations. Simple ESP32 connections are needed to get the button, screen, buzzer, and ultrasonic sensors to work but they're not required.
For example, you can provide links to:
This is the directory tree of this repo, you need to fill in the mission directory with your submission details.
AMD_Robotics_Hackathon_2025_ProjectTemplate-main/
├── README.md
└── mission
├── code
│ └──
└── wandb
└──
ur training job>
b>
The latest-run is generated by wandb for your training job. Please copy it into the wandb sub directory of you Hackathon Repo.
The whole dir of latest-run will look like below:
$ tree outputs/train/smolvla_so101_2cube_30k_steps/wandb/
outputs/train/smolvla_so101_2cube_30k_steps/wandb/
├── debug-internal.log -> run-20251029_063411-tz1cpo59/logs/debug-internal.log
├── debug.log -> run-20251029_063411-tz1cpo59/logs/debug.log
├── latest-run -> run-20251029_063411-tz1cpo59
└── run-20251029_063411-tz1cpo59
├── files
│ ├── config.yaml
│ ├── output.log
│ ├── requirements.txt
│ ├── wandb-metadata.json
│ └── wandb-summary.json
├── logs
│ ├── debug-core.log -> /dataset/.cache/wandb/logs/core-debug-20251029_063411.log
│ ├── debug-internal.log
│ └── debug.log
├── run-tz1cpo59.wandb
└── tmp
└── code
g
├── run-tz1cpo59.wandb
└── tmp
└── code
└── code
NOTES
- The
latest-runis the soft link, please make sure to copy the real target directory it linked with all sub dirs and files. - Only provide (upload) the wandb of your last success pre-trained model for the Mission.