Ogrebot

Sadly I’m writing this years after I built this robot and the computer I did all the work and has all the files for this has been released into the abyss so I can’t provide good pictures or reference material. Apologies.

Ogrebot is the firefighting robot I built for the Trinity International Robotics Contest. I built V1 my junior year and v2 my senior year. Ogrebot was developed during a time I was learning a lot of about robotics, so the beginning and end robots are fundamentally different.

For the Trinity competition, the task is to build a robot that autonomously navigates a maze and detects and extinguishes fires in the form of candles. This is vaguely similar to the micromouse competitions which are semi popular these days.

V1 was designed entirely by me as a high school sophomore, so before you judge me too harshly for my poor engineering decisions, please take that into account. Before this project, the only CAD program I had ever used was OpenSCAD, a “CAD” project that you had to program all of your parts. I wanted to move to a real cad program so I decided to use Fusion360 for this project. The design featured a layered layout (and since ogres have layers…), with all the drive components on the base level, the second layer was exclusively sensors, the third was for main control and extinguishing, and the fourth was the handle/start electronics.

It was built this way for easy testing, repair and access. Our previous robot, boxbot (as the name suggests was just everything thrown into a box), was a rats nest of cables impossible to do any work on. Additionally if I wanted to test just the motors and driving I could undo everything and work on it from there.

V2 was not supposed to exist. V1 had some issues at competition due to a bunch of random bs. Sadly that’s just how robotics works, it’s just murpheys law taken to the extreme as there a bunch of complicated systems that work with each other in complicated ways. And as a bunch of high schoolers who though we were smart tried to do things the “right” way instead of a simple way. V2 became the bastard child of me (who had designed V1), and a younger student in the club. He wanted to build a robot that was done the right right way as if we were boston dynamics. I still think the robot he wanted to build would have been great but the issue is we held on to some stuff from v1 and some stuff from his robot which caused some issues. In this version we added a 2D spinning LIDAR sensor and we used custom brushless servo motors instead of brushed motors. So now our robot could go 30 mph. Cool! (but also useless). When testing in our schools lab, this robot worked great, we had incredibly precise sensor data and our motors were accurate to millimeters. However at the competition our raspberry pi which was struggling to handle the loads of sensor data and running ROS (which sucks on low end hardware), it didn’t matter if we built super cool motion control systems, dead reckoned encoder feedback, SLAM and Monte Carlo localization. Our pi literally died hours before the competition. This was obviously incredibly disappointing, but i’m still super proud of the robot and don’t regret our decision to go overboard in all those fancy buzzwords i just mentioned as I and my teammates learned an insane about “real” robotics that most high schoolers can’t say they had a chance to do.