2025-01-08 EFS Leads Meeting

Zeropilot:

• Goal is to have autopilot flight

  • auto takeoff, fly, autoland

  • fixed wing

• Could aim for having drivers done for middle of term

  • Most using DMA is the plan

• Managers are already in a pretty good place, relatively simple for M1 and more or less done

• Integration itself isn’t too intense, might be a task for Ari

• Manasva is slowly taking over ZP throughout the next term

  • He is now the first point of contact for ZP, Derek as back up

• Unit testing we will continue to do

  • For the managers, the logic there

  • Drivers validated through debugger and hardware, not unit testing

  • More so the “software” side of the code, does this input cause this output kind of thing for the functions

• SITL (current on pause)

  • our drivers could theoretically be set up to work in a desktop environment

  • able to validate certain aspects that Gtest can’t (regarding RTOS etc)

  • Telemetry manager is likely most prominent for the first place we’d use this, can discuss with Yarema about his work regarding this

• HITL (not happening for now)

  • Not worth the amount of effort for the risk we get rid of by doing it

• Infra

  • Linting (github actions)

  • Github actions for compiling and running tests

  • We could build the library with arm compiler and run GTest

  • Was done with old ZP so could port over after some light re-write

• Want to get EE boards working, was having driver problems last time

  • Could get Ari to work on as part of integration

CAN:

• LED Board

  • Plan and hopes is to use for current comp cycle

  • Anni has been leading, confirm with him if he wants to continue working or if he wants to pass it back to us and we can find new PM

• Servo

  • For eclipse

  • Priority, need accountable work done consistently

• Power module

  • For eclipse

  • Priority, need accountable work done consistently

• CAN Sensor Cluster

  • Might be killed, maybe they found an off-the-shelf?

  • At least at risk for sure, confirm with Daniel next steps

• ESC might be killed? didn’t need in arch?

  • Confirm with Daniel

Tracking Antenna:

• Should it still be as high priority, considering not for comp?

• Might be harder to get people encouraged to do it when there isn’t really a goal for it, especially considering its less of a learning experience (using arduino, mostly done with bugs to fix, etc)

• Confirm with the people currently working on TA if they’ll be on site to work on at all, can reassign if not but figure out above stuff first

Tuning:

• Priority

• Path forward is to talk to team about it at first EFS meeting

• Explain why this is critical

• Learning tuning will increase their odds of coming to competition

• Explain why this is a good opportunity

• Setup an environment for knowledge transfer and for progress

• There’s team members who have knowledge about ardupilot setup, get them, and facilitate an environment where they can knowledge transfer and get the people going. So explain important to team and set up meeting and environment where ppl can get together and pass knowledge and make progress

• Setting up space for them to fly is a task too, likely can’t fly near E7, WREST RC if booked, or maybe there’s a parking lot or a field or something out by CLV

  • And finding a time where we can support it, this is harder to support since we’d have to create time for just supporting this one task instead of being able to jump between tasks in work session for ex

  • Might be a good idea to talk to someone with experience in Mission planner / ardupilot like Manasva, Jerry, Smile, Yuchen, or Evan

Objectives/deadlines for Comp/Eclipse stuff:

• Servo and power module hopefully can finish by end of term

  • Servo is a lot closer, power module we know where to go roughly

  • We have our own hardware to work on it and firmware should stay the same between those and EE board if needed

  • I believe we do have EE boards for all of these, though confirm?

  • Confirm if there will be newer revisions/plans kinda out of curiosity, not critical for EFS purposes

• LED Board

  • Will follow up with Anni

  • We already have EE boards

  • Confirm if there will be newer revisions/plans kinda out of curiosity, not critical for EFS purposes

Plan to split work:

• Derek mostly for ZP

• Roni mostly for CAN

• Tracking Antenna and Tuning have less defined scopes so will figure out as that’s figured out

Plans for first social:

• Blind/deaf/mute bakeoff, maybe at Derek’s, then hangout and play switch or board games

• Maybe go to board game bubble tea place in plaza depending on number of people

• Sending out a poll to gather interest

General:

• be more direct with deadlines and involvement expectations so priority tasks can move forward more consistently and members with less time aren’t under sudden pressure

• some kind of plan or routine for consistent progress
  
  
  

Should probably move the stuff below to another doc:

Goal for Bootcamp:

• Set up and able to use IDE, STM IOC setup, and Git/Github

• Write C/C++ code

• Know how to consolidate a data sheet

• Know how to ask the right questions

• Understanding of general approach to embedded development

Reviewing Bootcamps:

• Jot down any notes while reading over PR

• Files changed → IOC

  • Download

  • Could use the specific IOC viewer software so able to view IOC without opening entire project in CubeIDE

  • Check that IOC configured to work correctly with SPI and PWM

    • Confirm they’re using right pins as outlined in Bootcamp doc

    • Check timer (TIM1) for PWM config

    • Check SPI config

• In main.c

  • Check code

  • Initialized safely, correct bytes sent and bytes received interpreted correctly

Post Bootcamp Meeting:

• Ask basic questions about SPI and PWM

• Ask some questions about the IOC config and the code, some mistakes are ok but see effort and ability to answer the basic questions

• Suggest any improvements and walk through any concepts that they may be confused on

  • If no improvements, they may close their PR and are now done

  • If improvements to be made/things to be fixed, ask them to work on it and let you know. Also leave a review on Github so they remember what to fix. Likely no need for another call if they are able to fix it.

  • If not enough foundational/basic understanding of Bootcamp knowledge goals (might be because they just copied from a past submission), ask them to work through it and gain a better understanding of what they are working on. Will likely need another call once they are ready in this case.

• Give new member onboarding confluence at the end