Hardware Client for Linux/macOS?

[qwertychouskie]

I know this has been brought up before, but is there any ETA on a Linux (and Mac) release? Many programmers exclusively use Linux or macOS as the development environment is leagues better. Having to find an old Windows system just to update the OS/firmware of the Rev hardware is extremely sub-optimal. (For example, of the 3 programmers on our team, only 1 is still on Windows.)

[qwertychouskie]

Also, if you need any help testing, I'm happy to help (exclusive Linux user myself).

[NoahAndrews]

Unfortunately we don't have an ETA, but it's still in the plans.

[NoahAndrews]

It's worth noting that you don't need to use the REV Hardware Client to update the Control Hub OS, Driver Hub OS, or Expansion/Control Hub firmware. Since FTC teams are not required to use Windows for any reason (unlike FRC teams, unofficial tools aside), we've made sure that every single thing you can do to FTC hardware using the REV Hardware Client can also be done without it.

You can update the Control Hub OS from the Manage page. You can update the Expansion/Control Hub Firmware from the Manage page or Advanced RC Settings in the Driver Station app. You can update the Driver Hub OS from the built-in Software Manager app. You can program your Control Hub using Android Studio, the Blocks page, or the OnBotJava page.

For FRC teams, you can technically even update the Power Distribution Hub, Pneumatic Hub, and SPARK MAX from Linux (and probably macOS) by putting the device in recovery mode and using dfu-util, but that's not officially supported.

[qwertychouskie]

