As you might probably guess, a lot of development on WPILib and related FRC software tends to happen in the summer. That means NOW is the best time to get WPILib developers thinking about what improvements need to be made for the 2019 season. While WPILib developers are active on CD, the best way to do this is file issues on github!
Of course, not everything is a good candidate for inclusion into WPILib: mind the contribution rules! We would also love to see more pull requests and code contributions from community members – once again, see the contribution guide.
More community involvement in WPILib development is a Good Thing. Thanks in advance for helping to make WPILib and FRC software better for all teams!
The one improvement I can think of is an easier way to communicate with coprocessors. Although it is already possible to do this with the networktables class, it is hard to set up in my experience and at competitions most of the teams I talked to who also had coprocessors said that they switched to using sockets instead of networktables because of latency and setup issues. Because there are coprocessors in the KOP and since most teams find the WPILib implementation finicky and slow I think it would make sense to improve WPILib here. I’ve only been using WPILib for a year so this may be a bad idea for some reason, but I feel it would really help if WPILib had a class that creates a socket server on the rio and is designed to be easy to use. That way teams can skip half of the issues they already have and only have to focus on getting a socket client working on the coprocessor. For my team’s robot this year I used the C++ networktables class on the roborio to create a server and the pynetworktables implementation on a Jetson and it just felt like the experience could be improved. I constantly had issues with failed connections, high latency, and it just simply not working sometimes (even when I didn’t change anything). I know it’s a stretch and probably isn’t worth doing anything about but because you asked this is my suggestion for WPILib this year.
Contrary to the above. I’ve had no issues with my Raspberry Pi3 Co-Processor and Network Tables itself. I’ve had a ton of issues with the new Shuffleboard not properly re initializing Camera Feeds as well as it just freezing and not wanting to get any Network Table data until reboots. I want more stability in Shuffleboard.
We used ZMQ this year (well, to be precise, protobuf over ZMQ), and it was extremely easy to get up and running.
Edit: Also, I’d just like to give a big shoutout to the WPILib dev team for being timely in responding to issues and very receptive to suggestions for better API design. I’ve been extremely impressed with how WPILib has come along in the past couple years.
Regarding socket servers: NetworkTables (NT) is just a layer on top of sockets, so switching to a WPILib official socket server isn’t going to fix anything (and in fact makes a lot of things worse). I suspect the reason teams switch to socket servers (or zeromq for that matter) instead of using NT is generally because they feel they have more control over it and they feel its easier to diagnose issues when they occur.
Regarding latency: the documentation for NetworkTables isn’t as clear as it should be, but by default it sends data every 100ms. You can change the settings to as little as 10ms, which is good enough for most teams. Measurements we’ve done indicate that the latency is pretty stable.
Regarding finickyness: I’ve never actually heard this complaint, what do you mean by finicky?
Regarding the Jetson: One other user reported a pynetworktables issue related to this. However, since nobody else reported an issue, it was thought to be an isolated problem. I wish you had reported your issues on github about your problems, and perhaps we could have had more data to figure out what the problem was.
Finally: Obviously I’m biased, but I’ve always really liked the key-value abstraction that NT provides. While it’s not a perfect fit for all users, I believe many of the problems people have with NT tend to either that users don’t actually understand how it works, that the documentation has been slow to document how it works, or that the applications they’ve been using with them have limitations because the authors didn’t understand how NT is supposed to work.
Prior to ntcore (2015/2016?), NetworkTables was a nice abstraction that had absolutely terrible code underneath the hood. After the rewrite, it’s worlds better and has had fewer issues than the original codebase. It’s not perfect. There are tradeoffs that have been made. There are still some things that could be improved (particularly in regards to documentation).
For the issues that remain – I’d like to see more community participation in making things better. The source is there to go look at. If someone thinks there’s something that sucks or is buggy – good, go diagnose the bug, make a pull request, and let’s fix it for everyone. Collaboration is a core value of FIRST, and particularly with regards to software its so much easier for people to do so – and yet we don’t collaborate nearly as much as we could.
For the last few years, from within I’ve been personally advocating the WPILib team to be more open to community participation (as have others). I think it’s better than it used to be, and will continue to get better.
Caveat: please don’t interpret this as trying to discourage teams from coming up with their own solutions to common problems. I think it’s good for community members to do innovative things like try out cutting edge technologies, and if successful try to bring those technologies into greater use.
Improve FRCSim or work with the Synthesis team as well as NI to create an ultra-realistic and easy to use simulator that allows teams to easily import models from Solidworks, Inventor, or Onshape (maybe use universal STEP-based imports and then have an importer program that allows the user to define points of motion, etc), as well as code from the 4 major languages (Python, Java, C++, LabView) with support for the Talon SRX/CTRE libraries. We’ve tried both Synthesis and FRCSim in the past but have ran into problems that we simply don’t have time to solve during build season, which defeats their purpose. I understand the monumental amount of work required to make one of these simulators work, but it would be incredibly useful if the barrier to entry was low.
a quicker way to clear a graph that is displayed on the smart dashboard.
idk, the whole proccess of pressing ctrl+e, right clicking etc is a bit exhausting, but we are probably just really lazy
seriously tho, a “clear graph” button will save so much time when tuning PID.
This would be awesome to see, but extremely challenging.
One of our top summer projects is to get at least a 2d drivetrain simulation going to help design & validate autonomous next year. Much more low-bar than the full model import with accurate physics, but hopefully “enough” to be useful and reusable year to year.
What about the usage of shared_ptrs in the c++ templates? I don’t really think shared_ptrs should really be used at all. I would rather have just an instance of the object on the stack
I love the thoughts, keep them coming! But… while posting them on CD is good, it is not sufficient.
As mentioned in the original post, please file issues on github (or add a +1 / thumbs up to an existing issue). That is the best way for these things to not get lost and never seen again.
Our team has made good use of I2C communication out to coprocessors, sensors, etc.
In WPILIB, the I2C class contains a little javadoc saying that “It probably should not be used directly”. I suggest either deleting that comment, or perhaps have an I2C expert rework the code as needed.
The C++ templates already don’t use std::shared_ptr as of the 2018 season. In fact, only RobotBuilder still generates code that contains std::shared_ptr. We’ve wanted to fix this for at least a year now, but the few people who understand how RobotBuilder works don’t have time to update it.
The full text is “This class is intended to be used by sensor (and other I2C device) drivers. It probably should not be used directly.”
I think the intent is that teams should not call the I2C class directly from Robot.java. For example, if teams want to use a lidar that uses I2C, they should create a driver (Lidar.java) that uses the I2C class, and then call the Lidar class from their robot code.
Suggestions on how to make that more clear (and better yet, pull requests) are appreciated.
