Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

AER Resources

Anteater Electric Racing Logo


Welcome to the team! These pages are a rough guide to help you get started learning what you need to know when joining AER’s Electrical (PCB) or Embedded teams!

About Me

Hi! My name is Anushree Godbole, and I’m a Computer Engineering sophomore. This is going to be my second year at AER! I’m specifically part of the Electrical (PCB Design) team and the Embedded team.

Why I Made This Guide

I’ve compiled some of my learnings here in order to help out new joinees! I came in not knowing much about both PCB design or Embedded work, so I know it can be quite overwhelming to learn at times. I’m hoping this will be a good resource to get you a head start!

Happy reading! :)

PCB Resources

💡 Biggest takeaway: ASK QUESTIONS!!!

  • If you don’t understand something (no matter how small or seemingly insignificant), ask someone! The leads are always here to help!

  • Remember, everyone has to start somewhere! :)

How Do I Even Start?

  • Pick a board (RTM, BSPD, CCM, etc) and dive right in → no better way to figure stuff out than looking through the schematic for yourself

    • Learn the acronyms for the boards and what they stand for (you’re going to be hearing them A LOT)

  • Have AI explain things to you → can take screenshots of certain parts of schematics and have AI explain to you its functions

    • Make sure to ask it questions like:
      • Why did they choose xyz part?
      • What does xyz part do?
      • What is the purpose of xyz part?
      • Could xyz part be replaced by something better/easier? Why?
    • Aim to dig as deep as possible: any knowledge is good knowledge!
    • If anything seems confusing, make sure to verify with a peer/lead!

  • Look at old boards! → go to ECT and physically look at the old boards

    • How are they harnessed together?
    • How are they soldered? Are they through-hole or SMD? Why?
      • Are there any specific reasons why one type of soldering might be better than the other for the specific board?
    • Do there seem to be size constraints for the old boards?
    • What components on the board stick out to you/can you recognize?
    • What components are you seeing for the first time? → Ask someone about them!

  • I heavily emphasize that learning/looking into the Embedded code base will really help you understand the FUNCTION of the board itself

    • May not necessarily teach you the nitty gritty of why certain components were picked for certain boards, but it’s super important to understand what the board is trying to achieve in the first place
    • Easier to get the bigger picture if you understand how the code interacts with the hardware and how it’s rules compliant

  • Once you somewhat have a grasp on what your assigned/given board does, make a presentation on it (individually or with a partner)! Run through all parts of the schematic and explain its functions

    • My example
    • Once you have an idea of how the board works, make sure to read ALL of the rules related to that system
      • Ruleset
      • Understanding how the boards are rules compliant is super important to understanding why logic was implemented a certain way or why certain components were chosen
    • Present! You always learn/remember better by explaining to someone else

  • Now that you’re confident on how your board works, it’s time to brainstorm possible improvements. Make a presentation on ways you can possibly improve the given board

  • Now, rinse and repeat for the other boards!

General Tips

💡 Pro tip: READ THE DATASHEETS!

  • Especially helpful when you’re making boards: you need to know the details of the parts you’re using

  • They can tell you important information like:

    • Pinouts (Ex: Which pin is the Gate, Drain, and Source on a MOSFET?)
    • Recommended operating voltage and current
    • Typical applications in circuits
    • Other electrical characteristics

  • You don’t need to read the entire datasheet! Just start with the most relevant to what you’re working on

  • PCBs at AER are heavily tied to the embedded code, so it’s important to at least have a bit of background information on what the codebase looks like (not necessarily required, but I definitely found it helpful)

    • Detailed documentation on everything embedded
    • Follow the README in the repo to run and view the documentation locally (also further explained in the Embedded section of this guide)
    • Read through any important parts of the documentation that relate back to the boards/how they work

  • If you have more time, I’ve heard good things about this course by Altium

Embedded Resources

Git Basics

  • Git: a version control system that tracks changes to code and allows multiple people to collaborate on the same project

  • We mainly use GitHub (which is built around Git) to store all of our files

    • Allows us to see past changes, updated changes, and it’s easy to keep track of who changed what

  • Repository (repo): think of it like a container to store all of our car related files

    • Cloning a repository: when you want to make changes to a repository in an IDE, you’ll have to make a copy of that repository on your personal device (hence, cloning)
      • This allows you to make changes locally (on your device) before you publish those changes to GitHub for your collaborators to see

  • Branches: each repository has branches, and they allow you to make changes to code without changing the main source code

    • Each repo (by default) has a main branch, where the main source code is
    • Each new branch starts from the current state of the branch it’s created from (usually main)
    • You can make edits on the new branch and it won’t affect the code in the main branch, until you “merge” into main
    • Importance of branches: lets you change code without directly affecting the main code base, and is more easily undoable

  • Pulling changes: downloads the latest changes from GitHub into your local copy of the repository

  • Pushing changes/committing changes: means “pushing” your code to a branch, and your changes will show up in that branch with an optional commit message that you enter

  • Pull requests (PR): a form you fill out with a quick description of your changes in the code

    • Allows reviewers to check over your code to give you feedback and request any changes
    • Once approved, your code will be merged to main
    • Reviewers can post comments on the pull request to request changes/fixes to your code

