I’ve begun porting the WPILib ( GitHub - wpilibsuite/allwpilib: Official Repository of WPILibJ and WPILibC ) to V5. While I don’t have direct experience with FRC/FTC, my impression is that their programming community is much more open and collaborative than VRC’s, and would like to see that ethos come to this community.
The reason I chose to port WPILib is that it’s extremely well thought out, has high code quality, and provides a robust feature-set. I’m particularly taken by their Mission Statement in regards to raising the floor, not lowering the ceiling ( Contribution Guidelines — FIRST Robotics Competition documentation )
I have departed from WPILib’s implementation of units-of-measure, favoring the approach taken by OkapiLib, leading to a number of small changes in implementation but not functionality.
I would suggest users start from one of the example projects rather than jimmy with the makefiles, since the example projects already have the makefiles set up properly.
I’ve physically tested some basic elements on a differential drive train. I’ve not tested any of the Mecanum (which works on X-Drives) code yet.
This is also an ask of this community to help support this project, either through feedback or code contributions.
First off, you’re technically violating the license of both WPILib and OkapiLib. In both cases, you have to leave the original copyright header intact. Furthermore, you can’t just change the name mentioned in the copyright header to your own. The correct thing to do if you’re modifying those files is to prepend your own license above the old one.
This feels less like a WPILib port and more like it was “inspired by” WPILib. Some classes were copied from wpilibc and wpimath as-is, but there’s a lot of stuff missing, and there were so many additions and changes that don’t follow the original design intent that I’d almost call it a different library. Here’s some of the things I noticed. (Hopefully in a follow-up message because the forum says I can’t post more than two links in a post as a new user.)
Fair points; will modify copyright notices per suggestion.
I’ve not gotten to the the WPI thread implementation so I’m not entirely sure at this point how it aligns with what is possible on the V5 Brain. As you note, the environment only supports c++11, which has led to a number of changes, particularly with templates.
The majority of FRC code uses cooperative multitasking on the main thread for concurrency instead of separate threads. Here’s how it works.
A Notifier context contains a condition variable (CV) and a wakeup time. The HAL Notifier API maintains a priority queue of Notifier contexts sorted by soonest wakeup time. Threads wait on their context’s CV for their time to run. The roboRIO’s FPGA timer interrupt is set to fire when the soonest wakeup time occurs. When it does, the context’s CV is notified so that thread can run, the context is dequeued, and the interrupt is set to fire at the next soonest wakeup time. Periodic tasks re-enqueue themselves with a later wakeup time.
TimedRobot runs multiple callbacks on one thread of execution by making one Notifier context and maintaining its own priority queue of callbacks and wakeup times. It’s done this way because it saves on HAL resources (only one CV per thread of execution, for example).
There’s a Notifier class that wraps the HAL Notifier API in a thread, but that’s rarely used anymore.
Thanks; this is definitely a bit I’m not looking forward to, is how to integrate this model into the V5’s threading model. It’s certainly possible it’s very easy, and my concerns are overblown, but I’m concerned that this could be where some dragons lay.
While I’ve not used the Command-based programming model, it looks nice and clean. I’m a bit concerned about the learning curve that VRC programmers may have, especially given that the 3 main programming environments provide methods akin to driveTrain.turnToPoint etc. and I wasn’t sure what the best bridge forward would be, so I resorted to enabling a similar interface.
yea, some things may not port directly. The V5 (running a VEXcode program, PROS is using FreeRTOS) only supports cooperative multitasking, and the threads have certain characteristics to allow them to tolerate the common mistakes that students make (ie. treating a thread like a function and calling from a loop). But we also have other little discussed capabilities that may make implementation of a notifier easier, namely the event system and timers that can cause a cooperative thread to run.