From d669982a497fcc5f323acf15cc840b8519bd68d0 Mon Sep 17 00:00:00 2001
From: josh <102478723+realjoshuau@users.noreply.github.com>
Date: Tue, 8 Oct 2024 20:05:09 -0700
Subject: [PATCH] Fix small typo in mechanical-vs-software-solutions.tex (#24)

---
 .../application-advice/mechanical-vs-software-solutions.tex     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fundamentals-of-control-theory/application-advice/mechanical-vs-software-solutions.tex b/fundamentals-of-control-theory/application-advice/mechanical-vs-software-solutions.tex
index a4508c2..3a611a7 100644
--- a/fundamentals-of-control-theory/application-advice/mechanical-vs-software-solutions.tex
+++ b/fundamentals-of-control-theory/application-advice/mechanical-vs-software-solutions.tex
@@ -6,7 +6,7 @@ \section{Mechanical vs software solutions}
 building a robot, but we often allocate just two days for software testing.
 Despite this, teams still field competitive robots, which is a testament to how
 simple and easy to use the FRC software ecosystem is nowadays. Focus on a
-reliabile mechanical design first because a good mechanical design can succeed
+reliable mechanical design first because a good mechanical design can succeed
 with simple software, but the robot can't succeed with unreliable hardware.
 
 The solution to a design problem may be a tradeoff between mechanical and