Vladislav Pomogaev

Engineering Graduate – VE7ZAH

Admiral Trackbar, winner of the Star Wars autonomous robot challenge!

Admiral Trackbar is an autonomous robot that navigates using 3D printed treads, avoids detection by detecting infrared signals, and rescues Ewoks through servo powered arms. It was build by a team of four (Chuan Du, Forbes Choy, Vladimir Novakovic, and myself) as part of the course: ENPH 253, Introduction to Instrument Design.

The objective of ENPH 253 is to learn the basics of digital and analog electronics, control systems, C++ programming, project management, and instrument design. The content for the course is a series of lectures and mini-projects, but the practicum is the construction of a robot that completes an obstacle course.

At the end of the course all of the groups’ robots compete against each other to complete the course and score the most points. Our Admiral Trackbar robot won this competition and proved to be the defender of the galaxy!


Top down view of the competition surface with legend. The rotating platform is only triggered if the robot does not wait for the laser tripwire to be disabled near the archway. The zip-line is a ~1″ diameter aluminum pipe that spans the diagonal of the competition surface.

The competition’s main objective is to “rescue” the ewoks and Chewie by using the robot to pick them up and return them to the robot’s starting location. The ewoks are worth less points than Chewie.

The major obstacles on the course is two 6″ gaps in the competition surface floor, a rotating platform triggered by an infrared tripwire, a narrow ledge, and a zip-line. The rules dictate that the robot should autonomously navigate this course without human intervention in less than 2 minutes.

Let me tell you, this competition is not easy. We only had about 3 months to design, implement, and test the robot, and the robot needed complete all of the objectives perfectly and return, otherwise no points are scored.


3D Model of the chassis. The two tank treads were 3D printed out of flexible TPU. A set of machined aluminum axles and roller bearings ensured smooth motion. The motors and gear reduction were chosen to provide maximum torque for the desired maximum speed. An adjustable motor mount allowed us to change the gear ratios later on. This model was later used to layout the rest of the mechanical components on the robot.

One of the first pieces of the robot that was designed was the chassis. We went with a tank-style tread design since it could easily cross the first gap, as well as the second gap on the track. The treads themselves were 3D printed out of flexible TPU, for which I did the CAD design using Onshape and AutoDesk Fusion 360. I also helped create the design and create the aluminum axles using a combination of lathe and manual mill, as well as laser-cut wheels, motor mount, and gear reduction mechanisms.

The first prototype was meant to test whether a tracked robot could bridge the gaps on the competition surface. As you can see, it’s construction is a bit crude…
We tried our best to cut down on the weight of the robot early on in order to increase linear and angular speed. We also optimized our gear ratios to give us the maximum speed for the given motors and competition surface.
Once we had a drivable chassis, we tested it manually on the competition surface under manual control. It performed well, but we still had a long ways to go. We were able to cross the first gap on the competition surface with no problems. The second gap required a running start.
Next, we added a forklift-style lift system for the basket. The idea here was to collect the ewoks with the robot in the basket and return just the basket via the zip-line.
Next we added a robotic arm to the front of the robot. We used a servo-motor with a gear reduction to give us the torque we needed to lift the ewoks. Here we are testing all of the features of the robot simultaneously to stress test the battery.
Once we had the arm and forklift set up on the robot, we started adding the sensors. We first added one IR sensor array on the bottom of the robot to allow us to follow tape on the competition surface.
In order to keep the weight of our robot down and to aid with further speed estimates and gearing calculations we decided to make a weight budget and try to keep the weight within a set objective.
Once we got some rough estimates for the weight, we moved onto specifying the motor. The motor was selected out of several candidates and geared to the appropriate ratio for the hills and inclines we would see on the competition surface.
Once we had built the chassis and recorded it’s linear and angular speeds we did a quick estimate for how fast we could complete the competition. Rules dictate that if we need to, we can restart in the middle of a 2 minute heat. However, the clock would still be ticking and we would have less time to repeat our objectives.
After lots of testing on the competition surface we found that the single-armed robot design could be improved upon. Orienting the robot to face the ewok perfectly and not knock the ewoks over was difficult. We refined our design by creating two arms that would “scoop” the robots up by their feet. Placing these arms on the sides of the robot would allow us to simply drive by on our pre-programmed path marked by tape and not have to deviate.
This is the final iteration of the robot. We have gone away with the zip-line mechanism and changed our arm design. The objective now was to reliably return some, but not all of the ewoks by simply picking them up, placing them in the basket, and returning home. This worked out in our favor because our setup was extremely reliable and consistent, which eventually translated into the most points out of all the teams.


The main electrical systems for the robot hinge around a Bluepill; an Arduino-nano-like clone utilizing the STM32F-series chips. The main board we developed had a plethora of connectors and features, as well as some serious EMI filtering for power that allowed us to quickly iterate and add new features to the robot as needed.
For the electrical system we constructed a power budget to identify major uses of power and to specify the power converters and power rails required. We used several converters on the robot, including a linear regulator on the Bluepill to power all of the components. We used a single battery for powering the system. We calculated the runtime of the robot to be around 22 min under worst-case conditions.
The pin-out of the Bluepill was laid out on a spreadsheet before the soldering of the main board. We identified and resolved any timer conflicts using this document.
We used our custom-designed IR sensor arrays to detect taped features on the competition surface. These arrays have an on-board ADC that senses the signals coming off IR receivers. The ADC is accessible through I2C, and has two connections on the back for redundancy and daisy-chaining.

Two of my main responsibilities was to design the IR sensor arrays that were used to position our robot, and to design the main motherboard (we would add a second board later to expand our IO). The main board featured a 5V regulator, an STM32 development board, and a collection of JST-style connectors that would connect the main board to other peripherals. This main board was made on a perfboard, so we could iterate and change the design as necessary.


Lastly, we needed to write code that would allow the robot to complete the course. The code was written using C++ using the Arduino framework in the PlatformIO IDE. It was mostly a collection of classes, algorithms, and loops that enable us to complete small parts of the track, and by running these small parts together we were able to complete the much larger objective.

Happy rescued ewoks!