As the hardware systems lead for Case Western Reserve University’s Baja SAE team, CWRU Motorsports, I’ve learned a ton about hardware development, and especially how to create a lean, efficient team out of people who may not have experience in the field of engineering. There are a few tricks to this that I thought I would share, and that might prove useful to others.
First, Baja is a resource constrained scenario. When I was an intern at Asensus Surgical, one of the things my boss Dustin instilled in me is the value of developing hardware in the service of software. Because software is so much more flexible than hardware (a revision comes with practically zero cost), designing hardware that provides ample flexibility for whatever software lies on top of it is key to ensuring a quick turnaround on a prototype.
What does this mean in terms of PCBAs, harnesses, and assemblies then? Basically, the key to a good first rev is bloat, funnily enough. In a world like Baja where you might only get two spins of a board before you have to compete, throwing as much as possible at the wall and seeing what sticks is a surprisingly effective strategy in building a system that works. You can always go back and delete parts that you don’t need in later revisions.
In the domain of software, the trick is minimizing barrier to entry, and maximizing eyes. Firmware for our boards is frequently written in days, not months, which means we need a way to go fast. For this reason, we frequently do things that are considered “no-nos” in many embedded situations. One of the things we do the most that I personally think could get the most flack from the community is heavily rely on C++. Every piece of firmware that ran on the 2023 car was written in C++, as it provides many features that speed up development for our applications. C++ is also much more friendly to the CWRU Computer Science/Engineering crowd. While CWRU does not teach C++ in introductory classes, the object-oriented nature of C++ is more familiar to students with Java experience than C’s procedural programming.
Second, as a leader of a student team you have to ensure that every project you give out is a learning experience. Even students that come in knowing about PCB design or embedded software still don’t know how your organization does these things, so designing projects that lead into your workflow as a team is a helpful step of onboarding. Providing learning experiences that match a student’s comfort level is also important. I remember tasking a new member with figuring out everything they could about logic-level shifting. It seems like a menial task to anyone that has been doing embedded, but to a first year college student, that’s a decent sized task. They came away knowing a ton about logic levels, and even picked up some details about signal bandwidth and high speed design.
Finally, the most important thing I think any student leader can do is really care about their team. I will admit I get caught up in the engineering far too often as someone who is supposed to be “management”, but making sure that your team members know what they’re supposed to be doing, enjoy what they’re doing, and feel like they can come to you with issues they have whether they be about engineering or the team is critical to having a sustainable team, and a well functioning team.