My only hesitation is if it’ll make the PDP too bulky, but I’m all for it if it’s clean and compact.
To expand on my earlier comment, things I’d like to see:
- Unquestionable reliability.
- Training and tools to get a programmer from zero to “can do whatever 5-point autonomous task is on the field that year”. (I can say, without a shadow of a doubt, that this is not the case today.)
- Clarity in WPIlib documentation when they only support a basic form of a vendor’s product, so kids don’t think that’s all there is.
- Clarity in vendor documentation on how their product interacts with WPIlib, so kids don’t think it’s a whole different world.
- If/when existing components are going to become illegal for competition, a year’s notice. (FTC does a pretty solid job of this.)
- Continued shifts towards CAN becoming the norm.
- Ways to put PWM motor controllers on CAN, so existing stockpiles are more versatile.
- No new connectors we have to learn how to deathproof.
- If we can do that at a cost savings, sure let’s do that too. But I’d rather pay the going rate and get something better than get a cut-rate thing.
Yeah, the VRM isn’t really that important. All the VRM is is an extra box just for your radio.
Only use connectors that have a sufficiently large body that can be grasped to pull out the connector instead of having to pull on the wires like the encoder connector on the Spark Max.
The WPILib docs do exactly that… step by step walkthrough of installing, setting up a project, and culminating in this 5-point auto routine. (although you might need to tweak the timing a bit). Sure, it’s not the most elegant 5-point auto routine, but it does check that box.
Is there something more you are looking for?
Our new programmer about Jess Boucher’d me in frustration trying to follow that guide, and as a non-programmer I don’t know where things went off the rails. My hypothesis from trying to follow along in the documentation is that WPIlib’s documentation for newbies in how to handle CAN-based motor controllers does not quite reach up to the edge of where CTRE’s and REV’s material reaches down.
I certainly see why WPIlib doesn’t want all of those vendors’ things in its code base, but the gap can be confounding to teams who see CAN as the way things are going (which, it is–nobody in the FRC market is rolling out a new PWM-only controller these days).
hmmmm, wonder if FIRST could get them to do a behind the scenes thing about what is inside and how they work
If your programmer(s) are struggling to implement CAN, then why use CAN? If you are only expecting to do basic driving/moving functions PWM will work fine.
Back on topic I hope the new RIO has more I2C slots.
I’m struggling to reply to this without including snark because I find your notion so dismissive that I think it deserves it… so I’m hoping you appreciate you are about to get one of the least snarky answers I can muster in an effort to get you to see that this isn’t a great line of thought.
There are a host of reasons as to why a team might want to use CAN, specifically that the current crop of “smart motor controllers” for FRC rely on CAN and do PID and other things (current and voltage sensing) onboard. They might also only have CAN based motor controllers. They might also have a desire to push on the limits of what they know and try something new and outside of their comfort zone.
That’s effectively how the cRIO era PDPs worked. They contained the VRMs for the cRIO (24V) and radio (12V). But no “smart PDP” functionality (just distributed and regulated power).
The issue (besides not having any “smart” capabilities), however, was that the original radios specified (Cisco Gaming Adapter, 2009-2010) used 12V, while the D-link radios used later (2011-2015) used 5V, and in order to keep the same PDP, a 12V to 5V adapter was used. Going to an external VRM likely was at least partially to prevent this issue; if we ever changed radio voltage, it’s a lot less expensive to ship everybody a new VRM than a new PDP, and doing so would avoid having to use extraneous adapters.
Yeah, those little JST connectors are terrible to insert, remove, and manage. I hope REV can look into some beefier, nicer connectors in the future for small pins like that. That being said, I’d probably just use a Falcon anyway. Speaking of connectors, I hope that (if REV is actually making new PDP/PCM/VRM) they stick with WAGO connectors or at least not XT connectors like their FTC products. Just having bare wires is quite nice as a PowerPole team. Even then, a WAGO seems more reliable than a pair of PowerPoles even if one was soldered directly into the PDP. Maybe the Weidmullers could use a replacement with some sort of connector, but I think teams have learned how to succeed with them. .1" headers would be a huge step back. JST XH connectors at least don’t fall out all the time but are such a pain.
Anyone have any experience with retention in Molex KK connectors I personally like the JST SM connectors but they are only available in wire-to-wire format.
While all of your other points are valid, this one really isn’t. AFAIK, all current CAN motor controllers support inputting a PWM signal via their CAN wires. (the diligent controller might not, but does anyone even use that? Certainly not enough people for it to be worth me checking if it is still a legal motor controller)
While you are technically correct in that it would work fine, if your team is attempting to do anything remotely smart in the future, that wiggleroom of CAN-capable devices being driven over CAN is lovely. And given that the last PWM-only device given out in the kit was the Spark in 2018 (!), it’s entirely possible that teams won’t actually have any reason not to at least try it.
This isn’t something that trying it out is cost prohibitive, most teams will already have them in-hand, and the failure mode is “doesn’t work, go back”. As a CSA and mentor (your user title says you are one anyways) there’s plenty of room for teams to learn there in trying and not succeeding in a way that doesn’t hurt them, no?
We used connectors from that same product family at my last job. It is a type of connector meant for applications where frequent assembly/disassembly is not required. We used it for some sensor cables that are plugged onto a board at the factory and it would only be unplugged if the equipment needed to be repaired by factory trained technicians (once or twice over 20 years). Most of them would only be unplugged when the equipment is being scrapped.
Thanks for the feedback. While it’s not going to be practical from a support perspective to do this everywhere, I agree it would be beneficial to build some better bridges to vendor docs in key spots. For example, just above the section I linked to, we could add a section with tabs for each vendor showing a few lines of drivetrain motor setup for that vendor’s CAN motor controllers, with links to the vendor documentation on how to install their vendor dependencies. Do you think this would be sufficient to address the issue you ran into?
Hopefully better connectors on the Rio and better protection against metal shavings.
To second Billfred, and speaking as a non-professional programmer familiar with the basics of logic and some minor capabilities in other languages, beginning to program in FRC is a massive undertaking mostly due to references all over the place from different vendors/libraries. If everything was in one place with examples for each different vendor the bar would be at a much more approachable level.
Maybe if REV included these (and left clearance for them) then at least people would rip fewer wires.
That’s why I think it should have both a dedicated 12V and 5V 2A output. Cover all the bases before it becomes an issue.
This is my biggest concern. I would kind of be alright with some JST stuff on a PCM or VRM replacement, but the WAGO connectors on the PDP replacement need to stay, no questions asked.
However, I think we should remember that Rev’s engineers and corporate staff are also FRC mentors. They had a reason to try and improve the standard for FTC, but hopefully they understand that FRC is different.
I certainly hope that the “compatibility with current devices” includes being able to use the new development environment and wpilib and deploy to existing roboRIO(s) for testing…