Project Status

[BearzRobotics]

So if this is to survive it will require people who currently are on a team weather a student or mentor to continue its development. Would it make sense to reach out to the community through things like chief delphi to help find new devs?

[kohlerz]

I'd be willing to help. I have limited c++ experience, so I would have to start with solving a few small issues, but hopefully, we can get repo back up and follow along with the new releases of DriverStation.

[BearzRobotics]

Alright, the DriverStation is made up of 2 projects. QDriverStation and LibDS. QDriverStation is written in c++ with the qt framework and LibDS is written in plain c. The biggest problem is Alex is in collage and I been out of school for two years now, so neither of us have access to a roboRio to get the necessary info to keep the project going.

[kohlerz]

Sounds good. I'm going to finish up my personal projects in the next few weeks, and then I can start focusing on this. Build season does start very soon though, so I will probably update the repo for 2018 and 2019 after build season ends (if I can figure it out).

[BearzRobotics]

So for those interested in continue development we should look at ntcore. From reading the doc they moved to a lib 128 encoding for data which could be the cause of the major breaking. Though this lib is how the bot communicates with everything.

https://github.com/wpilibsuite/allwpilib/tree/master/ntcore

[BearzRobotics]

So from looking through the docs the robot uses TCP, but when messing around with the qdriverstation and wireshark it appears were using the UDP protocol.

[Redrield]

Most of the control between robot and DS happens over UDP. Certain actions like sending game data and match/competition info happens over TCP.

To the issue of QDS, I have a driver station supporting the 2018 protocol that supports joysticks here. Unfortunately it's *nix only. (Linux only at the moment because the joystick input library I'm using crashes under macOS).

[alex-spataru]

Any updates on this issue? :(

[kohlerz]

Sorry, my team kind of fell apart this year :(. We're based at a university that has a lot of covid rules this year, and high school students are not currently allowed to go to meetings. I'll look into getting a RoboRIO and updating the protocol though. I'll try and let you know if I am able to figure it out.

[alex-spataru]

Yeah, the pandemic changed a lot of things everywhere. The economy down here in Mexico got hit pretty hard, I have several post-college friends in the aerospace industry who where fired in order to reduce operational costs. But at least I got a job as a web developer, which should help me until I finish my studies and get a proper job.

Anyway, I found out that some of the people who forked LibDS have worked on the implementation of the 2019 comm. protocol, specifically:

• Booma23's LibDS fork
• Team 3487's LibDS fork

Maybe we can work with them in order to make this project relevant again. I'll tag their accounts to see if we can get some response from them:

@booma23
@Team3487-RedPrideRobotics

I recall using the FRC Simulator that came with LabVIEW to test the QDriverStation, the only requirement is to launch the simulator and set the robot's IP address to 127.0.0.1. However, I don't know if the simulator has been updated to work with the 2019/2020? WPILib & comm. libraries.

Hope everyone is safe & doing well.

[solonovamax]

I'd love to contribute to it, though I have zero access to a roborio and I'm a java dev, so c++ is way out of my scope. (and I cba to learn a new language right now)
Might rewrite it in Java with JavaFX though, since java is pretty pog.

Also, team 3487's fork you linked there is now deprecated, so you might want to add a strikeout or something to it.

[Redrield]

I'm currently maintaining an open-source DS Conductor that works with 2020 robots. It implements all the safety features of the NI DS (such as grabbing disable keybinds regardless of window focus) and functions on macOS and Linux. the backbone of this is the ds-rs library, a cleanroom implementation of the protocol in Rust. The Rust library also exposes a work-in-progress C interface under the libDS directory. Some other efforts to create driver stations using this platform can be found at https://github.com/thirdparty-ds/.

[alex-spataru]

@Redrield Thanks! I'll check it out later this evening. Do you mind if I use your work as a reference to create the initial implementation for the 2019/2020 protocol in LibDS?

[Redrield]

I don't mind but I also feel like it would be more valuable to put time towards one library, rather than creating several of various degrees of maintainedness

[alex-spataru]

@Redrield Maybe we can work to integrate your library with the QDriverStation. LibDS (the version that its now used in the QDriverStation) is written in plain C, and has several problems with managing sockets in a cross-platform way. I feel that by using the ds-rs library we can overcome this and many other issues.

Also, many of the limitations of C are compensated with custom-built code (e.g. queues, arrays, event management & string handling). Taking a look at LibDS with my current experience, I concluded that my "hacks" are probably not the best, nor the safest way to implement a library meant to operate possibly dangerous robots.

If you want, we can collaborate on finishing the C interface of your library, and then we can integrate the interface with Qt (and thus the QDriverStation).

By doing this we have the following advantages:

• We maintain the existing UI of the QDriverStation (which has almost all the features of the FRC Driver Station).
• The ds-rs is written in a programming language that is safer and has more features.
• Since you are an active member of the FRC community, the project could remain active for a longer time.
• The QDS is/was relatively known among the FRC community. A Reddit and/or ChiefDelphi post should be more than enough to regain exposure and make the project relevant again (thus more bug reports and possibly more devs).

If you are interested, please let me know. If you wish, I can give you access to the FRC-Utilities organization and integrate your current work (so that more people can work on the same project without the need of constant pull-requests, and for your FRC-related projects to gain more visibility to the community).

[Redrield]

I'd be happy to help integrate ds-rs into QDS, and I'd also like the help in figuring out a good way to expose its full surface area to C. You can add me to the organisation if you'd like, but I don't plan on moving any of my DS-related projects over.