Unibots 2026

I'm currently working on a robot for the upcoming Unibots 2026 competition.

The aim of this competition is to collect orange ping pong balls and small magnetic ball bearings. After collection, you get points for scoring into a collection area, which is located around the wall of the arena. The robot must be autonomous, and is allowed to be up to 20cm x 20cm x 20cm in size, the competition runs for 3 minutes.

Challenges

This is the second year I'm forming a team and design to compete. There are some important changes from last year we've had to adapt from:

• New Scoring System
Last Year, points were awarded for catching ping pong balls, a sphero and rugby balls within the body of the robot. This year, it's changed to just focus on ping pong balls and small ferromagnetic steel ball bearings. This changes the competition because we can now focus on optimising ball size for smaller objects, and makes the design of the robot more compact. However, we also have to add a drop-off mechanism to release the balls in the collection area, which adds complexity to the design as it is 15cm above ground.
• New Robot Size Constraints
The robot must now fit within a 20cm x 20cm x 20cm box, which is smaller than last year's constraints (30x30x30). This means we have to be more efficient with our design and component placement, and it also limits the size of the collection mechanism we can use.
• Streaming Ban
Last year, we streamed video from a raspberry pi camera over to a laptop, which ran the image processing and logic decisions. Then the laptop would send commands back to the pi for it to execute movement. This year, streaming is not allowed, so we have to run all the processing on the robot itself. This means we have to be more efficient with our code and use a more powerful microcontroller or single-board computer to handle the processing (or get creative, see next).

Streaming Ban

Our general approach has been to minimise components and cost. Last year, we had a Pi5 which was expensive. It took a lot of work to get working and we accidently fried the GPIO. This year, a member of one of our society teams (Adam) showed me that he had managed to run NCNN YOLO on the Pi-5, with much better results than last year. This got me thinking, what if we just ran it on a mobile phone instead? We could use a cheap android phone for the processing, and then send commands to an ESP32 microcontroller over bluetooth/wifi(udp) to control the motors. This would be much cheaper than using a Pi5, and also more powerful than using a microcontroller alone. We could also use the phone's camera for image processing, which would simplify the design of the robot and reduce the number of components we need to use.

Hence, we're currently building this approach:

Our plan is to have a mobile phone, running YOLO (via NCNN - thanks tencent! <3) and a small websocket/http web server. Then we have an ESP32 microcontroller which connects to the phone over wifi and receives commands to control the motors. We can also leverage the pose gyroscope and accelerometer of the mobile phone in our processing.

The HTTP Server hosts a small react app which allows us to debug the robot remotely from a laptop. Commands are sent via a websocket from phone<=>laptop, the camera YOLO feed is also streamed.

The react app lets us write Javascript code in a client-side editor such as monaco. We can then submit this code over to the phone: When the phone recieves it, it will interpret-evalute the code to Java and run it on the phone itself. We will expose a small API Javascript library to chat with the Java driver built into the android app. In this way, we are not running any code remotely during operation of the robot. All processing and logic is happening on the mobile phone mounted on the bot, but we can quickly iteratively prototype our code remotely on a laptop

This is a similar approach to how REV Robotics runs their control system for their FIRST Tech Challenge robotics competition (I participated in 2023, and volunteered in 2025), where they allow teams to write code on a laptop web browser in Java or block-based languages which run on a control hub onboard the robot.

This architecture allows a lot of flexibility in our design, and also allows us to leverage the power of mobile phones for image processing, which is much more efficient than using a microcontroller or single-board computer alone. It also allows us to easily debug and iterate on our code remotely, which is a huge advantage during testing and development.

This sounds great, how do we make it? Well, the legends over at tencent have us sorted. The amazing nihui on Github has made this repo github.com/nihui/ncnn-android-yolo11. This repo is an Android app that runs YOLO via NCNN. Works like a charm. NCNN is a method of optimising models to run on mobile phones, perfect for our use case.

I forked the repo and got started! You can find my version here (github.com/dylankainth/ncnn-android-yolo11), where as of 08/02/2026 I've currently got it set up as a remote control with camera streaming. Next steps are to implement the Javascript interpreter and state saving of js files.

