Go WPILib #2982
-
|
Hi, I'm a member of FRC team 5340 @fairmingos, and I've been looking into potentially writing a Golang implementation of WPILib, but I'm having some trouble figuring out where to start. I've been combing the C++ source looking for some hint at what the actual underlying process is that allows the robot to communicate with the driver station, but no luck. Furthermore, I realized that I don't know the first thing about how the RoboRIO performs this task on startup. I'm guessing that a fair amount of this nitty gritty is baked into the RoboRIO image, and is therefore under National Instruments' jurisdiction, but that doesn't really clarify how one can interface with it. It also really doesn't help that half of C++ syntax looks like gibberish to me (I've only done Java and Kotlin for FRC programming). My question is, is there anyone who'd be willing to sort of give a brief overview of the inner workings of WPILib?I'm particularly concerned with what goes on at the boundaries. In other words, it's not terribly difficult to figure out how to implement the IterativeRobot class, for example, on the surface. As I dive deeper down the source code rabbit hole, however, I encounter dead ends and obscure syntax that make it extremely difficult for me to figure out how this code is interacting with the Driver Station on even the most basic level. My general perplexments:
I think it would be really cool to implement this stuff in Go. It's an awesome language that, in my opinion, provides the best of both worlds in terms of being both high level and low level. It is extremely type safe (if you're not using hacky unsafe features), functions are first class objects, there are no 'classes' in the traditional Java-esque sense, but you can attach methods to types, which allows for the same kind of state encapsulation, and it's garbage collected. But you don't have to care about Go to understand why I want to write my own implementation. It's just fun. What better way to learn about robotic software than to pick apart WPILib? I know that @auscompgeek has experience in the robotpy project and has tried a Rust implementation, so their input, if available, would be most appreciated. I hope this isn't too much of a bother or an unreasonable request 😂 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
Lots of questions to go over, so I'll start with the simple ones and where to go from there. To start with, for interfacing with the roborio hardware and DS directly, all the headers for doing that are found at https://github.com/wpilibsuite/ni-libraries/tree/master/src/include But, even that is pretty low level, and the FPGA is even trickier as its C++ exports and not C exports, which are much harder to interface with. The DS interface itself is not documented, and also all the ports are already attached to by the netcomm daemon, so you can't directly interface with them anyway. Its custom UDP packets. Instead of starting at that level, I would recommend looking at the HAL interface we have in WPILib. This is an object like C API for interacting with all the hardware functionality. That is deployed with any WPILib code, and all the interfaces can be found at Basically, to use that, you need to call HAL_Initialize(500, 0), and then any other functions can be called to get anything else you need. The headers there have function documents for what each thing does, and has access to all the hardware and the DS. Its definitely the best place to start, as its a simple API that gets rid of much of the complexity, especially in the IO. For starting programs, at startup the robot runs a file called |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! That was about 100x more helpful than an hour's worth of Googling and finding nothing but beginners tutorials on FRC Robot Programming. I'm somewhat disappointed to learn that the networking stuff at the lowest level has a proprietary aspect ;-; I suppose the most disappointing thing to take away from that is that it seems @qhdwight has a repository called frc-go in which he's already quasi-implemented the HAL API, but it appears a bit rough around the edges. Then again, it's hard to smooth the edges when you're dealing with C interop. Basically, my goal is to create a sort of custom API for my team that is as pure idiomatic Go as it can get, not because I think there's anything wrong with WPILib as is, but because I think it would be neat to try out a different paradigm. (TL;DR) My biggest beef with the way FRC programming is commonly done is the big push to use the TimedRobot class and the 'Command Based' project structure, for fear of getting your hands dirty in the lower level stuff. It makes me wonder what TimedRobot does beyond providing nice little 20ms loops for each of the different modes. Or what does the Command class do aside from make your code hyper-dependent on a little abstract class that could be implemented easily yourself in exchange for a heck of a lot more clarity? But these things are great for standardization. It makes each team's code follow a similar structure, and that has value. On the other hand, it's a whole lot of abstraction, and what are we doing here if not learning about robotics? It's crossed my mind over and over again, as I'm sure it has for many an FRC programmer, what does this actually do? What is the actual relationship between the software I'm writing and the hardware on the robot and the joystick connected to the computer? It's a tricky balance between making it easy for new people to learn and making it robust and generic. I'm concerned that it's moved too far in the direction of user-friendliness, and it feels more like we learn to write WPILib code or 'FRC' code, if you will, than writing something that's generally applicable to robotics. I think it would be neat if there were a more clearly documented pathway to not use the built-in IterativeRobot class, for those of us curious about what's going on under the hood and how we can best customize our code. I understand for the purposes of competition it's most important to keep everything as standardized as possible, so it's a really good idea to have the whole TimedRobot thing as the de facto. After all, I'm sure most high school students who walk in wanting to program the robot haven't the faintest idea about the nuances of software architecture, and the Command Based paradigm is a really easy place to start. I was just amazed at how difficult it was to find anything written online about what exactly WPILib is or does on a level lower than "it's how we write our robot code". Anyway, thank you again! You rock! |
Beta Was this translation helpful? Give feedback.
-
TimedRobot does mainly just that. Most of the heavy lifting is done by IterativeRobotBase::LoopFunc, which mostly involves calling LiveWindow, Shuffleboard, and Watchdog functions on top of the normal virtual functions for each mode.
I'll link to my CD post on pretty much this exact subject, rather than repeating it here, because I think it encompasses what my perspective is on this topic.
The software (at least WPILib) is completely open, so anyone who wants to understand how it works deeper is free to dig into the guts to see how things work under the hood. The source code is even "clickable" in vscode so you can directly drill down that way too. We do have an example program showing how to write a program without using IterativeRobot, HAL, as well as a template that doesn't use it. |
Beta Was this translation helpful? Give feedback.
-
|
I had forgotten about this, but you might find this useful: https://github.com/qhdwight/frc-go .. not sure how far they got |
Beta Was this translation helpful? Give feedback.
-
|
It was more of a proof of concept. By no means a complete library, more of a playground. Definitely a lot of room to improve, I just did the minimum to get it up and working on the bot (drivetrain with talons). Some more idiomatic bindings would be great to see! |
Beta Was this translation helpful? Give feedback.
Lots of questions to go over, so I'll start with the simple ones and where to go from there.
To start with, for interfacing with the roborio hardware and DS directly, all the headers for doing that are found at https://github.com/wpilibsuite/ni-libraries/tree/master/src/include
But, even that is pretty low level, and the FPGA is even trickier as its C++ exports and not C exports, which are much harder to interface with. The DS interface itself is not documented, and also all the ports are already attached to by the netcomm daemon, so you can't directly interface with them anyway. Its custom UDP packets.
Instead of starting at that level, I would recommend looking at the HAL interface we h…