We’re trying to keep the overall philosophy and structure similar to WPILib – subsystems, commands, etc. We mainly made Sertain in order to make use of more Kotlin APIs that we wouldn’t have been able to otherwise. It also gives us a little more fine-tune control over the lifecylce of commands, so we know what’s running and when. We’ll be adding more over the course of this off-season, especially in regards to testing and simulation. I’d really like us to do more test-driven development next year, but even having a few tests is a step in the right direction.
It was actually super easy with Gradle, fewer than 50 lines. You can see the code here. That was all made post-competition season so it’s never been used in competition, but it has helped us tremendously at off-season demonstrations and even just everyday debugging. We just display it on Shuffleboard for anyone wanting to check the version of the code, but I’m looking to do more now that we have access to all that information.
Nothing fancy. Basically just color thresholding, find the biggest blob of the right dimensions, then send the location back to the roboRIO which uses it to grab a cube. We did dabble around with actual object tracking with OpenCV’s CSRT, KCF and MOSSE classes, but we didn’t ever get anything more usable than without, and the FPS drops weren’t really worth it. Nothing zebracorns-level by any means
We did just get a LiDAR, though, and have got some basic SLAM running, but that’s a whole different story… Hopefully we can strap it on the robot and upload the code within the next few weeks to see how well it does or doesn’t work.
Thank you for your code release! I had been toying with converting our team’s code to Kotlin, so it’s interesting to see how you did things. I’m also curious about if you plan on using IDEA next year, given that VS Code is going to be the new standard, and from my experience it doesn’t quite pick up gradle dependencies for its intellisense yet.
One suggestion I have - you link to sertain’s JavaDocs, but there are no descriptions/documentation for any of it in those docs. Those would be really helpful for pointing people in the right direction for where to get started. From what I could see from a quick glance, you came up with a similar notation that we did for declaratively creating CommandGroups, which is encouraging to me, though I’m not quite sure what your “mirror” and “bridge” commands are, or how they’re meant to interact with core WPIlib.
We love IDEA/IntelliJ and definitely plan to continue using it. Every IDE has its use, and IntelliJ exceeds at usability with Java/Kotlin/Gradle. That said, most of us do use VS Code for everything non-Java/Kotlin, such as our vision and other coproccessor code.
Thanks for the suggestion! Yea… we’re in the process of cleaning it up a little. CommandBridge really shouldn’t be accessible, and most of that is all internal hacking to get around some weird WPILib stuff. We’ll add some examples and step-up the documentation over the next few weeks!