Electrical Team Structure Ideas

Technical Electrical
#1

Hey all,

We’ve been shifting the structure of our team over the past few years, namely who is responsible for the electronics on the robot. I’m curious, how does your FRC team delegate the electrical work? Do you have a full ‘Electrical’ subteam? Is it lumped into another grouping of students? Right now we have our electrical and programming students grouped together into a ‘Controls’ group, with the idea that some students still specialize in one or the other, which creates a divide I’m looking into adjusting next year, and I’d like to hear what your teams do for some ideas.

Thanks in advance!

1 Like
#2

We have a seperate programming and electrical subteam. They’re relatively seperated, and only a few from each subteam are capable of the other.

#3

We have a separate Programming and Electrical group because programming can be a full time job.
Also, our electrical group is in charge of the pneumatics.

#4

3946 had a similar structure for the first two years. Unfortunately, the wiring and plumbing suffered for it, partly because no one was joining controls unless they wanted to program (your dynamics may be different). Splitting the two (and getting a real electrical/pneumatics mentor) the third year was a great improvement - we went from TRS (twitchy robot syndrome) to where electrical and pneumatic systems were more reliable than mechanical or programming in a single season - and programming improved as well, as they weren’t “distracted” by wiring and plumbing. (And at least some stuff was LABELED!)

Added: It was implied, but let me make it explicit - the same sub-team does electrical and pneumatic systems. It never made sense to make a separate sub-team because some years (2015 & 2017) the robot did not have a pneumatic system.

#5

We have a separate sub-team for electronics (and pneumatics), they have nothing to do with programming / CAD / mechanics

#6

We also have a separate electrical team (along with mechanical and programming) as one of the build teams. They handle all electrical work and also do pneumatics except for the actuators themselves, which tend to be integral to systems that the mechanical team builds. The team has been structured this way since out rookie year (2013) and it’s always worked well.

#7

Yep our electrical people also handle pneumatics.

We originally had electrical by itself too, but the first few weeks of season are a bit awkward because the workload doesn’t kick up until the robot is mostly together (there’s some minor test board setup and helping with prototyping, but not 3-4 weeks of work). It’s that gap that mostly resulted in the merge. After the robots coming together there is plenty of work electrically, but the first half of season is my main concern for maintaining a steady stream of work to do

1 Like
#8

Mechanical/Electrical team separate from programming (mostly)

#9

Until this year, we had electric as a subteam of mechanical. They are also responsible for pneumatics. For 2021 they are a separate team.

#10

We technically have a separate electrical team. We have a dedicated mentor and student captain for electrical, but most of the students who work on the electrical board also dabble in other subteams - we had a lot of kids interested in learning about electrical stuff this year, but there’s not enough work to keep them all doing electrical 100% of the time.

2 Likes
#11

Like others, we have a dedicated electrical team. In pre-season or early season, they spend time working on core electronics which includes installing connectors on new components, checking connectors on reused components and testing/logging battery performance.

One area we have had difficulty with is who has responsibility for mounting sensors, electrical chains, and brackets for electronics. Does this fall to mechanical or electrical? As a mentor, I lean toward this falling into the mechanical camp, since it calls for planning during design and CAD.

1 Like
#12

I would suggest that the electrical group take responsibility for installing the sensors and their associated wiring and wiring devices such as the Igus chains.

You are correct that these components must be included in the CAD. If the electrical team has the responsibility for those components, they need to have a seat at the table when determining the initial design concepts and at the subsequent design reviews. They should also be there to ensure that there sufficient consideration given to the rest of the control system so that there is sufficient space for those components, that space is in a reasonable location and that there is adequate access for construction and maintenance. A few more hours of thought invested into the design of your robot can save days of frustration when building, modifying or repairing it.

#13

We are a small team, so out set up is a little interesting. We TECHNICALLY have a separate electrical, but we only have one person in electrical. For the beginning f the season, she works on cad and switches over to electrical once the building kicks in. We also have a mechanical who knows electrical well enough to help. With those two and the mentor, they get the robot done fairly quickly.

#14

Electrical and programming are separate for us. The world interaction part of pneumatics works with mechanical, whereas wiring pneumatics is electrical, and coding pneumatics is programming.

#15

We have an electrical subteam that handles all things electrical and a completely different subteam that handles all of the programming, named the programming subteam obviously. In terms of pnuematics, the electrical subteam does deal with the PCM but the mechanical subteam deals with everything else.

1 Like
#16

Our programming team will often consult the Electrical and vice versa but they are (often) separate teams because of the load that both sub-teams carry. For the Future we plan to have middlemen in all sub-teams to help better integrate systems.

#17

We have a single controls team. The controls team handles, wiring, programming, and pneumatics. There are no hard lines of demarcation in the group, and I expect all of them to be able to perform basic tasks in all 3 disciplines.

If you study business at all you will find that most businesses are a set of constantly changing org charts. The company will try to become a ‘flat’ organization with very few levels of middle management, where the layout is basically workers -> mananger -> director/owner/etc. Later, the company will slowly move toward monolithic structures with manager reporting to manager as it grows. Eventually it becomes multi-layered and someone in management decides it would be good to become a ‘flat’ organization again, usually with a head reduction to become ‘lean’ or ‘work oriented’ or whatever buzzword you like.

The constant migration is really just a way to justify head count reduction while giving the manager of the day something to report to their bosses as a continual improvement.

The benefit of small teams like we run in FIRST is that you can keep them small and agile. You don’t have to have them set in stone, and if someone wants to work on A they can, even if normally their job is B. Organizations that become rigid (“that’s not my job!”) become buearacracies. That’s the reason many companies will look at what FIRST teams do in the time span they do it in and tell you point blank “our engineers couldn’t do that”. The reality is that their engineers COULD do it, if the company would get the heck out of the way and let them work rather than filling out forms, attending meetings, and adhering to all the rules.

Big companies inevitably fall into this trap, and if you talk to engineers and designers in those companies you’ll find many of them spend huge amounts of time in administration like book keeping and paperwork rather than problem solving and designing. That is also how you go out of business.

I could give you a real life example and how this gets so bad that employees end up going without the ability to log into portions of their jobs for a week, and it’s considered business as usual. Or how a key system breaks and it’s discovered the sole guy who owned it was cost-saved out of the organization and on one was ever assigned his job tasks. It would take several pages to explain the absurdity of it all. I suggest you start reading Dilbert to get an idea. That comic largely is true to life.

6 Likes
#18

I’m not super worried about forcing students into boxes, we have students who move between subteams perfectly well. I’m more considering the structure at the base level, so incoming students have clear expectations for what they will do when they want to join X subteam. I really just want to make sure that the workload of the controls part of the robot is balanced as well as reasonably possible.

I’ve been thinking about having the electrical students spend more hands on time helping with prototyping (mostly the build/CAD students right now) for the first few weeks of season. It both helps fill the time with useful contributions while waiting for the robot assembly, and it also can help build understanding of mechanisms and sensory applications within them.

#19

I think that’s an excellent idea. I try to emphasize that good programmers really need to understand the mechanical and the operators to do it right. The wiring team needs to understand the mech team for ease of assembly and robustness. Basically, the more you know about everything the better you’ll do at your particular job.

1 Like
#20

Our electrical team is separate from our programming team. Pneumatics are done by the mechanical team. Might be a little bit unusual, but I can now see why it’s done by electrical. I wish I saw more cross-training among the other sub-teams, but we will be trying again for it this year.

1 Like