2023-09-19 Electrical Leads Discussion
- Michael Botros
- R D
- Mena Azab
- Daniel Puratich
Atendees
@Daniel Puratich
@Anthony Luo
@Megan Spee
@Mena Azab
@Nolan Haines
@Michael Botros
Topics
Possibility of appointing another EE lead as next term none of the current EE leads will be on site.
Discussion
Appointing a fourth EE lead because no onsite lead
Having someone onsite would be nice
Neel possible candidate
Few other candidates?
Communicate at next subteam meeting
“it would be nice if we focused more on building foundation in the team in sense of hands on”
seeing lots of bootcampers at the work sessions, we want to build people up
soldering an XT90 becomes a lot of repetition in the things leads have to teach
because you lots of bootcampers, this type of activity that brings people together is very applicable here
XT90s is very common for WARG builds.
Could invest in videos at the end of the bootcamp or confluence docs explaining tutorials
giving people that gold standard one time could help them a lot
Direction
discussion in #ee-comp-drone today!
Mena: “team is good at saying what needs to be done, but falls apart at giving direction and assigning specific people to do things when”.
everyone knows what needs to be done
really hard to find direction
if you take direction immediately instead of working with you it feels like they’re breaking you down
Example: ESC cases
We need ESC cases, then we never really got requirements for them, Conall begging for requirements, then he did it himself, then he got very brutal feedback
This workflow is very confusing
Give tasks a direction and clear ownership & expectations
It’s easy to see what needs to be done or what’s missing when looking at the final product but tasks feel under supported at the start
Someone just needs to make the decision and say make the call instead of open ended responses
Solutions for a small thing become very nebulous because directors not calling it and pushing for individual engineering analysis which is very time consuming
This balance between “calling it” or “letting people analyze it” is described in more detail within Resolving Engineering Disagreements
For certain decisions there is more direction required from the beginning
Currently electrical requirements come more from directors than ee-leads
What’s stopping leads from doing the eng analysis themselves?
There’s a lot leads have to be up to speed with
The gender conventions thing that happened at the work session
It’s hard to know all this stuff when you’re new
If unsure about something ask question?
EE has always been coming up with their own projects and directors adapting that to be beneficial to the team
pressure felt currently is shift from “pcb design club” to more “comp related”
Sometimes directors need to shot call Resolving Engineering Disagreements but we want EE-Leads to be directly involved in design reviews
bringing up concerns and questions early is required to get the proper feedback without wasted effort
“we don’t know what we don’t know”
hands change quickly at WARG and dunning kruger goes hard
it’s easier to receive direction at the beginning instead of feedback at the end from an ee-lead perspective
EE is a unique position of ramping up to competition hard
Can be extented to all subteams
at the beginning of every project they ask people to make a block diagram as an initial phase
feedback is given at that stage, but creating a block diagram takes some effort
asking subteam leads to make architecture block diagrams?
have official meetings to review designs
From Megan “i relate pretty hard to u Mena, on mech and when I was mech lead I called some shots and I made design decisions that were ultimately flawed. but it's kind of about learning, right- I also asked people a lot to check over what I was doing, because I wasn't very experienced, so luckily most of what I had part in kinda turned out. But there were def things that I made that I had to fix last minute and stuff just because I never bothered to reach out for review. It comes with time, i guess, you just get a sense for what might cause a problem in the future. ngl i wish i could actually offer advice, but i still struggle w/ that” in discord here.
2023-2024 Program Outline is the projects from the teams perspective
This year we are rushing ahead on stuff which leads to some of these issues
2024 System Architecture this doc will eventually have the RFC system which will be implemented once the arch doc is finalized.
Subteams require less director guidance as knowledge builds up? Knowledge only builds up via repeated design reviews and questions
A lot of this is caused by lack of knowledge and knowledge transfer
People who learn things will be the people who do things
there will be mistakes along the way if people are doing things they’re inexperienced at
Going step by step is not always efficient when
why wasn’t location of ESCs decided when mech frame was designed
mech frame was designed to be a modular flexible setup
here “goal is to keep system flexible during this initial assembly.”
We use 30x30 mm standard on the top of the frame as defined in Mounting Hole & Pattern Specifications
Difficult to do step by step when delegating out
lots of delegating is possible when things can be sequentialized and parallelized
theory and concepts can be done before hand to allow for easier delegation
whey wasnt ee told where to place ESCs
this wasn’t conveyed clearly because background information wasn’t conveyed
this was conveyed by Anni here
“put down a layer of tape on the carbon fiber, and then use double sided tape for the ESC's and that should be ok. you can use the cases from last year if you're really worried”
Many design decisions were captured in syncs like
Why are we waiting on some design decisions
we currently have 4 diff usable models of ESCs we could use on Pegasus
we have lots of diff requirements for all of them
they are all optimal for a diff use case
We didn't account for all of those when deciding to mount something
design decisions at the time of making the mechanical frame was allowing for maximum choice when it comes to ESCs
we need to communicate historical information from sync meetings to subteam leads
a lot of this narrows down to component placement → doesnt feel like anyone is responsible for component placement
it’s not clear who placement belongs to and how it should be tackled.
generally quick tests require lots of collaboration and people engaging and asking questions
for competition stuff it’s a lil more of an optimization phase
we need to prioritize for these type of things
pixhawk
rf sig performance
all components have unique requirements from all aspects
electrical should handle electrical requirements and facilitate integration
EE should focus on most important things electrically
because of this the process is more decentralized
An example of a component with all of it’s requirements documented is Jetson
The whole solution to this might be using software to easily share component placement / collaborate on block diagrams
hehe Daniel thought of this as well here
a collaborative diagram system will help
component placements are driven by subteams that bring them up primarily
order/priority will be defined based on the strictness of requirements
Who exactly is the “we” in these discussions
subteam leads during AEAC syncs
There’s a huge integration game with lots of components
one decision will have cascading consequences
having integrated subteam leads will be important
sometimes it isnt clear who is up to what subteam
definitions need to be clear
scope of electrical team possibly needs to be defined because its not so clear
Challenge is rn we have a drone before an arch document so it makes it difficult
We can check back in in a week and a half
can do another director sync with questions
2hr meeting ggers