Lessons in Constraints
Finding the balance of constraints and freedom in engineering
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.
It’s also a book that’s largely inspired and influenced my own writing.
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.
The earliest lesson on the impact of constraints vs freedom in engineering came during a 2nd year university group project.
The project, in our Mechanical Engineering course, required us to design and build up to 2 robots to complete a lunar mission-style challenge.
The Challenge
Our challenge was to build up to two wheel-based robots.
They needed to transport some cylindrical mini barrels (~10cm diameter and ~20cm height) from one area of the desktop setup to another.
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.
Budget
Each team was given a budge of around £100 in addition to basic hardware given to us such as:
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.
Hilariously, supplier we requested sponsorship from confused our project for an ambitious masters project with much larger costs and we secured £1000.
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!
Our Approach
As young and green engineers - we opted to take the opportunity to maximise how much we could learn from this unlikely scenario.
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.
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.
Hardly any ingenuity felt necessary to apply. It was a massive robotic arm drilled onto a base with wheels.
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.
The strategy now became:
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:
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:
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.
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.
Their goal was to create technology ambitious for their time, and building a lot of the hardware from scratch.
The company’s sales fell way below expected, for several reasons - in particular the timing of product releases did not align with demand.
Tony Fadell then moved to Apple and his projects became much more constrained in timelines, encouraging him to leverage hardware that already worked as part of his iPod engineering designs.
Lessons for Outsourcing Work
Several startups will make the decision to outsource technical work in the early stages to consultancies and design houses.
A potential time-sink in projects is when consultancies hand projects back to the clients. The time-sinks can be a result of:
Technical literacy beign outsourced and clients have friction with taking the work further
Design intent is not always documented
Toolchain setups are often overlooked and cause delays to client teams when taking the work over
A good consultancy deliverable comes downstream from well-thought out technical requirements set by the client and consultants.
Us buying a robotic arm in many respects outsourced a lot of our technical literacy without any technical requirements specific to our task.
Our smaller robot was much less ambitious in what it needed to achieve, but it was reliable because it carried out it’s task and nothing else. We also designed it bespoke to the tasks it needed to do.
For us, it felt as though as soon as we received the arm, instead of investing our time in designing the mechanism, we were learning how to set it up, hoping it would save us time down the road, or perform better when complete.
Reflection
The project underperforming cannot be blamed solely on the budget. The £1000 could have been used much more wisely and delivered a better performing outcome.
For example we could have spent the money on:
High quality troubleshooting equipment such as multimeters and logic analysers
Higher volumes of components than required for the design, to account for spares
Resistor and capacitor kits, for testing, prototyping and troubleshooting
Nearly a decade later, a mature reflection on the project after lived experience in other projects is that much of the bottlenecks in projects come from troubleshooting, debugging handing work over.
All of our issues in the project came downstream from not having monetary constraints and falsely identifying the design phase as our bottleneck.