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.

[alex-spataru]

@Redrield Ok, for the moment I will be working on fixing current issues and provide a "legacy" version of the QDS for users that need support for the 2014 and 2015/16 protocols. Afterwards I will check ds-rs with more detail and begin integrating it to the QDS with git submodules (so that any changes that are made on your repo are replicated in the QDS repo).

Thank you very much for your support!

[alex-spataru]

Update: I just received a PR from @Boomaa23 (FRC-Utilities/LibDS#11). It implements the 2020 protocol, I will be integrating it with the QDriverStation shortly.

@Redrield I'll rename this project to "QDriverStation" again, the QDriverStation/rs_ds implementation with your library should have a new name to avoid confusion with users (name ideas are very welcome). On the long term, I think that the rs_ds should be used instead of the LibDS, since it uses a safer programming language.

[Gautam-C]

Wondering if anyone else has gotten the 2020 protocol working. I just tested it on mac, but I couldn't get the robot to even be recognized by the computer.

[Boomaa23]

My apologies if it doesn't quite work, I wrote the 2020 protocol from some Wireshark captures I got in March, and haven't had access to a robot since then. I'll probably have access to one in January so I can try to fix it then.

Robot connectivity issues might not be the fault of LibDS though.

[Gautam-C]

Gotcha, just making it known.

[alex-spataru]

Update: Hope everyone is safe & doing well with the ongoing pandemic. I just added support for building and deploy this project with GitHub actions, I also made some fixes for newer versions of Qt & MSVC. You can check the build process here, and you can download the build artifacts for each commit from here.

I also created a new release with the latest changes, hopefully this can help us to test new changes. Stay safe!

[imreallyliam]

Will try this out on an actual robot and report if it works or if I had to call emergency services

[alex-spataru]

Will try this out on an actual robot and report if it works or if I had to call emergency services.

I would strongly recommend you testing on a spare RoboRIO that has no connection to any motors/actuators first. If things go smoothly, we can start improving the protocol based on your observations.

When I had access to FRC parts & robots, I always put the spare robot over some crates to avoid breaking a window or hurting someone while I did protocol testing.

Wireshark captures from both the official Driver Station & from the QDriverStation would be greatly appreciated!

[imreallyliam]

I would strongly recommend you testing on a spare RoboRIO that has no connection to any motors/actuators first. If things go smoothly, we can start improving the protocol based on your observations.

When I had access to FRC parts & robots, I always put the spare robot over some crates to avoid breaking a window or hurting someone while I did protocol testing.

Wireshark captures from both the official Driver Station & from the QDriverStation would be greatly appreciated!

Luckily we have a crate setup, and yeah I'll that information. Anything is an improvement from my Windows VM

[imreallyliam]

It appears that connection is impossible. Have tried to ping the roboRIO and it is connected, SmartDashbord does work along with the joystick but it just isn't able to connect. Currently unable to use Wireshark but will do when I can.

[alex-spataru]

Well, it happens, nothing ever works on the first try.

Please let me know when you have the Wireshark captures, also a screen recording or log with date/hr/min/secs of the FRC Driver Station running (while Wireshark is capturing on the background) would really be helpful. This allows me to know what did you do with the FRC Driver Station and how it affected the packets/frames that the DS sent to the robot.

For example, if I know the exact time in which you pressed the enable/disable button, I can know which frames in the Wireshark log are related to the enable/disable event. In turn, this allows me to "reverse engineer" the DS protocol, since I can compare the frames with the DS events & state of the robot and figure out how the protocol works.

[KenwoodFox]

My team does all their dev in linux, and we use vms for running driverstation. I think we'd be interested in helping out if we can, having a native solution would end our need for vms, is there a place to get started?

[sipmine]

Is there full support for FRC 2020 ( Wpilib ). I use vmx pi controller. My os Ubuntu

[KenwoodFox]

We've been using it and it seems to work ok with only a few bugs, using the 2020 robotpy wpilib @sipmine https://pypi.org/project/wpilib/2020.3.2.0/

[sipmine]

We've been using it and it seems to work ok with only a few bugs, using the 2020 robotpy wpilib @sipmine https://pypi.org/project/wpilib/2020.3.2.0/

I use java wpilib.

[KenwoodFox]

We've been using it and it seems to work ok with only a few bugs, using the 2020 robotpy wpilib @sipmine pypi.org/project/wpilib/2020.3.2.0

I use java wpilib.

¯_(ツ)_/¯

prolly works the same~

[sipmine]

How fix buffer overflow detected?