Lessons in Constraints - by Greg Tidanian

Embedded Build Log

SubscribeSign in

Lessons in Constraints<br>Finding the balance of constraints and freedom in engineering

Greg Tidanian<br>Jul 20, 2026

Share

David Epstein is an author who wrote Range: Why Generalists Triumph in a Specialized World - which is a book I’ve recommended and gifted to several engineers as I’ve felt the lessons are so applicable to engineers particularly at the beginning of their career and even during their education.<br>It’s also a book that’s largely inspired and influenced my own writing.<br>Recently, David Epstein released a book called: Inside the Box: How Constraints Make Us Better and from reading about it’s contents during it’s pre-release, I decided to write about my experience with constraints in engineering, in particular during my own university education.

Thanks for reading Base60! Subscribe for free to receive new posts and support my work.

Subscribe

The earliest lesson on the impact of constraints vs freedom in engineering came during a 2nd year university group project.<br>The project, in our Mechanical Engineering course, required us to design and build up to 2 robots to complete a lunar mission-style challenge.<br>The Challenge

Our challenge was to build up to two wheel-based robots.<br>They needed to transport some cylindrical mini barrels (~10cm diameter and ~20cm height) from one area of the desktop setup to another.<br>Some objects needed to be rotated, while others could be dragged or picked up to a specific location - and the end-location of different objects dictated how many points we gained.<br>Budget

Each team was given a budge of around £100 in addition to basic hardware given to us such as:<br>Wheels

Microcontroller development kit

Motorcontroller

In addition to our budget however, we were advised to reach out to component suppliers and to ask for sponsorships in the region of a couple of hundred pounds .<br>Hilariously, supplier we requested sponsorship from confused our project for an ambitious masters project with much larger costs and we secured £1000.<br>PS - when realising the projects were confused we insisted on changing the offer, but as they already issued the account they insisted on keeping it the same as they were happy to issue the same amount!<br>Our Approach

As young and green engineers - we opted to take the opportunity to maximise how much we could learn from this unlikely scenario.<br>We decided to buy a robotic arm that could be used to pick up and transport any object we needed to and in theory score as many points as we wanted.<br>It was heavy, but could move in multiple degrees of freedom - designing an arm like this would have been out of scope for our timelines and ability at the time, so we saw it as a major advantage in our competition.<br>Hardly any ingenuity felt necessary to apply. It was a massive robotic arm drilled onto a base with wheels.<br>For our second robot, we opted for a much smaller and simpler design with pincer-style grips controlled by a stepper motor and made using laser cut acrylic. More thought went into the second robot, with the emphasis on being as simple and reliable as possible.

Arduino Tinkerkit Braccio Robot T050000<br>The strategy now became:<br>Use the larger robot with the robotic arm to execute the difficult tasks, scoring the most points.

Use the smaller simpler robot with pincer-grips to carry the tasks which required the least complex movements , scoring reliably and consistently.

Outcome

Our larger robotic arm system struggled for several reasons:<br>More dexterity meant more complex programming required (pre-LLM’s)

More dexterity meant margins for error were even lower for positional accuracy

The weight distribution of the arm changing based on it’s relative position resulted in it falling consistently

The mass of the arm meant it had to travel slowly around the course - having a lower ceiling for potential points scored

Our small pincer robot was consistent and more reliable for other reasons:<br>The pincers didn’t need as high of precision in order to capture objects

It was smaller, more lightweight and had a lower center of gravity - meaning it could travel faster

It was much quicker to program as well as iterate on its accuracy

Its task was much less complex and had less opportunities to go wrong

You can guess which robot scored more points - the smaller pincer one massively out performed our larger arm robot.<br>Lessons for Product Development

David Epstein talks about how Tony Fadell, the co-creator of the iPod, began his career at General Magic , a company founded by former Apple employees with significant resources.<br>Their goal was to create technology ambitious for their time, and building a lot of the hardware from scratch.<br>The company’s sales fell way below expected, for several reasons - in particular the timing of product releases did not align with demand.<br>Tony Fadell then moved to Apple and his projects became much more constrained in timelines , encouraging him to...