New Scoring System

The storage/dropping/collecting mechanism is primarily an engineering/CAD issue. My solution this far this year has been to use a lift.

I sat with our teams at KCL Electronics and Robotics Societies and did design reviews for initial ideas. Ideas such as an archimedes screw, a conveyor belt and a scooper were considered. Some teams have chosen to take those approaches, I felt a lift was best

Lifts do have their technical challenges:

• How can we fit as many balls on the lift at a time as possible? The more we can fit, the less times we spend going back and forth

I made the lift take up an entire middle section of the robot. We squeezed components on the left and right sidepods with the motors. This gives us a huge area to pull up balls



Huge Lift, Sidepod with electronics.

• How can we make sure our lift doesn't exceed the dimensions of 30x30x30 ?(max expanded limits)

For rack-and-pinion style lifts like mine, you need to make the rack as long as possible within the limits. Then, you need to place the pinion as high as possible on the bot. This gives it the maxmimum vertical reach. It's really tight, but we make it work in 30x30x30.

• How can we make sure the lift is stable and doesn't tip over when it's fully loaded?

We make sure the centre of gravity is low, and that we have a wide base to prevent tipping.



Ball on lift!
Rubber band, when at the right height, stops balls falling forwards out the bot.

• How can we actually move the lift up and down?

You can use a cable driven lift, or a scissor lift, but I opted for a rack and pinion style lift. It's simple, and we can easily 3D print the rack and pinion gears. We have two motors working in parallel to drive the pinion, which gives us more torque to lift the weight of the balls.



Rack and Pininon lift, one of two sides

Manufacturing

3D-printed it all. Mostly on a Bambu-A1, but some parts on a Prusa Mini

Did all the design in Fusion360. I made sure to add 20x20mm spacing of 3mm holes in most components to allow standardised mountings later.

It's obvious, but making an assembly of your design is super super useful.

Electronics

The ESP32 is the go-to for our control system, but what about the other components?

We used Li-ion 3s/4s cells last year, but I had a bad experience because we just didn't know how to look after them properly. We overdischarged it, and then it would not charge up afterwards. Battery safety is really important, especially because they are explosive. So, this year, We've opted to use 10xNiMH AA's.

Why? Well, they they might be a bit bulky, but they are dead simple to use. They are meant for consumers, not hobbyists, therefore they are really hard to break. If they do break, they are the only type of rechargables that I know of that can be bought at a local hardwareish store in the UK such as Argos or Amazon-Next-Day. Chargers can also be bought at most supermarkets, making it super simple to fix if something goes wrong. They are also quite affordable.

For motors, we went with the good-and-trusty Yellow TT-motors in 1:48 configuration. They are just ol' reliable, and reasonable size. Adapters for mecanum wheels and these motors is a standardised product, which is much easier than when I was cutting steel rods last year after our 3d-printed parts snapped.

In terms of motor driver, we started with the L298N. As good as it is, we felt a few extra volts would be good for our motors. The H-bridge is meh on L298N, good for 80% of use cases, but we definitely felt the weight of the bot pushed us into that last 20%. So, I swapped them out for IBT_2's. Note, one L298N can supply two motors, whereas one IBT_2 can only supply one. Therefore, the wiring got a bit bigger and messy, but I sorted it out.

I was able to combine the two lift motors into one IBT_2, because they are in parallel and doing the same thing. So that saved us a bit of space and money. The drive motors are on separate IBT_2's for better control and reliability.

I also added a buck converter to power the esp32 from battery.

Summary and Next Steps

Overall, I'm really happy with our design and approach for this year's Unibots competition. The use of a mobile phone for processing is a game-changer, and I think it will give us a significant advantage in terms of performance and flexibility. The lift mechanism is also a solid choice for our collection strategy, and I'm confident it will be effective in the competition.

Next steps for us are to finish the implementation of the phone's software, and then to start testing and iterating on our design. I'd love to also fine tune YOLO for Orange Balls, but I'll leave that for Shreyas (teammate) to do. We have a lot of work to do, but I'm excited to see how it all comes together in the end!