This has been the year of COTS swerve (specifically SDS), turrets, box climbers, and Limelights. I don’t think any of these are going away any time soon.
What turrets with hooded shooter COTS have you seen?
I saw at least one GreyT turret + shooter combo. We built our shooter (no turret) using the GreyT STEP files for the side plates, which worked well
I’ve noticed several things on the support side as brushless motors and a-motor-on-everything-that-moves has become more popular.
More teams I’ve helped on the FRC Discord have had CAN delays from too many devices on their bus (both motors and sensors), and brownouts. Increasing status frame periods helps somewhat with the former, but it would be best to never send unused data in the first place so you don’t get bus spikes every 255 ms (CTRE’s max period) or 65.535 seconds (REV’s max period). A few teams on the Discord saw some success with using prime numbers for the status frame periods.
I’d prefer that the vendors and teams use the existing CAN bandwidth more efficiently instead of adding more. Increasing the bus data rate with e.g., CAN FD means that teams will have to follow the CAN spec’s topology more closely (no stars, avoid long bus runs). I’ve seen a few posts by CANivore users here about unstable bus segments due to violating these constraints.
More teams are using brushless motor built-in encoders, and more teams have asked why the SysId optimal feedback gains are so low, or why their feedback is so sluggish but oscillates if they increase the gain more. The cause is the default velocity measurement filters on the Falcon 500 and NEO built-in encoders adding a lot of measurement delay. It’s fixable with the Falcon, but not with the NEO.
Loop overruns have also come back. I’m not sure whether it’s from people creating a lot of objects in Java and the GC getting involved, or some kind of blocking I/O on the CAN bus.
Convenience is winning over deterministic, more performant robot architecture. Teams assume there won’t be a problem, but if there is, it’s a lot harder to fix later. This is reflected in both the hardware choices (everything on CAN without proper RT considerations) and software choices (Java for robots). There’s nothing wrong with considering the tradeoffs and picking the more convenient solution, but teams need to at least be aware of the performance they’re potentially giving up and whether it’ll matter for them in the long-run (do the math; save the world?).
I can’t speak for everyone here, but our decision to ditch the pneumatics this year has been so incredibly worth it. Also, brushless motors are almost the gold standard at this point.
I really love this note. I have a lot of thoughts on this - but they’re maybe not worth getting in to in this thread.
One question I have here for others is what tools do y’all use for profiling/troubleshooting Java robots and performance? Debugging utilities is one big component I’m missing from my toolkit that I feel like would allow me to level-up in tracking down issues.
Edit: I feel like I should offer up some conversation in this topic as well as opposed to just asking for help. We used AdvantageKit for part of this year with a decent amount of success. It decreased our autonomous and systems tuning iteration time by being able to view things on graphs and in tables. The software is still a little bit weird though, and we dropped it due to other reasons. But I’m very excited about this piece of technology, and I wish I had more open source cycles to contribute to it myself!
Eh, I’d argue 2019 moreso for that, though you can get away fine without this year (aim in the general direction) and in 2019 (goal indexing features).
I don’t feel like we’ve seen quite a much complex shooting on the move as was teased throughout 2020 and 2021, but that’s certainly beginning to change robot and code architecture in wider audiences.
REV absolutely knocked it out of the park with the MaxPlanetary. It’s better in every way than it’s predecessors, while being priced similarly. Also, who doesn’t love a load ratings table that’s just: YES
We would have loved these so much on the single jointed arms.
Solid full send product, and I imagine there’ll be more significant outside (Battlebots etc) appeal.
Yep. Can’t wait to spam these everywhere if the 2023 game ends up being an arm/elevator game like 2018/2019
It’s been a while, but it required something like this to get running -
The idea here was to expose JMX metrics that yourkit or another JMX client could consume. It was certainly helpful to understand where our performance issues lied that year; the JMX server shows you general JVM information unless otherwise configured.
As a recommendation, I wouldn’t take this approach first in understanding performance issues. JMX metrics grant you a snapshot of the running application - which is valuable in professional environments & especially long-running server applications, but I don’t think it’ll give you much insight on a robot.
I feel like this is the first year though where you can’t just slap a flashlight on and practice a bunch to be top tier, so it’s pretty close to limelight-or-nothing if you don’t want to do any work on the vision pipeline
Absolutely. The shot volume for top teams is so high that aiming using vision is absolutely necessary. In previous games that had actual cycling, teams would top out around 9 cycles, which means 9 times you need to aim and shoot. Now, we’re seeing the best teams do 15 “cycles” or more, depending on how many shots you put in when you do shoot. That time to align happens more, meaning minimizing it has even more of an impact.
Trajectory following developed tremendously in 2021, and it’s been a huge deal this year. The resulting quantity of top-tier autonomous routines is astronomical compared to previous seasons.
Can you explain this as if (for example, just hypothetically) I was a big dumb mechanical engineer who has been in this program for 11 years but still has no idea what CAN really is just that we send signals on it and occasionally it gives us bizarre errors that I can’t wrap my big dumb mechanical brain around
Back on the old IFI controller in C you had to be very careful about everything you did to keep the code running quick.
When more powerful controllers, WPILib, and managed stuff came around it was like you had a big bucket and you could dump pretty much whatever code in and it would go, as long as you didn’t do anything silly.
Recent years have increased the number of cups of liquid you have to / can pour into the bucket, and if each of those glasses were a little too full, you might overflow the bucket, and that would be bad.
Instead you needed to look from the beginning and decide how to put the right (usually minimally efficient) amount of liquid in each cup before dumping it into the bucket. Un-overflowing the bucket can be hard if you’re already at that point.
I can try. (Hoping not to get flamed)
There’s a camp that thinks the path from (a) building a cool mechanism to (b) using it to score points should necessarily go through:
– capturing thorough a priori knowledge of the system using modeling and system identification / characterization techniques
– using that knowledge to crystallize a model-based control system
There’s another camp that thinks the path from (a) building a cool mechanism to (b) using it to score points should necessarily go through:
– implementation of the simplest possible control method, e.g. bang-bang or a P-only controller, using hardly any a priori knowledge of the system
– choosing to implement more performant control methods when it’s determined empirically that the more convenient approaches are not good enough for the task at hand
Neither camp is always right!
- Brushless motors in general (NEO/550) in addition to the Falcons
- switching to all CAN control rather than PWM
- Proximity and contactless (Hall effect) limit switches
- COTS linear motion
- Minimal use of automotive motors (window, van door, throttle)
- Increased use of belts over chain
- increased use of compliant wheels in conveyors and intakes
- hex shaft over keyed shaft
Use of poly carbonate for structural components instead of aluminum.