This came up again recently with another student being unable to run the Hardware Client (https://www.reddit.com/r/FTC/comments/w748dn/support_rev_hardware_client_on_linux/)

Does there happen to be any ETA on this? Or even a source code repo for the Hardware Client, so the community can port it?

As Linux is extremely prevalent in development and STEM field, and also becoming more common in the mainstream with e.g. the Steam Deck, having the official Rev Hardware Client only work on Windows just feels like blocking a large portion of the community from being able to use the software. Also, Chromebooks are the de-facto standard in schools nowadays, and most Chromebooks can run desktop Linux apps, so a Linux app would also address most Chromebook users.

[ghost]

It's worth noting that you don't need to use the REV Hardware Client to update the Control Hub OS, Driver Hub OS, or Expansion/Control Hub firmware.

You can update the Control Hub OS from the Manage page. You can update the Expansion/Control Hub Firmware from the Manage page or Advanced RC Settings in the Driver Station app. You can update the Driver Hub OS from the built-in Software Manager app.

Technically, you can even update the Power Distribution Hub, Pneumatic Hub, and SPARK MAX from Linux (and probably macOS) by putting the device in recovery mode and using dfu-util, but that's not officially supported.

It is mostly the thing that in my team we are actually people with Macbooks or Linux laptops ( Yes we don't like windows for many reasons), and we cannot emulate the REV HARDWARE CLIENT and we also cannot port it, so the only way it to use an annoying VM or find a way to send our code to the control hub directly.

[Windwoes]

or find a way to send our code to the control hub directly.

You do not need the hardware client to program the Control Hub.

[KenwoodFox]

My team also is a linux/bsd focused team and i really like what you said about chromebooks too. Porting an app can be a lot of work, maybe adding a section to the docs to make dfu-util maybe not offical but, more well known. Using an external tool like that could be our community contribution

[ghost]

or find a way to send our code to the control hub directly.

You do not need the hardware client to program the Control Hub.

idk our coach said that we need the rev hardware client to create code ( with blocks or onbot java ) and send it to the robot.

[NoahAndrews]

or find a way to send our code to the control hub directly.

You do not need the hardware client to program the Control Hub.

idk our coach said that we need the rev hardware client to create code ( with blocks or onbot java ) and send it to the robot.

You can also program in Blocks or OnBotJava by following these instructions to connect your computer to the Control Hub's web interface: https://docs.revrobotics.com/duo-control/control-hub-gs/connect-to-the-control-hub-robot-control-console#web-browser

[ErikSRoth]

So, our FRC team is doing all the coding from macbooks. I am hoping that a mac/linux version of the hardware client is still on the roadmap. The only windows machine we are using is for the drivestation since there is no FrC legal alternative for mac/linux (which I will be bugging FRC about). If this is still in the works, I would be willing to beta test for it as currently on a mac I use Parallels to run a virtual windows box for the Rev hardware client and a couple of the FRC tools. Currently we are using the Rev Spark Max controllers over CAN for the brushlees and PWM for the brushed. I was looking (and have not found) and documentation for a web interface for the Spark Max. If there is one a link would be appreciated. While the FRC is great for kids to learn and participate in, I feel that the lack of support for anything other than windows is not giving the kids a wide enough learning experience based on what they will face in the real job markets. Just my 2C ::sunglasses::

[KenwoodFox]

My team is 100% linux, we have a virtual machine running on one of the servers that runs windows so we can use stuff like the imaging tool and other NI tools, also the rev hw client. we use qemu for USB passthrough to the spark maxes and the rios.

[InfinityDevTech]

+1 Would love to see a linux client.

[qwertychouskie]

Just wanted to check in and see if there has been any progress on this front. Given that much of the client is built around open-source/cross-platform technologies (Chromium/Electron, JS, adb, libusb, etc), porting some, if not all, functionality to other platforms should definitely be viable.

I would love to try to port it myself, but unlike the old SPARK MAX Client, the Hardware Client sadly doesn't seem to have the source code publicly available. If you are interested having the hardware client ported, hit me up :)

[CamoCatX]

I would also like to see a port to nix (meaning, UNIX and UNIX-like operating systems, such as chromebooks, Macs, and Linux) OS's. As a programmer I see a lot of other tools for the technical-savvy already on nix. Or even, made for it. On other robotic tools, (such as ROS) it is literally for Linux. So a port (official or not) would be a favor for an already thriving community.

[xu-shawn]

+1

[papereater42]

+1

[KenwoodFox]

Haha yeah we use ROS and all our dev laptops are linux, atm as a work around, we use qemu/VMM to have windows VM copies with the rev tool on them

qemu lets u passthru the USB devices and for us its worked but, its like the only app left in the frc suite besides the driver station that doesn't work on freebsd/unix/linux nativly.

[CamoCatX]

Haha yeah we use ROS and all our dev laptops are linux, atm as a work around, we use qemu/VMM to have windows VM copies with the rev tool on them

qemu lets u passthru the USB devices and for us its worked but, its like the only app left in the frc suite besides the driver station that doesn't work on freebsd/unix/linux nativly.

I do the same thing. Although it has a lot if boilerplate, and seems unnecessary that I cannot even use it on Wine/PlayOnLinux. I am guessing that they will phase out Windows 10 support, which is much easier to use in a VM then Windows 11, with requires secure boot and all these other unnecessary features. (Read, they do not require it to be turned on, they just want it installed on the system, because it's the thought that counts :) ) Setting up secure boot in Qemu is a bit tricky.

[CamoCatX]

The fact that they have an open-source Linux kernel (https://github.com/REVrobotics/opensource.revrobotics.com) for the control hub on the same Github Group that owns this repository, with its first issue literally asking for Linux Support, is astounding.

[rmaizel]

Still hoping for REV Hw Client on Linux

[qwertychouskie]

Copying this from Discord:

From: @Iris-TheRainbow Hello from the Unofficial REV Port team! After some work, we are finally ready to go public with our first release. A collaboration between @Iris-TheRainbow, @j5155, @qwertychouskie, @Moose1301 , @Froze-N-Milk, @TBHGodPro, @dr-hextanium, and @warmpigman , we are proud to announce the REV Hub Interface - Community Edition! The REV Hub Interface is a piece of software intended to control a expansion hub through USB on a PC, but REV never released it for any platform but Windows. Now, we have a fully cross platform release with many improvements included.

With a modern UI, improved responsiveness of commands, a port from a 15 year old Python version, and many bug fixes, the Hub Interface has never been so useful.

As of now, releases are available with Windows, Linux, and Mac binaries, PyPI builds, with Linux Flatpak (a release on Flathub is to come). Our github is available at https://github.com/unofficial-rev-port/REVHubInterface, feel free to open an issue there if it would arise, as we are actively developing.

And:

Hello everyone! I'm sure y'all have heard about the ongoing project by the Unofficial REV Port Team. To learn more about our goal and our first release, please look at the announcement above.

We wanted to let y'all know that we have created and opened up a community server regarding this project and so if y'all want to discuss the project, get early access to announcements and updates, and have a better place to provide your suggestions for the developer team, please join the server using this link: https://discord.gg/9TgsNykAwf

Thank you for your time and we hope to hear from the community!

[Iris-TheRainbow]

Hey thats me! thats just the RHI but HWC is hopefully coming soon ish maybe

[warmpigman]

Jeepers that's nifty!

[qwertychouskie]

Work is coming along well on adding macOS and Linux support to the core libraries used by the REV Hardware Client, see https://github.com/REVrobotics/CANBridge/pull/29 and https://github.com/REVrobotics/node-can-bridge/pull/21 for details.

[KenwoodFox]

Thats super awesome to hear @qwertychouskie, hope those come along. Anything we can do to help/submit code?

[qwertychouskie]

Thats super awesome to hear @qwertychouskie, hope those come along. Anything we can do to help/submit code?

We'd be happy to have you in our discord server if you're interested in helping out the project. https://discord.gg/DH7qSvY36V

[Cuadritosuwu]

+1

[ofluffydev]

The official Rev team should show support. The Linux kernel and the operating systems built around it are a profound example of open-source development, and supporting them would show Rev's philosophy of supporting FOSS and community-driven development.

Keeping it only supporting Windows disregards millions of people, FTC participants or not, and limits teams that do not have the resources for a powerful machine. This is due to the newer windows' bare minimum running requirements. Where Linux works great in a single board computer with 2GB of RAM and a 1ghz CPU, Windows demands at least 4GB. It also requires the x86_64 (or AMD version) to run. A final "cherry on top" is the structure of Windows drivers compared to Linux. Windows has many functionalities you cannot disable, which forces you to use a newer PC.

While I see, "it's in the plan," an insane change coming soon will likely demand Rev support this ASAP. As soon as Windows 10 hits EOL in 2025, many teams will be forced to use a more powerful machine or switch to Linux. To continue using the hardware client on a post-EOL machine, you will be open to security vulnerabilities.

As most of the profits generated come from the actual hardware, keeping the hardware client both proprietary and closed source doesn't make much sense anyway. If there are no resources or knowledge available to support Linux, let the community help. Open source the client, and allow actual pull requests, rather than just hiding the source from its users behind a repo with binaries .exe files.

The sad truth of this is, Linux support may even already exist. Unless the entire application is developed using Windows's APIs directly, many sources can be built on both Linux and Windows with small modifications. If it truly is limited to Windows, Linux's openness promotes development already and would be even easier than Windows. The entire kernel's source code is public, whereas Windows is not and you have to rely on its documentation.

Whether they like it or not, as shown in the previous comments, people need the support so badly that they will go as far as reverse engineering the entire application and building it for Linux. One of the obvious issues with this is time. The fact that Rev maintains their hardware client for teams, allows them to focus on the robots' programming and building. Without Linux support that time is lost, and teams are forced to find workarounds to use it, and not everyone can find a workaround due to it being designed not to.

I would love to see official comments from a staff/team member from Rev on this, and I am even open to helping create and maintain a Linux version of the client. My team is part of the people included in this issue, and the laptop that I use for developing our robot code runs on Linux. Android Studio works perfectly, even with full adb support, Rev Hardware Client could as well if effort is put forward into it.

Remember, just because one person can use alternative methods does not mean all can. While I can reverse engineer the control hub's operating system or even replace it entirely, this is not always possible. That requires knowledge related to Android that does not relate to FTC other than the fact that the system runs as an app on the Android OS. Even if I did that, it would immediately break the rules with FTC, and disqualify us.

[Iris-TheRainbow]

Hey @ofluffydev ! Ive got great news for you! As you can see from Unofficial REV Port's page, we actually are working with REV On getting linux support into the hardware client. We can't share everything we're working on, and currently the start of the FTC season is delaying our work, but things have come a long way. Most of what we're held up on is native bindings (GYP....)