My team always seems to be a year or two late on what the FIRST Community is doing. I’ve been curious what new technology or concepts you’ve seen be used this year. Hardware or Software.
A few examples from the past few years (also maybe I am just really out of the loop!)
What Else? Any new sensors becoming popular? Any software Concepts?
(If it isn’t clear I’m looking for offseason projects for my time to work on!)
Not sure how new this is but I’ve seen more teams using ethernet switches than before. I’m guessing this is due to the widespread use of vision cameras.
Things that caught my eye this year as increasing in use or a likely new trend:
Another trend I’ve seen is teams foregoing pneumatics. No more rushing to pressurize in queue is nice
This may indeed be a trend as more people switch from the 16-circuit PDP to the 20-circuit PDH allowing more motors. If so, I think it is a trend that we are likely to buck (depending on the game, of course).
I’ve seen a lot more swerve than I did in 2020. I’ve also seen a lot of Limelight. It may be just because our team did it for the first time this year, but I feel like I’ve seen more turrets.
I definitely see pneumatics becoming necessary again for a pick and place game.
Yeah we’re still WCD. Not sure if we will bother with swerve, although swerve looks awesome
it CAN’T be another shooting game next year right?
Pretty sure they used a very similar mechanic to 2020 with the shooting and climbing to help ease teams back in
Climber-in-a-box solutions. So many good options out there now. They have really raised the floor on overhead climbs.
Swerve everywhere. At the PNW events I was in there were more swerve teams than not,
Swerve, turrets with hooded shooters, and vision were all very common in NC this year, thanks in part to great COTS solutions
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!
We’ve got YourKit working on the robot a few times in the past, @jlmcmchl might be able to shed some more light on this if he remembers.
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.