GitHub and VSCode

  • Sign in to GitHub through VSCode

  • Hit “Clone Git Repository” on the Welcome page and copy and paste over the HTTPS link from the repository itself

  • Select a destination to clone your repository locally (somewhere on your computer where you won’t lose it). Yay, now you have a local copy of that repository on your laptop and you can edit it freely!

  • When you want to open that repo in VSCode, hit “File” and then “Open Folder” and open the folder associated with the cloned repository

  • Now you’re ready to code! Feel free to make any code changes here, no one will be able to see them unless you push your changes to GitHub

VSCode Basics

  • First step: open a cloned repository on your VSCode (see above section)

  • Switching or creating a new branch: In the bottom left corner, you should see the current branch that you’re on

    • If you click on the branch name, you’ll see a menu in the search bar that says “Select a branch or tag to checkout”

    • Here, you can create a new branch or select one that you’ve already made (if creating, type the new branch’s name in the box)

      • If you create a new branch and publish it on VSCode, you will see the changes reflected on GitHub as well

  • Pushing and pulling changes:

    • Pulling changes: click on the branch split with circles icon in the left sidebar

      • Hover over “Source Control: Changes” and click on the 3 dots to the right

      • You’ll see multiple options here, but the two most important are “Fetch” and “Pull”:

      • Use “Fetch” when:

        • You want to see what new changes there are without automatically changing your files
        • You have uncommitted work and don’t want to cause merge conflicts
          • Merge conflict: occurs when Git gets confused because two people changed the exact same lines of code, and doesn’t know which version to keep

      • Use “Pull” when:

        • You’re just starting work for the day and want the absolute latest code
        • Warning: the “Pull” action will cause your files to be automatically updated with the latest code and could force you to deal with merge conflicts

    • Pushing/Commiting changes: In the same source control section, you’ll see an empty box that says “Message…”

      • This box is for your commit message, which describes what changes you made at a glance
        • Ex: Create initial AER beginner guide pages documentation, Add GitHub pages workflow
        • Message is supposed to make it easier to see which changes are associated with which commit
      • When you’re done with your message, hit the “Commit” button, and then hit “Sync” to sync your changes to GitHub

How to Make Code Changes and Create a Pull Request

  • Create a new branch with the naming format: FirstinitialLastinitial/task (if multiple names, hyphenate the initials)

    • Ex: ag-dt/speaker

  • Make sure you are making your changes in the branch you just created and NOT main (you shouldn’t be able to push your changes to main anyways)

    • When you’re done with all of your changes, make sure to commit. Now you’re ready to open a Pull Request (PR)!

  • Go back to GitHub: when you visit the repository, you should see a bright green button that says “Compare & pull request”

  • Fill out the PR according to the PR template (it should autopopulate, but if it doesn’t just check the PULL_REQUEST_TEMPLATE file)

    • Add the Embedded lead as a reviewer and assign yourself + your partner on the PR/task

    • Note: The picture shown below is a PR in the repository I used to create this guide, so the PR template doesn’t populate there

    • Create the PR, and shoot a DM to the Embedded lead about it

    • Wait until you get comments or until your changes are merged into main

    • Once your changes are merged, make sure to go back and delete the branch you previously created (to reduce clutter)

Typical Git Workflow

  1. Pull the latest changes from main

  2. Create a new branch using the naming convention above

  3. Switch to that branch and make any changes to that code

  4. Commit your changes with a descriptive message

  5. Open a Pull Request + wait for your code to be reviewed

  6. Address any review comments and make changes if needed

  7. Once your code is merged to main, delete your branch

  8. You did it, celebrate!

General Embedded Info

  • At the end of each quarter, we’re all required to update our embedded documentation for whatever we worked on in this repo

    • It’s a great way to get in-depth knowledge of everything embedded (though it can be dense at times)

    • We use Markdown to write this, and you can run it locally on your laptop to see the rendered changes

    • To run the local rendered markdown page and develop first enter:

      curl https://sh.rustup.rs -sSf | sh

    • Install mdbook:

      cargo install mdbook mdbook-mermaid

    • Clone the aer-documentation repo (or whichever one we’re using at the time) and then run:

      git clone https://github.com/Anteater-Electric-Racing/aer-documentation

      cd aer-documentation

      mdbook serve

      • git clone → clones repo in git
      • cd → means “change directory” to aer-documentation (or whatever the name of the repo is)

    • Go to http://localhost:3000/ to see the rendered changes