Project Eragon Episode 1
You know what sounds pretty cool? Building a robot. From concept to full build, no fanfare or what-ifs, let’s give it a shot. To begin we are going to the drawing board using a top-down approach and work our way to first-principles.
Welcome to SzaberDesign
First, we need to do what has been done for every project on this site, and especially of this magnitude.
Defining the Build.
We need a few things here to get a defined build. The best policy is with minimal yet contextually rich words exactly what we want to accomplish. No more, no less.
- Bipedalism
- Wireless control
A few words with big implications but we can work with this as a baseline to prevent scope creep. So let’s begin forming the first one.
BIPEDALISM
- The bodily attribute of being bipedal; having two feet
This mechanic, we deal with everyday on our own two feet, is the most familiar and natural. Surprisingly, it is far more complicated than the in-grained muscle memory that we have about it. For example, we actually fall in order to move forward. There are pros and cons to structuring a robot this way.
Pros
- Releases upper limbs for multitasking
- Elevated FOV
Cons
- Higher center of gravity (Increases tipping force ratio)
- One leg injury ruins locomotion
- Weight and strain focused on lower legs
For our robot these are quite intimidating, but still they can be overcome.
So let’s set some helpful constraints here to help us achieve this build goal. Each of these constraints needs to help defeat or mitigate some of these Cons.
Con: Higher Center of Gravity
- We can mitigate by lowering the max height of the robot to 1 foot or 30 centimeters. A smaller robot naturally has a lower center of gravity and our ratio of tipping force, the base of support and other balancing factors are heavily in our favor.
Con: Leg Injury
- Limit traversal range and terrain adaptability. So our terrain will be the closest thing we have and only that, about quarter inch high carpet. And our target range will be the standard house square footage ~1800.
- This hurts to put in, but tradeoffs need to be done in order to limit the scope creep, next build we can reconsider
Con: Leg Strain
- Weight and dynamic forces compared to servo and material strength. For this case, let’s implement a smaller thinner figure, we don’t need something massive, we just need enough movement to gather data. So, our build material should be in consideration of this.
- We have a few options, from metal cutouts to PLA/PETG printed parts. The most modular pieces should be printed, the legs need to consider metal for strength. Our main factor, we need to build for weight. Once we get craft our BOM we can understand what weight-class our robot falls into and start adjusting strength-to-weight ratios.
All together:
- 1 foot/30 cm max height
- .25 inch/.64 cm carpet terrain
- Build for weight tolerance
WIRELESS CONTROL
Our next build requirement of wireless control comes with baggage. This is a multi-step problem with potentially many sub-categories and electronic devices. For this build, we will limit to just two main devices and a few sub-components to ensure power and safety. Specifically there will be two main controllers. A device to set the priority objective, send out commands to the robot and receive sensor data. And second, a device bolted on the robot to receive commands, move servos and send back sensor data. A split architecture of two systems, the commander and the soldier.
Commander
We need to break down the commander like our original build design, specific low word count contextual constraints that we can build software around.
- Accomplish Objective
- Communication Package
- Compute
Unfortunately, detailing these aspects of the Commander will need to have its own writeup in Episode 2 i.e. API formatting, hardware, safety protocols and more. So for now we will move on by considering the Commander as a black box that does exactly what we want: setting the objective, computing the inputs and sending out the commands.
Soldier
A low-intelligence system that reads sensors at millisecond speeds and can transmit that information just as quickly to the Commander. A microcontroller is the perfect candidate for this operation and includes a small form factor. Another aspect of the microcontroller is that it is by definition exactly the type of machine we need to process and implement commands from the Commander.
The Soldier is a State-Machine
Its code will consist of:
- states, transitions and actions.
For example, the Commander will transmit the command “Forward” and the Soldier will read this as a trigger to transition its state from standing to now walking forward and begin looping through the action of moving the servos in a pre-determined stepping motion forward. Keeping with this same methodology, we can implement separate triggers for other important interrupts i.e. safety protocols or settings adjustments.
Likewise with the Commander, we will expand on the Soldier in episode 3 where we can discuss the hardware and other components to make it run. For now, the Soldier will also be a black box but with an added running state of either “Stop” or “Forward”.
Conclusion
Overall, this is a great start to Project Eragon. We identified the core concept of the build, Bipedalism and Wireless Control. Two difficult problems further contextualized to better understand what each of the requirements entails. For bipedalism, pros and cons were analyzed and constraints, such as the 1 foot height requirement, placed to better mitigate the challenge of implementing them. For wireless control, we created the Commander and the Soldier, two devices that for now are simply black boxes that communicate with each other but with a defined role in the system. In conclusion, there is more to unpack with this build, but as long as we can keep pace Project Eragon should be walking on its own two feet hopefully in the near future.
