View Single Post
  #4   Spotlight this post!  
Unread 19-08-2013, 20:52
nathan_hui nathan_hui is offline
Registered User
AKA: Nathan Hui
FRC #2473 (CHS Robotics)
Team Role: Alumni
 
Join Date: Feb 2012
Rookie Year: 2009
Location: Cupertino, CA
Posts: 228
nathan_hui will become famous soon enoughnathan_hui will become famous soon enough
Send a message via AIM to nathan_hui
Re: Electrical team training

Here are some suggestions:

Presentation 1:
  • Tell the students that Ground is what all voltages are measured relative to. It'll help standardize readings later on, and if anyone goes into EE, they won't be surprised.
  • Servo can be velocity controlled (continuous rotation servo). Be careful, because those are commercially available.
  • Encoders don't tell you how fast something is spinning so much as how much they've spun (and maybe which direction, depending on the particular encoder)

Presentation 2:
  • Page 2: Clarify "continuous". I understand it to mean continuous voltage, but that's not necessarily the entire picture. Power systems (especially on the robot) are effectively DC, but past the motor controllers, they can kind of look like AC. Also, the current for motors is generally very much non-constant (but continuous).
  • Your power diagram isn't *necessarily* complete. You also have 12V going to your analog header and digital out. But that may or may not be important. It may also be prudent to delve into a discussion about the different current capabilities of different ports.

Presentation 3:
  • I wasn't aware that we had 24V level signals on the robot. Or 12V level for that matter.
  • As a matter of principle, not everything is PWM. You have CAN capability and I2C capability, neither of which actually use PWM. I'm also fairly certain that the cRIO does not communicate to the breakouts using PWM, though that would be an interesting design.
  • Just so that you don't confuse people, a solenoid is not the pneumatic piston. The solenoid is the valve you use to control the pneumatic piston.
  • Should you include some discussion of analog sensors? I don't know about your team, but my old team used to use quite a few of them. They're generally more abuse-proof than encoders.

Presentation 4:
  • Instead of characterizing current as low, medium or high, why not characterize it in amps?
  • It may be advisable to give more information about the motors, but then again, this is an electrical perspective, not an electromechanics perspective. Oh well.

Presentation 5:
  • Careful you don't shoot yourself in the foot by saying the example on slide 2 is necessarily easy to trace. Also, cable management does not necessarily mean shorter wires (the shortest wire is a direct line, which generally results in mechanical interferences and the rat's nest).
  • Upside down parts aren't necessarily bad. If I want to really save space, you'd barely be able to access anything without having to take the thing apart. A lot of things would be upside down. Especially the things that need airflow.
  • I would like to debate the notion that zip ties are bad for cable management. Sure, they're not necessarily the most ideal for every situation, but once you've gotten permanent cable bundles, nothing holds them together better than zip ties. They're lower profile, and if done nicely, it looks professional. But, if your team has decided not to, then don't. Better to have a stable standard than a debated and ignored standard.
  • An interesting byproduct of cable management is that you will incur service loops, and possibly higher resistance/impedance over your cables. This *could* affect the performance of your robot, as well as running signal lines next to high current noncontinuous DC lines. Cable management is not only about keeping things neat, but also keeping systems modular and maximizing the performance of signals. Many teams attack the CM side by using breakouts to DE-9/DA-15/DB-25 connectors in order to combine signals into a shielded cable assembly for each system, as well as using interchangeable connectors (Molex, XT90, Andersons) for power systems.

Overall, it's a good introduction to electronics for FRC. I would say that anyone who learned everything in the powerpoints would understand what the electronics divisions work with and possibly what the purpose is, but definitely not how the electronics divisions work, and probably not enough to look at any team's robot and understand the electronics components. You've done a great job covering most of the components, and some of the system level stuff, but there probably could be a lot more done with the systems level view (i.e. showing how everything fits together with both signals and power, showing the entire data flow from environment to actuator, showing where the DS falls into all of this). It's a great start, and I hope that you will continue working on this presentation. It has the potential to really be a role model for teaching FRC electronics.

P.S.: One suggestion for making the presentation itself better: A prof once told me that in order to be a really good lecturer, you have to explain each point three different ways. But you can't put everyone to sleep either. Take that as you will.
__________________
Nathan Hui
B.S. Electrical Engineering, UCSD '16
FRC 2473 (CHS Robotics), Team Captain '12
FTC 4950, 6038