Hello, I’m working on an offseason drive train and I want to include a belly pan for mounting electronics and for structural rigidity. There are many options when designing a belly pan, so I appreciate any advice teams can share.
On other threads, it is generally agreed upon that the diamond pattern lightening of aluminum belly pans is only worth the manufacturing time investment for very experienced teams. Consequently, I will be limiting the CAD to solid plates with holes or COTS perforated sheets. I understand that there are countless options for materials, and I wish to better understand the tradeoffs between them. From a design standpoint, I prefer a solid sheet (e.g. baltic birch vs perforated polycarb) because I can put holes only where I want them.
I have seen many robots with essentially all of their electronics on their belly pan. My team has usually made spark max plates so that the encoders are placed very close to their motors, and the aluminum plate acts as a heat sink. However, I would prefer to have electronics on the belly pan to save space and weight. For neo motors, will anything bad happen if we extend the wires between the encoder and the motor?
For (1), I’m a big big fan of baltic birch. If you can source it, it’s super easy to work with. I’ve used 1/4"/6mm solid sheets as bellypans before, and riveted them to the frame with washers underneath the rivet.
For (2), nothing specifically bad will happen. With our experience with NEOs, we typically try to locate the motor controller such that we don’t have to extend the power or encoder wires coming off the motors themselves, since that just adds a lot of connectors and failure points. If you’re looking at saving weight, I don’t think heatsinking the motor controllers to aluminum is hugely necessary.
Does your team put motor encoders near the motors?
My team is also going to be using rivets for the first time (previously we used 8020 and t-nuts). Do you need to use rivets with a larger grip range for the belly pan since it is so thick?
My team uses large, thin, non perforated sheets of polycarbonate. Our 2020 robot had three levels of belly pan like sheets and they were all made of either 1/8in or 1/16in thick polycarbonate. They are relatively light and allow for super flexible mounting, as well as being really easy to cut and drill. If you are trying to avoid lightening patterns stay away from aluminum because a non pocketed aluminum belly pan will add a lot of unnecessary weight to your drivetrain.
We mostly use the built-in encoders in brushless motors. When we do have external encoders, they’re typically located closer to the mechanism than the motor to minimize backlash, and we typically wire them to the data port on the motor controller.
Yes to the grip range, we try to always make sure that the grip range is appropriate for the application. The bins we store rivets in are labeled by the grip range.
Especially in the CAN motor controller era, I would highly recommend you keep sensored CAN motor controllers right next to the encoder. Really can help cut down on signal noise and simplifies debugging/wiring/maintenance in the long run. Adding a NEO encoder extender just adds failure points to the system, which you want to avoid.
Here is a link to a few clean wiring pics I keep on hand as a reference, they might give you some ideas on clean belly pan layouts
I would agree that adding encoder extenders to NEOs so that the Spark Maxes can be located remotely from the motor is probably not worth the hassle of the extra failure points.
Having said that, we did do that this year for our shooter motors and intake motor so that the motor controllers would not be on the moving turret or intake (mostly due to space constraints on those mechanisms). REV sells extension cables and joiner boards. We followed REVs recommend method of using shrink tubing to secure the connectors to the joiner boards. We never had any issues, but obviously, we did not subject this setup to a full season’s worth of battle testing. also, the shrink tubing makes the connection fairly difficult to disconnect if you do need to replace a motor or swap a mechanism.
Thanks everyone! My understanding is that although no one has had issues with extending the cables between the neo and the spark max, it should generally be avoided.
If teams aren’t placing their spark maxes on the belly pan, where do they put them? It just seems strange to me that I rarely see motor controllers on mechanisms of other robots when ours are always littered with electronics. Should I put the spark maxes near the motors or is it okay to wire them off to the belly pan?
I see spark maxes sprinkled all around robots often, it’s definetly preferred to not use any extensions. An important consideration is to protect the can bus.
Our 2020 robot doesn’t have a belly pan but it is a fun game of spot the motor controller.
My rule of thumb is generally if a motor requires an extra sensor, is far from the drive base, and is protected enough, keep that motor controller near the motor. Here are a few examples I quickly found of motor controllers not on the belly pan of robots
Spreading the motor controllers around the robot can improve the serviceability of the control system if done in the right way. Imagine trying to work on or trying to troubleshoot a control system mounted on a bellypan with large mechanisms installed above it.
Sometimes the right answer is to mount the control system on vertical panels above the top of the bumpers. Of course, protective panels would be installed if required. My memory is not the best but I don’t recall seeing many robots with bellypans in 2015 due to the physical configurations that many teams chose.
We use Compbond for our belly pans. it’s sandwich of aluminum and ABS, which gives it great durability. It’s a little expensive, but many sign shops use it for displays and other various things, so ask around and see if any of your local ones would be willing to give you cutoffs. I encourage you to keep your sparks close to you motors for a few reasons.
a. CAN and two power wires is easier to run than three phases and the encoder cable for NEOs.
b. It makes troubleshooting easier, because instead of having to label each motor controller or tell them to blink, you know the motor controller mounted right next to the motor is the one driving that motor.
I can’t tell what you mean by encoders, but using external encoders for velocity control (and even position control) has become a bit outdated with the introduction of the encoders internal to the NEOs. Many of FRC’s best programmers have come to a consensus that the internal ones work just fine. Now, if you’re doing position control that needs a precise encoder value, then I get it. But even then, it seems like your best bet is to put the Spark closest to the encoder and motor as it’s a big convenience factor and we FRC armchair EEs tend to not worry about EMI as much as we should sometimes (ask me how I know).
Also keep in mind that brushless motor controller’s three outputs carrying AC current (technically trapezoidal, but close enough) will dissipate \frac{3}{\sqrt{2}} times the amount of power of one DC input, or about 6% more than the two DC inputs. Not a significantly higher voltage drop, but not nothing either.
