For our Worlds robot, we wanted to move back to a flywheel design after running into some issues with our slingshot. We started by looking at what some other teams had done and decided to base our designs on that.
We started by building on the old copy of our chassis we still had laying around, so we could know if this was going to work before we completely dismantled our robot from States.
This is our team’s engineering notebook as of States 2023. We declined to update it further after this.
Doom on the V5 has existed for around 5 years at this point, I believe the original project was by sealj553.
This original port of doom to the V5 required both an SD card, and was also limited by the existence of the program bar which takes up 32 pixels at the top of the brain’s screen.
My version is the original modified to run into neither of these challenges. For what should be obvious reasons, I’m not releasing the source code, but I will provide the pre-compiled binary that anyone can download to their V5.
VEXos 1.1.2 introduced a new ability to control WS2812B addressable LED strips directly from the ADI on the V5. Previously this was semi-possible by bit-banging with APA102C strips, but the speed at which the V5 could send data to the lights was far too slow to be workable in any real application. User code, that being the code that runs on CPU1, is limited to updating the state of the ADI every 10ms. The protocols to drive lights require much faster timings than that to work properly, so until firmware was added to drive this directly from CPU0, controlling addressable lights wasn’t feasible.
After reffing at my fair share of VEX tournaments in recent years, I’ve come to determine that I’m really not a fan of the web interface that is used to start/stop the match timers. Holding a phone or tablet like that in my hand for a long period of time is very bothersome to me and I wanted to design a better solution that would make the experience more bearable :3
pros c fetch sylib@<version>.zippros c apply sylib@<version>main.h file, make sure to include sylib/sylib.hpp/include/sylib/env.hpp make sure that SYLIB_SRC_PRESENT and SYLIB_ENV_VEXCODE are not defined, and that SYLIB_ENV_PROS is. This makes sure that the right headers are included, and that sylib uses the pre-compiled library provided by the template instead of trying to build it from the non-existent source (which would not compile in a PROS environment anyways).initialize() function, make sure to include sylib::initialize();note: Sylib requires PROS kernel 3.7.2 or later to run, and is not currently compatible with PROS 4