There’s an idea in video game development called “scope-creep“. When you work on a project, especially a long-term project, if you’re inexperienced, you tend to go into the project with far greater expectations than are realistic. It’s a joke online that many people’s first attempts at video game development are “MMO RPGs” with “infinite worlds” and a billion NPCs or some other equally insane dream.

It’s okay to dream (and should be encouraged, even), but it’s also important to find that achievable, realistic balance. Then, once you’ve set yourself a project, do not compound your work by adding more and more as new ideas spring into your head.

In video game terms, this means that you might start out intending to make a simple 2D platformer, but then you decide to add a scoring system, then a crafting system, then a combat system, then multiplayer, and collectibles and Sloto Cash Bonuses and on and on and on until your simple game is too large for you to handle and collapses under its own weight. In other words, the scope has crept up beyond your original intent.

This idea applies to far more than just video games, of course. I’m an engineering student at university, and a project requires me to design and build a mechanical/electrical device of some kind. My project partner and I initially went with a card dealing machine, but that was rejected because a student had done that exact same project as the previous idea. Thbbthh.

Anyway, the project we ended up going with was a robot-toolbox-table that can follow a technician around while he works and lift the tools up to about shoulder height. Sounds simple enough, right?

It turns out that this idea was infinitely more complex than the card dealing robot ever was, even if we had intended to run with the idea that would also shuffle the cards too. So now we have this big, bulky robot that we have to design, that has to do all these things, and oh my gawd, what the hell have we gotten ourselves into?

Navigation, Tracking, and Pathfinding

It seemed fairly obvious that the primary problem we had to solve was the issue of how this robot would move from point A to B to C. We also knew that proper pathfinding would be above and beyond what either of us cared to develop (that’s the kind of problem companies like TESLA works on, so yeah- it’s a bit beyond our capabilities). Instead, our robot would pick a destination and drive in a straight line towards it, only stopping if there’s an obstruction and then wait for help in that instance.

We reasoned that the physical movement would be done by motors and wheels. Easy. However, how would the robot decide where to go? The robot had to be capable of following a person. How could we college students, with only a couple months of development time, pull this off?

Our first idea was some kind of radio tag. You, like the tracking devices you always see in movies. It turns out that those are a lot more sophisticated than you might think. GPS modules can get expensive if you want precision indoors. Trying to use a cell phone to feed GPS data to our controller (which would either be a Rasberry Pi or an Arduino) was suddenly getting very complex- bam, scope creep.

Our next idea was Bluetooth tracking. If we’re connecting to the phone anyway, maybe there’s a way to use Bluetooth to feed position data from a phone to our robot? Well, while that’s certainly possible, every method we found online relies on beacons set up around a room. For a robot that we want to be able to plop just about anywhere, we can’t have it be limited by having to set up beacons within the room first.

Our third idea was RFID chips. There’s an article from MIT that talked about how they managed to use such chips for tracking position data. Sounds perfect! The problem was that the range was limited to about 20 cm. Also, it took MIT researchers to get it done.

Fearing the worst, we realized that we were way overthinking this whole thing from the get-go. Perhaps there was a simple sensor that most Arduinos come with anyway that could somehow track a person?

Now following this train of thought, we began looking at Ultrasound sensors. They work by emitting a high pitched noise and receiving the returning echo. Echolocation, in other words. Okay! Such a sensor is good at tracking distance but not so good at identifying position. What’s worse, it can’t differentiate between objects. A wall and a person and a chair look identical to such a sensor. So while it’ll still be useful to have such sensors, it doesn’t solve our problem.

Next was Infrared Sensors. They’re pretty cool. As one might guess, they can be used to spot sources of infrared light. If we put an infrared source of light on our technician, as a keyfob or whatever, the robot could follow THAT around, and bam! Problem solved! Except for one tiny thing… it wouldn’t be able to differentiate between sources of infrared light. Which could be okay if it weren’t for the giant, flaming infrared light source that ascends into the sky every day. Agh.

Last but not least was a Color Sensor. That’s when it clicked, and the angel’s choir started singing, and lightbulbs turned on. The robot could be programmed to follow a specific COLOR not commonly found in nature. A color like that of an engineer’s safety vest, for instance. Badda-bing, Badda-boom, we’ve got a method to follow a person that doesn’t require sophisticated hardware or software!

Up, Up, and Away!

The second biggest problem we had to solve was figuring out how to lift the table up to the desired height we wanted. At first, we just assumed that we would use pistons, easy peasy lemon squeezy. The problem? We need to lift our table about a meter up, and there aren’t many pistons that can extend that far, at least not within our budget for this project.

The second idea was to use pulleys and motors. Not ideal since it would require a frame that already reaches the height we’d want. Again, that wouldn’t be the end of the world, but it irked me that we wouldn’t have a slim profile when the robot wasn’t extended.

My project partner then suggested we do something like a digger arm. On digger trucks, they have the larger scooping arm controlled by hydraulic pistons, but they only push on the arm right near the axis. This stroke of ingenuity would mean that we could use smaller pistons to achieve lift! Brilliant! Now, how the heck do we apply it to OUR project?

That’s when I suggested that we do something like a scissor lift. You know those carts that construction workers use to work on buildings, several stories up? Yeah, those are scissor lifts. They’re extremely space-efficient, use pistons, but can achieve great heights without too many sophisticated parts. Waaaay better and more applicable to our project! But, sigh, that’s so many parts that we’d have to make ourselves. Lots of interlocked rods and whatnot…

I was talking about these issues with my dad when he suggested the most dad-thing he could have suggested: Why not use a scissor jack?

For those of you who have never worked on cars before (like me), a scissor jack is a device for lifting up the car to work underneath. It’s like a diamond shape of four metal rods, with a big screw that crosses the diagonal horizontally. With a motor to spin the screw, bam! We’ve got a lifting/lowing system that uses very few parts that can be scaled to the height we need! Now we’re talking!

Reducing our Scope

We would have never gotten to that idea if we hadn’t known from the get-go what our scope was in the first place. If we had simply decided to run with our first idea, we would have been in way over our head and ended up floundering on this otherwise immensely vital project. This planning stage required to break down our project in several smaller categories:

First, we had to break down each of the logistical problems that needed solving for the robot. This included the navigation, the lifting/lowering of the table, and the tracking.

Then, we had to break each of these down even further. For the tracking, we had to think hard about exactly the kind of functionality we wanted. What does our robot have to track? How precisely does it need to be done? At what distance? Are our ideas actually practical for us to pull off?

This is a vital step for any long-term project. The more of these questions that you can figure out on paper, the more time and money you will save in actually implementing them. Each of the ideas above could have easily led us down a rabbit hole of expenditure and overly ambitious ideas that might not have worked in the first place.

Long story short, always know your scope, and never let it creep away from you!