FTC Team 16750 Progress Update

[kevinfrei]

We are a high school affliated team, and the hardware box arrived the day after our final normal team meeting prior to summer break. A few of us are going to try to meet over the summer to do a few silly things with this fancy new hardware. One of the mech students is going to CAD up a drive base, and I (Kevin Frei, lead mentor) will be going through initial setups on a Mac, Windows, and maybe even a Linux machine just for the lol's.

My plan while students aren't available is to move my silly little demo robot (aka Mouse) over from a control hub to the Hybrid control system initially. In the mean time, one of our students is going to CAD me an A301-based drivebase, and I'd like to build that up, too. He says "8 motor powered Mecanum will be fun" 🤣

One final note: Our team will be working in Java. That said, I'll be trying C++ if I get bored, cuz I like it more.

[kevinfrei]

Installation on Mac Feedback

(I'm starting on Mac, cuz that's what's on my lap right now.)

As a preface to all this, I understand that this is an alpha program. I've run alpha software before (i've worked on very large pieces of Alpha software, like, um, Visual Studio). My experience tells me that installers don't typically get much attention, so I'm going to be pretty blunt, because this process is quite bad, particularly in comparison to the very straight forward Android Studio experience for ControlHub coding. It's also bad considering that you're doing this on machines that people might want to do other things on. We're FTC: We don't run budgets where purchasing as extra couple laptops for team members is a rounding error.

(Mac-only) First of all, it's an installation app, and not just a 'drag to install' kind of thing on Mac. Okay, there are a few apps that have installers. But I sincerely worry about how this is screwing up my machine. I don't like needing to clean up messes from bad installers. This ain't windows. Lose 3 points.

Second: It's an installation process, but it CREATED A NEW TOP LEVEL FOLDER IN MY PERSONAL FOLDER NAMED wpilib WITHOUT ANY OPTION TO NAME IT ANYTHING ELSE!?!" Sorry: I'm very picky about how I have my systems configured, and building an installation process without bothering to allow me to put the folder somewhere, or even pick the name, is a really, really bad user experience. I want this stuff under my own subdirectory that I can put next to other things. Lose ten points, and know that I'm now triggered.

Third: the "Drag the VSCode app" to dock is really quite frustrating guidance as I already have a full copy of VSCode installed (because I write non-FIRST code on this machine: See first paragraph feedback), and it's named the same, and it's got the same icon, so if I do what is asked, I'll have no idea which version of VSCode I'm running. This is an unacceptable final outcome. If this is only for Alpha, that's fine, but if the plan is to have a separate copy of VSCode being the expected setup for release, change its name and icon. I know it can be done. If you don't want to do it, make wpilib 'stuff' a normal VSCode extension with some configuration like god intended. Lose 15 more points because I can't tell if which VSCode I'm using, and that's crazy-making.

Final Grade: 72% - a low C

Sure you're passing, but just barely.

[ThadHouse]

The thing is it’s not an application. If it was it’d be packaged as such. It’s essentially user data, not application. So we need a macOS user data path.

In the embedded world, the amount of different places all the embedded tool suites place their code is a lot, especially on macOS. We just need to find one, and if there’s no default it will probably just get hardcoded to ~/.wpilib

[calcmogul]

Application data typically goes in ~/Library/Application Support, and there's an API for retrieving the path: https://stackoverflow.com/a/8430843. That doesn't quite fit what we're doing though, and that's all I could find. Seems like Apple really intends you to install actual application bundles.

[kevinfrei]

I found a really simple solution to the "2 version of VSCode look the same" problem that I just validated. Rename the app container folder from "Visual Studio Code.app" to "WPILib VSCode.app". That's it. Nothing else. The icon is still the same, but the subtitle is the app name (WPILib VSCode) so I can now tell which one I'm tabbing to. The app continues to work just fine. The fact that you can do this to any app you want (except Apple's "special" junk-apps that you can't even remove without booting your machine into a bizarro safety-protection-override mode 😒 ) means it should be a viable long term solution. I'm not sure if you can do it before/during installation, but it's probably a good recommendation for anyone who is using a normal installation of VSCode.

[kevinfrei]

I guess one thought we could do is have a custom env var that could point to another folder too. But we have to be careful with configuration options, because we saw in the past users will very often choose the wrong options, and then we have to the triage everything. That’s why the installer was simplified to just be the options it was now. Something like that would 100% be a hidden by default option.

This is basically how every single build tool I've ever used does it. Everyone that makes build tools expects this. WPILIB_ROOT or something would probably be the "right" way to do it.

[kevinfrei]

I at least partially blame this on Unix, where the design decision to make hidden files be a folder name rather than a file attribute just shows a clear lack of thought by whoever designed that. Windows got this one right for sure, by making it an attribute.

lol. This particular "design decision" is actually just a little older than me 👴 obligatory wikipedia link. The only thing I hate about Windows' handling of hidden files is the default is that you have to specifically look for them, so most software fails to work if you mark their silly top level folder that's driving you insane as hidden.

[kevinfrei]

Installation on Windows Feedback

Oh, look. An .ISO. Why? Windows people don't do that much with ISO's. You know what Windows people are accustomed to? ZIP files. Yes, Windows 11 let's you just double-click the .ISO, but you get a security warning, then you get another security warning when you run the installer. Just package it as a ZIP file. Minus a tenth of a point, cuz this is just a weird choice, but it's fine. Actually, ISO's aren't compressed so you'd have a 180MB smaller package if you compressed it. Actually, if you delete those PDB's, you're getting most of the wins. Do that. I mean, I don't notice, but I have wicked fast internet. Most folks don't, so 180MB smaller for no real effort seems like a win. One more tenth of a point demerit.

It's not in a top level directory like on Mac! Hurray!

The fact that it's named the same isn't as big of a deal on Windows, because you're tabbing through open windows, not open applications, so I can see which thing I'm headed to pretty easily. That probably means it might make sense as a workaround for the truly infuriating Mac issue to install one of 10 or 15 different cmd-tab replacements. It's not great, but I know there are Mac apps that make tabbing more like Windows (and you can generally bind them to different keys: I'll dig one out after I've dealt with Linux...) I'll remove another tenth of a point, since I'm still frustrated by needing two full VSCode's installed. Stupid AI-induced storage demand.

The whole collection of stuff appears to live in \Users\Public\wpilib. This is a weird location, and annoying because it's "per user" but kinda not really. I don't yet know if I'm going to need to go to that directory on a regular basis from the command line, so I'll leave this one at full points for now. I'll try something before more feedback on this location.

The installer is ugly as sin. Lose 1 point. I probably should have ding'ed Mac for this, too. I'll just take points off Windows.

Overall grade: 98.7%.

Pretty solid, as far as basic usability and app install experience goes.

[ThadHouse]

Unless I’m missing what pdb you’re talking about. Which pdbs are we actually talking about.

[Gold856]

The ones that result from the installer being run through Native AOT.

[ThadHouse]

Oh. Yeah that one should be easier to strip. Its really 180 MB?

[Gold856]

Yes.

[ThadHouse]

Oh thats the avalonia PDB's. Gross yeah we need to strip those.

[kevinfrei]

Installation on Linux - nevermind...

Oh, it's only supported on Ubuntu. Ubuntu 26.04? Wait, wut? I didn't even realize that was out yet. And I've stopped using Ubuntu, cuz it's kinda fat, and kinda annoying, so I've switched to Debian 13 when I don't care about Ubuntu being kinda fat, and Linux Mint when I don't care about Ubuntu being kinda annoying. I don't feel like installing Ubuntu right now. I might try it on Debian tomorrow, but I think I'll try to make progress on SystemCore usage first, since Debian isn't officially supported (and Linux users are likely just going to deal with whatever, anyway, cuz...Linux...)

[ThadHouse]

Debian Trixie should work just fine, that’s actually our baseline. Let us know if it doesn’t, we should fix that.

We just haven’t updated the docs yet to properly say that.

[ThadHouse]

Debian Trixie should work just fine, that’s actually our baseline. Let us know if it doesn’t, we should fix that.

We just haven’t updated the docs yet to properly say that.

[kevinfrei]

Cool! I'll try it tomorrow, then!

[calcmogul]

Our installer generally works across distros. We just specify Ubuntu because that's what CI uses. The installer works on Arch Linux too, for what it's worth (that's what I develop on).

Fair warning that the Linux installer doesn't follow the XDG directory specification.

[Gold856]

There was discussion in wpilibsuite/WPILibInstaller-Avalonia#643 about that though. If you prefer XDG over just .wpilib, voice it over there.

[kevinfrei]

Installation on Linux, for realz

Okay, since folks say my distro-of-choice should be fine, I'm doing this.

The instructions for Linux talk about Sandboxing. I know what a sandbox is. I just don't know if I do or do not need to use WPILib from a sandbox. It's odd to provide guidance like that without some sort of "Here's why you'd need this sandboxed" or "Here's why you should/shouldn't generally do this".

Everything else "feels" about right except my ${HOME} rant, and for Linux, I think this is even worse, because you know you're dealing with more technically savvy users. I already registered my opinion in the discussion link above. Have I mentioned that I really hate apps that think they should be able to drop random crap in my home directory? Oh man, do I hate it. Stop doing that.

All that said, Linux isn't a letter grade. It's a Pass-Fail class. Thus far, things look like they work, so you get a big fat P for Pass.

[ThadHouse]

You need the sandbox stuff to launch vscode. On Ubuntu, it just won’t launch without those being ran. We hate it too, and wish apps would just work out of the box. But OSs like to fight users.

Agreed docs can probably be better there.

[calcmogul]

The sandbox instructions are for dealing with AppArmor on Ubuntu. Not every distro has that set up. I didn't have to do any sandbox stuff on Arch at least.

[kevinfrei]

Debian 13 seems to have launched the custom VSCode without concern. Docs. Docs would definitely help. Man, this feels like I'm using Alpha software or something!

[kevinfrei]

Done installing, time for a quick comparison

Okay, I've got software installed on a Mac, a Win11 box, and a Debian 13 box (same as the Win11 box, because I'm a glutton for dual-booting punishment)

This processes feels much clunkier than the FTC process, but at the same time, it's really just different because I'm only dealing with a single installer. For FTC today on Windows, you have to install the Rev Hardware Client, plus Android Studio, and maybe you even have to manage a different JDK installation. On Mac and Linux, you have to get Android Studio installed (pretty easy) and then deal with a JDK probably (messier) and then you have to know enough to use adb manually (even messier still). I really just want the single blob of software you're installing to be installed in the right place. Each platform is opinionated about this. If you're creating cross-platform software, you're signing up for dealing this kind of difference. If you don't, and just pick one platform the users of the other two will hate you for forcing them to use stuff that doesn't 'feel' right.

But you know what I really want? I want to be able to use a command line package installer, so I can trivially automate installation of this stuff on a student's machine. I already have a single script to install this stuff on all three platforms for FTC today. winget, brew, and apt all work well. It would be great if this stuff were packaged such that a single simple script (per platform, naturally) would be doable. Those of us who deal with constant new laptops from new students would really thank you for it.

And with that, it's on to greener fields: It's "get the new hardware to spin a motor" day! (Hopefully it's only a day, and not a week 🤣 )

[kevinfrei]

Things installed just fine. They installed fine again over the top of the installation I just ran. They installed a third time when I double-clicked the WPILibInstaller-CLI.exe and confirmed that I wanted to run it even though it wasn't signed. Each time it re-downloaded VSCode. 2Gbps internet makes this okay. 1-5Mbps internet at the high school would make that re-download pretty miserable😒

A few suggestions (I'm happy to open individual issues if you'd prefer: none of these should block the PR, imo):

1. Download VSCode to a known temporary location, and checksum it if it already exists before trying to download a fresh copy? Bascially, I'd like something to prevent re-downloading the same version over & over. Honestly, maybe allowing the user to have already downloaded a copy? The time it takes to set up a new machine behind school district wifi is very frustrating. I want to be able to prep a USB stick and do everything offline.
2. Detect that it's already installed, and verify an overwrite (and add a --overwrite option)
3. Prompt for confirmation if no flags are used. This is just me thinking about how to detect that someone just double-clicked the app. I don't know of a way to detect that type of a launch on Windows, so requiring a flag (--cli or whatever) or pausing for a prompt seems like a good way to deal with this.

Anyway, the CLI works from Windows. I'll go try to the Linux version. Can I jump through some extra hoops to allow it to work on Mac, or no?

[ThadHouse]

For mac, you can clone the repo, run the cli with dotnet directly, and use the flags to point to the resources and artifacts archives that you can get by downloading from that PR.

1 we can fix, 3 is easy to fix, 2 is probably something we won't do. We'd rather just overwrite, its always safe to do so.

[kevinfrei]

For mac, you can clone the repo, run the cli with dotnet directly, and use the flags to point to the resources and artifacts archives that you can get by downloading from that PR.

1 we can fix, 3 is easy to fix, 2 is probably something we won't do. We'd rather just overwrite, its always safe to do so.

I'll try to Mac thing in a few. Do you want me to create issues for 1 & 3 in the installer repo?

[ThadHouse]

Nah, they're already fixed just waiting for a run to push.

Note macOS might not work right. I can't actually download the resources to test it out myself.

[kevinfrei]

The linux CLI installer appeared to work just fine. I probably won't get to the Mac stuff until tomorrow...

[kevinfrei]

From Flashing firmware to a simple code snippet running in Hybrid Mode

Just a log of what I'm doing today

TL;DR: For as bad as my feedback was for the Mac installation experience for WPILib, this is that good. It's such a major improvement over the current Android FTC Robot SDK & hardware interaction experience.

I'm trying to channel the dad of the girl scout group I helped with some issues before their very first competition, here. The 'config' button is actually labeled "CONF" and it's a very subtle think you have to push with a toothpick or a paper clip. It would probably help to mention that there will be no indication on the SystemCore screen that it's in a mode. You'll only see the PWR light and nothing else. A handful of USB drives show up, so that was helpful. Some exposition about what this experience is actually like would help. For people who know what Flashing a device can do, but have never done it before, there's a fair bit of fear involved. Layer that fear on top of "This device costs my team $400, and it's out of stock for the next 3 months, cuz FTC & REV & supply chains" and you really can't "over explain" this process.

Nice job on the progress bar instead of a spinner. I'd probably indicate "All Data, including your Blocks and OnBot Java programs, will be erased!" in big flashing bold letters, if that's what happens (I assume that's what will happen...)

(Urge to disassemble this device is rising: RP2350? Neat! I want to run RISC V code on a little co-processor, just for fun! No, Kevin, stay on task, man!)

Okay, Flashed (pretty slow: would it be faster if I'd used a USB-3 USB-C cable? Cuz 32MB/second smells like the USB-2 bus is fully saturated...)

What's the SYSTEMCORE wifi password? Whatever: I just connected it over USB again for now.

Hey, look! There's the WiFi settings. I should have just tried PASSWORD in the first place! Anyway, let's connect over WiFi instead of USB! (My laptop is docked, so I've got WiFi to the robot and a wire to the interwebs, like god intended. I think an RPi5 can bridge, which would be amazing, but probably super duper complicated. FTC teams are accustomed to this particular annoyance, so unless it's not super-duper complicated, I wouldn't worry about it too much: Get a USB-wifi adapter for your laptop. No decent solution for Macs, though 😞)

That back is getting toasty. 56 degrees? Sweet, I'm annealing any PLA parts nearby while using my SystemCore!

Note to self: Much like the LimeLight 3A, the students will want to put these things in 3D printed containers. And, much like the LL3A, that's a very, very bad idea. Plastic is a better heat insulator than conductor. The back of this thing should be screwed to a bigger chunk of aluminum to prevent overheating, just like the LL3A.

OMG, I'm in a bash shell on the RPi compute devices. Glorious! So glad to have a future that doesn't involve Android 😃

Can I just SSH into this thing. Yeah, this has to be doable. Stay on task. Motor isn't spinning yet...

Drivers station installer: seems like a Windows installer. Controller recognized immediately. Handy! SDL FTW! (Our stilly steering wheel drivable bot thing will probably be way easier to setup, and involve far fewer "illegal" things!)

Back to VSCode: Mixing of forward & backward slashes in the path. Meh. Looks gross, but windows devs are pretty accustomed to it...

This is a breath of fresh air after being stuck with Android Studio for years. VSCode is just so pleasant. I only connected 1 motor and 1 servo, so let's comment out a few lines of code. VSCode comments code out well. Ctrl-/ doesn't leave hideous spacing 🥹. No more 5 layers of folders for Java, either. Nice job on first.robot as the entire package prefix!

Okay, deployed, but the RioLog window says "Robot connection lost". I think this is maybe a vestige of the FRC RoboRio control thing. The code is trying to run from the Driver's Station, but nothing is happening. I bet good money that this poor 6" USB-A to USB-MiniB cable is only power, and no data. Time to dig for another USB-mini cable.

Expansion Hub turned green: Good sign!

Note to self Hybrid mode is going to be annoying, because USB-A and USB-Mini-B are both pretty crummy, chonky connectors. I wonder if we'll be able to run hybrid mode with MotionCore, cuz a Rev Servo Hub + SC + MC would be a pretty nice setup (except for the aforementioned USB connectors...) More homework for me 😄

Motor and Servo both respond to input! HURRAY!

Oh man, deploying from a PC-hosted VSCode took well less than 20 seconds. So much better than the android experience.

Okay, before calling it a day, there's stuff sitting the home directory on the RPi 5 now. This looks so easy to poke around and diagnose stuff. OMG, the code is running vanilla OpenJDK 25. No more stupid Google/Oracle lawsuit avoidance shenanigans! ssh didn't just work without effort, but I don't want to accidentally mess anything up, so that's a future investigation (oh, who am I kidding: 30 FTC kids on the discord have probably already figured all this stuff out 😆)

I know there's a lot of concerns from the hardware students (mostly around the A301's and the whole "no more servos" [personally, I don't think the no-more-servos thing will stick: They're cheap and useful, and forbidding them will lobotomize FTC, but focus, Kevin: stop getting distracted!!!]) From a software perspective, however, this is SUCH a win over the current state of the world. I don't think I'll bother maintaining (or porting) TechnoLib, since it was basically an implementation of the 'heart' of WPILib, anyway. We switched to PedroPathing this last year from RoadRunner. I'll have to see what that looks like, but honestly, porting stuff from the current SDK to the new one might be a fun project, even if PP doesn't offer any wins over whatever WPILib includes.

[ThadHouse]

Ssh instructions and all the default passwords are in the readme for this repo.

[ThadHouse]

And you’re correct, the riolog thing is an alpha ism, and should be fixed in a release or 2. We didn’t update the IPs. Easy to fix. Same with getting console logs out of the ds. Those are all coming soon.

[Kevin-OConnor]

Regarding the feedback on the flashing process: Feedback on the crude alpha instructions is heard and all makes sense. To be clear, the intended final device update/imaging process is via the web interface with the existing Conf button + Limelight Hardware Manager as a recovery procedure only if something goes sideways. I know Limelight thought they were close on this and I see both the UI elements on the bottom of the Settings page and the .llupdate files in the latest pre-release OS assets, but I'm not sure if this is 100% functional yet or not.

[guineawheek]

As a Linux user for about as long as I've been involved in highschool FIRST, I really like ~/wpilib, personally. I often need to run tools and stuff out of that folder. I don't want more .s, more ~/.local/shares, more BS inbetween, more trying to mux which year's version of Glass or AdvantageScope i'm running in my PATH. That's a pain for my pinky and a pain for myself organizationally.

Need to run WPILib's bundled copy of Java? ~/wpilib/2027_alpha1/jdk/bin/java. Tool from a specific year? ~/wpilib/2026/tools/Elastic works.

For all intents and purposes, the ~/wpilib/YEAR directory is, more or less, the entire WPILib install. And it's nicely self contained per-year and filled with artifacts that aren't just useful in regular desktop use but also for stuff like CI. It actually ends up quite nice, because especially if you're not doing interactive builds, you can end up actually cp or rsync'ing the entire wpilib directory to other machines and have things Just Work. The main things the Avalonia installer does is just set up that folder and make a couple desktop shortcuts; the install process is traditionally quite barebones.

What about mixing WPILib VSCode with existing VSCode installs?

To be honest, and I understand why this isn't more obvious in the docs, but I just don't actually run the bundled WPILib vscode, I just use my system vscode install and actually directly install the current year's vsix from the ~/wpilib/YEAR folder. As long as you're configured for the correct Java version, it works perfectly fine.

Android Studio did this way worse

For over 10 years I've had to live with an Android folder in my $HOME, because of FTC's current control system. The weird disproportionate focus on this feels insanely...harsh when Android Studio produces an ~/Android, an ~/AndroidStudioProjects, an ~/.AndroidStudio{MAJOR}.{MINOR}, an ~/.android. And it makes a new ~/.AndroidStudio{MAJOR}.{MINOR} on every major update and has the gall to ask you to migrate!

Personally, I don't really care that there's a ~/wpilib in my home folder, and frankly I much prefer that to conforming to some XDG-slop standard. It's really not that intrusive, lets you have old WPILib installs from multiple years available simultaneously, contains a multitude of useful things (e.g. all dashboards, the bundled JDK with the guaranteed correct version, the native toolchain for the robot controller, and a Maven repository with all the wpilib artifacts so you don't need an internet connection to build everything). I am personally very willing to take the trade of having an install that's universally easy to find, to manage, and ultimately to remove than burying it in Linux's equivalent to the %AppData% void.

WPILib is not apt-packagable. Please do not subject us all to Debian's antiquated package management.

WPILib is ultimately installed differently compared to traditional Linux package management, and I really think that's fine because it ends up being a useful common denominator with its own well-defined bundled toolchains and system as a result. ~/.local/share et al feel more appropriate for software that actually live in {/usr}/bin, not something that's spiritually not far off from an actual local install.

I don't wanna deal with XDG-slop. I just want to be able to easily access a given year's context. I really don't see why this is such a huge issue.

[qwertychouskie]

And it's nicely self contained per-year

Thing is, from my understanding, various things rely on the folder staying in the default location with the default name. Placing it directly visible in the home folder makes it likely users move and/or rename the folder, which will then break critical functionality. Given that the folder needs to not be messed with, due to the software relying on the folder being in a known location, it should be placed in an appropriate location, which would be ~/.local/share/wpilib under XDG standards.

If it was truly self-contained like a portable application, where you move/rename the folder as you see fit, and it will work, then sure, ~/wpilib as a default location makes some more sense. But as it stands today, that's not what it actually is, so ~/wpilib is actually subtly communicating incorrect information, and therefore creating a footgun.

I don't wanna deal with XDG-slop. I just want to be able to easily access a given year's context.

If a particular user wants an easy way to access the folder, they can always create a symlink. As a bonus, they can name it whatever they want, and place it wherever they want, and it won't break anything. If you want it accessible as ~/wpilib, you can do that. If I want it accessible as ~/FTC/Programming/WPILib, or ~/Projects/FIRST/wpilib, I can do that. If someone doesn't want to see it, they won't, without needing to resort to manual intervention (such as adding the folder name to .hidden), or being pushed to unknowingly break their installation.

For over 10 years I've had to live with an Android folder in my $HOME, because of FTC's current control system. The weird disproportionate focus on this feels insanely...harsh when Android Studio produces an ~/Android, an ~/AndroidStudioProjects, an ~/.AndroidStudio{MAJOR}.{MINOR}, an ~/.android. And it makes a new ~/.AndroidStudio{MAJOR}.{MINOR} on every major update and has the gall to ask you to migrate!

Pro tip: Create a text file named .hidden in a directory, then just put the names of any files/folders in that directory you want to hide on each line, and they will show as hidden in your file manager. I use it to hide a few folders in my home dir, such as Ubuntu's ugly snap folder that sticks out like a sore thumb (it's not even capitalized, while every single other default folder is), along with Android and node_modules.

[kevinfrei]

For over 10 years I've had to live with an Android folder in my $HOME, because of FTC's current control system. The weird disproportionate focus on this feels insanely...harsh when Android Studio produces an ~/Android, an ~/AndroidStudioProjects, an ~/.AndroidStudio{MAJOR}.{MINOR}, an ~/.android. And it makes a new ~/.AndroidStudio{MAJOR}.{MINOR} on every major update and has the gall to ask you to migrate!

Given that we're alpha testing, and we can make things better, I'd hope that WPILib can hold a higher bar than Android Studio, the virus of development environments... Android Studio: your dev machine is our trash can™️

[kevinfrei]

I don't wanna deal with XDG-slop. I just want to be able to easily access a given year's context. I really don't see why this is such a huge issue.

"The XDG spec" is the phrase you're looking for, not "XDG-slop". It's not akin to AI-slop (probabilistic garbage generated through random IP theft that no human has bothered reviewing, nor was involved in the creation of). A standard (of which XDG is one) is the exact opposite of AI-Slop. Spec's represent thousands of hours of thought and design.

Why is ~/wpilib is the worse of the two options? If I've spent 30 years using a folder called ~/work then I install WPILib, getting to ~/work is now a worse experience. From here on out, every time I type cd w<tab> I suddenly have to start tying cd wo<tab> or (more likely for the first 6 months) cd w<tab>o<tab>. If you spent 10 years accessing a folder called ~/wpilib then you get WPILib installed to ~/.somewhere/else you spend 15 seconds typing ln -s ~/.somewhere/else ~/wpilib and you go back to working the way you always have. One is a long term cost and required behavior change, the other is a one time cost with no long term behavior change required.

[ThadHouse]

Spec's represent thousands of hours of thought and design.

I will say, as a primary Windows user, that spec absolutely does seem like slop, and seems to have very little design thought in it. It's very confusing and some of the paths really make no sense. But I'm not a linux user, so I don't really care that much.

[kevinfrei]

RHC2/A301 issues & confusion

I don't think this may be the right forum for this feedback, but man, the REV docs for the A301's are, uh, lacking. The Mac REV Hardware Client alpha insta-crashes on my M4 MBA15 unless the computer doesn't have an active connection to the internet. Even then, it never finds anything. I gave up and moved to Windows.

On Windows, the Alpha RHC2 app doesn't appear to see...anything at all with SystemCore attached over USB or WiFi. I gave up and installed the IPK through the Drivers Station App, which was quite straight forward. But then the directions say something about putting a file in "the downloads" tab, which (after much digging) seemed to be the Downloads tab of RHC.ipk, but you can't do what they describe. You can only "add a channel". So I plugged in a motor, and it popped up in RHC.ipk), at which point me poking around for 5 minutes resulted in figuring out that I could upload the .dfu file to update the motor. And then I did that for each of the 8 motors I have, which I look forward to doing on a regular basis. Firmware updates are a wonderful pass-time of this modern world. I think it's my new hobby🤣. I like cycling, mountain biking, playing guitar, and update firmware.

Summary: Directions for A301 gets a big 👎double thumbs-down👎. Honestly, I'd be comfortable writing up exactly how I did what I did with screen shots & whatnot, if folks would find it useful. Maybe to update the woefully inadequate A301.md file (or the REV.md file?) in this repo?

[Kevin-OConnor]

I was looking through A301.md and was struggling to match it up with your feedback, then I clicked over to the Rev.md and see most or all of the issues/confusion you are referring to in there.

The end intent is that A301 firmware update will ideally be built into the Motioncore page, that was close for initial release but the RHC2 IPK path ended up being ready sooner. But there may be some things I can try to clean up on those instructions in the meantime.

[kevinfrei]

I think the current split between the two docs is just really messy. I don't know who's going to bother with REV.md that isn't dealing with A301's. It probably should just be merged, but if things like firmware updates will be really, really, really infrequent, it's probably not worth the effort.

[kevinfrei]

Starting with MotionCore/A301's and WPILib for-realz

I just got an A301 motor to spin, using a really dumb little tele opmode that increases or decreases the 'throttle'. Is there some documentation about the A301's API anywhere that I'm not seeing, cuz I've got a Throttle, Velocity, and Current controls. Coming from a world of duty cycle and nothing else (Okay, run-to-position, but we always just did that ourselves, because we always needed a PIDF FF function...) are there docs that explain what these different things mean/do? Cuz setThrottle at 1.2ish seems fine, but when it hits 1.4ish, it just starts jiggling back and forth aggressively, and I was not prepared for that😮

Oh yeah, and now I get to swap between the V21 JDK and the V26 JDK, because our Android stuff won't work with anything later than 21, and SystemCore requires at least 25. Hurray. (I'm using the command line, like our ancestors intended)

I'm also starting to look at what it would take to get to basic feature-parity with A301's. I'll probably havfe to port the PinPoint driver to WPILib. I hear some students have vibe coded drivers around, but I'd rather migrate the Arduino driver to SystemCore, personally. Vibe-code is terrible for a starting effort, because it looks right (because that's literally how LLM's work), which makes catching errors at code-review time much more difficult.

I also feel like I need to read some good WPILib tutorials. I've been in "command-based" land for several years, so that's not really a new concept, but WPILib's structure feels different in some fundamental ways, from the FTC SDK and the variety of command scheduling systems that live over there (we've been using something an alum built since 2020). What's different? One thing I stumbled upon is that a teleop's periodic function seems to be getting called (with no hardware side-effects...) even with the opmode isn't selected? I'm seeing some weird behaviors, and I'd rather learn the "right" way to do things before I write up feedback just to save everyone time & turmoil.

Any suggestions for something that provides a better guided tour than me clicking "next" through the official docs?

[ThadHouse]

Just to double check, I wanted to make sure everything worked, so I freshly flashed by Systemfore with the Beta 11 image, Alpha 5 of the DS, and deployed your repo directly. It started up properly, and gave me the options to select both autonomous and teleop opmodes.

[jfabellera]

@jfabellera Any idea why? That seems weird, I would have expected it to be capped between -1 and 1.

So yes it is capping it to [-1, 1].... but not in right place 😄. That will be fixed next week

[kevinfrei]

Yeah, more details would be nice. Theres no robotLaunch script.

Oops: You're correct. It's called robotCommand and it was very helpful. I think I was running with a 1-off build. It's deploying, now. (Sorry for the silence: robots are not my only priority, in spite of what some of my students would like😄)

-rw-r--r--    1 systemcore systemcore  11276971 Jun 21 14:21 a301-test-all.jar
drwxr-xr-x    2 systemcore systemcore      4096 Jun 13 13:03 deploy
-rw-r--r--    1 systemcore systemcore   4372710 Jun 13 13:03 ehub-all.jar
drwxr-xr-x    2 systemcore systemcore      4096 Jun 17 21:37 logs
-rw-r--r--    1 systemcore systemcore         3 Jun 13 13:03 networktables.json
-rwxr-xr-x    1 systemcore systemcore       258 Jun 21 14:21 robotCommand
drwxr-xr-x    3 systemcore systemcore      4096 Jun 13 13:03 wpilib
$ cat robotCommand 
/usr/bin/java -XX:+UseZGC -Djava.library.path=/home/systemcore/wpilib/third-party/lib --add-opens java.base/jdk.internal.vm=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --enable-native-access=ALL-UNNAMED -jar "/home/systemcore/a301-test-all.jar" 

I've actually ported PedroPath over to SystemCore (I'm constantly impressed by the quality of code FTC students pull off!) and am working on just getting a simple 4 motor drive base with A301's "working" (I'll get it going with a simple periodic function first, then try to get it working with Pedro)

I think I'm occasionally getting myself into trouble by switching machines. Overall, the Mac doesn't seem like it's quite ready for prime time (RHC2 Alpha is so very, very crashy), so I'm sticking with Windows for now. (I don't use Linux too frequently, but I'm happy to run one-off testing there upon request)

[ThadHouse]

Realistically, you should never need the local RHC install. The systemcore ipk is probably what most people would be using, and that works in any browser.

[kevinfrei]

@jfabellera Any idea why? That seems weird, I would have expected it to be capped between -1 and 1.

So yes it is capping it to [-1, 1].... but not in right place 😄. That will be fixed next week

I can run it up to 1.25/-1.24 before the motors start freaking out with the 500RPM gearbox. I assume it has something to do with moving electrical fields faster than the motors can turn.

[kevinfrei]

Question and/or Feedback: When an exception occurs upon robot launch, there no real indication of the problem, except that "enable" is disabled. So, I wind up running robotCommand from the terminal to see what's crashing. Am I missing something in the driver station app? In FTC Land, you get a popup with a stack trace that most of the students figure out pretty quickly how to diagnose...

Very related: Because I'm sometimes running stuff directly from the shell, I think there are situations where I wind up running 2 copies of my app, and things behave...strangely. I have a little auto that switches through 4 motors, spinning each one up and down. And sometimes (again, when I think I have 2 app running) the motors are super stuttery, and just generally not behaving as the code indicates they should. I should probably get a wake-up error telling me I'm doing something bad, rather than just being able to do something bad...

[ThadHouse]

For the first part, that’s all fixed in the next WPILib release , but if you update to systemcore beta 11, you’ll at least get the crashes printed in the console tab in the DS.

Running from console is just something not supported, but we don’t have a way to block it. Since you can get all console output in the ds once you update to beta 11 and the latest alpha ds, there’s no reason to do it.

I’ll look into a way to by default block running the app from a console, and require it to be ran through the service.

How the console in beta 11 and above works is we’re just streaming the journald log from the service to the DS. So we always want it running through the service.

[ThadHouse]

Next set of updates will include blocking of running multiple robot programs, so it just won't allow it anymore.

[kevinfrei]

Question for software 'stuff':

What's the 'best practice' for having multiple robots, or multiple robot configurations in a single source repo? I'd really like to be able to have a single repo for trying all sorts of different stuff (in FTC, I typically have 3-5 completely separate robots, plus each bot tends to have a few different configurations)

[ThadHouse]

Generally, the answer is separate repos per robot. Robot projects in general are cheap to create and store.

However, nothing is stopping you from having multiple Robot classes. If you look at Main, you'll see that its just loading a specific Robot class. You can change that and redeploy to launch a separate robot class. And then it will only automatically load the OpModes that take that robot class in their constructor.

[kevinfrei]

Yeah, multiple repos really stinks for sharing code. I'll go take a look at main. Thanks!

[spacey-sooty]

If your aim is sharing Java code between multiple teams/robots then you can always do Gradle subprojects. When my team was split into two teams with a common set of code we had a common project then two robot projects under each team numbers directory so your deploy would be ./gradlew :teamnumber:deploy

[kevinfrei]

That's what build targets look like in FTC. I'll have to dig in and figure out how to do that. Hurray, another build system to learn 🤣

[gearsincorg]

FWIW (and I'm not advocating for this... but since you asked) for my testing here, where I also wanted to try lots of things, I just created an "Alpha" folder and put each robot project under that. Then I made Alpha a repository. This way all the projects get maintained together and I can have them all available for comparing when experimenting & cut & pasting. It's not pretty or efficient but it's simple and it's.... simple :)

[kevinfrei]

Got a full, dedicated A301 drive base going. It's insane to drive, because the mech student doubled up all the A301's so each wheel has 2 motors attached to the drive axle. With the 500 RPM gearbox, and a 3:2 timing belt speed up, it's spinning wheels at 750RPM. I haven't really run into any issues that haven't already been reported (Periodic functions appear to be running all the time...)

Next up: get the PedroPathing library port working and try running autonomous paths with goBilda odopods attached to this little speed demon...

6-tiles.mp4

FirstDrive.mp4

[gearsincorg]

Are you running setThrottle() or setVelocity()? I ask because I was wondering how well the twin motors are sharing the load. I could see setTrottle() sharing fine, but I wondered about setVelocity() if they both try to close the loop.

[kevinfrei]

I used setThrottle specifically for that concern, cuz I was worried about dual closed loop controls acting weird. I'll switch it to setVelocitiy and see if it behaves any differently in the next day or so.

[ThadHouse]

At some point we want to have a follow mode, similar to FRC motor controllers. But the way Motioncore is implemented makes it basically the one thing we don't get for free by using existing infrastructure. Since the buses are all separate, follow mode has to be implemented in software on Systemcore.

[kevinfrei]

Our mech lead asked me to zip tie another 10lbs to it, to see how well it handles 🤷‍♂️

[kevinfrei]

Are you running setThrottle() or setVelocity()? I ask because I was wondering how well the twin motors are sharing the load. I could see setTrottle() sharing fine, but I wondered about setVelocity() if they both try to close the loop.

I'm now running setVelocity with dual motors, and it behaves the same as with setThrottle. Is the closed loop happening on the motors? (I assume so, but I'm not really a very informed mech/electronics person)

[kevinfrei]

One more small collection of feedback: The First Driver Station app.

1. I can't get it running on my MBA 15: it never detects the spacebar as e-stop, and yes, I've done all teh thigns. Any suggestions? (I know, Mac App security stuff is ANNOYING. I haven't done Mac ObjC/Swift debugging in a long time, but I could probably dig into that if it would be helpful)
2. There's no obvious indicator that your code crashed. (Mentioned this earlier: it's quite frustrating) I have to know to go over to the log tab, and scroll because I notice that 'enable' is now disabled.
3. I run my high density LCD screens at "old people" scale, so that ultra wide, short control layout doesn't fit on my Framework 13 2880x1920 screen.
4. Why is it that shape? Why can't I lay it out differently? Why can't I maximize it so I can do things like see more than 300 characters in the log at one time? There are clearly separate 'panes' but they're all side by side.
5. I CAN USE MY PS5 CONTROLLER WITHOUT A CORD! WAHOO! (I don't care if it's legal or not: Please don't remove this capability, even if I have to click a button that turns the drivers station pink or something. It will be marvelous during coding sessions)

It's an order of magnitude better than the miserable FTC driver's station 🤣 (I have an Amazon Kindle Fire tablet that I've side-loaded that thing on for non-competition stuff, because it was $40, but it still doesn't let me use a bluetooth controller)

[kevinfrei]

External dashboards are so useful for development, I’m sure teams will get used to them.

I'm far more certain that most teams won't ever use them😞. Plenty of FTC teams currently use FTC Dashboard or Panels. I know how useful they are (have you ever waited for an entire Android build/deployment cycle to change a single number? Ugh...). I'd bet money that maybe 25% of teams won't even realize those external dashboards exist. Most FTC teams don't use cameras (or sensors of any kind). Most teams only know how to use the built in telemetry, because it's easy to use and is in the sample Blocks code they copied to make their starter robot drivable. If it's not built into Blocks and really easy, it's not going to be used by most of the teams building a robot. Please keep that crowd in mind when thinking about UX. Your new users are a much more diverse group, skill-wise, than FRC (at both ends of the spectrum).

Also, @ThadHouse, I'd love to grab coffee or lunch with you somewhere (maybe in Monroe?) to chat about robots/code/stuff some time!

[ThadHouse]

I'd love to grab coffee or lunch with you somewhere (maybe in Monroe?) to chat about robots/code/stuff some time!

We definitely should. Monroe works great. Email me (thadhouse1 @ gmail) and I can grab your phone number.

[guineawheek]

I actually used wpilib in 2016 on an FRC team before I went to FTC, and SmartDashboard was by far one of the things I missed most from FRC.

I know people who disagree with me on this one, but I honestly think if official Systemcore-era docs showed off a dashboard and how to use it the way SmartDashboard was back in those days, I do think lots of people would use it.

It's something not every novice student realizes they want or need before its power is demonstrated to them, and something I think a lot of FTC people mentally write off because they only (initially) see the controller as an interface to communicate with the robot; they'd need to reach into the FTC community (alone a huge jump) to realize things like FTC Dashboard exist.

Video related: https://www.youtube.com/watch?v=U2TGYPNR5oQ

[ThadHouse]

We definitely plan on documenting elastic like that. Especially with elastic being accessible over the web interface, you don’t actually even need anything installed locally. Just hook into the network and set a few flags.

[ThadHouse]

@kevinfrei An update has been released that lets you select the smaller screen by default, and should fix the keyboard issue.

[kevinfrei]

LL3A SystemCore library somewhere?

Given that there's "Limelight" on a variety of pieces of this tech, is there any ETA on getting the actual Limelight camera interface working on SystemCore? The current WPILib integration doesn't look compatible. Is there something somewhere I should be grabbing for this?

(I've got a little bot I'm trying to convert to hybrid mode that has a LL3a on a gimbal, and I'd love to get the whole thing working if possible...)

[Kevin-OConnor]

OS 12 has the OS side support for this but I don't think there is anything on the robot code side for this yet for accessing the values. They are probably getting published to NT on the system server somewhere you could dig around for with Elastic/Ascope/Outline Viewer to identify, but now that OS support is in I'd imagine we'll start working on something nicer for robot code side.

[kevinfrei]

SystemCore & Encoders?

How can I connect encoders to SystemCore? The API indicates that I provide 2 ports, so is it just a power/signal/gnd to the first one, and just signal to the second port? (I'd rather use the SystemCore for odo than have to connect a second expansion hub to get odo working on my current FTC demo bot, until I can get PinPoint drivers up & going...)

I think the higher level question might be: Are there docs somewhere I'm missing? (follow-up question: Would you like me to start writing some of these missing docs?)

[ThadHouse]

Encoder support has not been implemented yet. The classes are still there because at some point they will be, and they existed on the roboRIO.

Once it's implemented in firmware, that is how it will be done, with the restriction of it must be done in 3 specific pairs (0-1, 2-3, 4-5). It won't support arbitrary pairs.

TBH it's probably easier to get pinpoint working. Especially because someone posted a driver #323

[kevinfrei]

STL/STEP/OnShape for battery mount?

Students driving around the dual-A301 bot slammed into the wall at full speed and (naturally...) broke the attachment points completely off the battery mount. It's obviously 3D printed. Any chance the file's publicly available, so I can reprint one?

[kevinfrei]

[jfabellera]

Please send an email to support@revrobotics.com to get it replaced.

[kevinfrei]

Universal (and more advanced) telemetry & editable static values?

@ThadHouse (or anyone else) what's the easiest and most universal way to get some sort of telemetry? I'm in the process of porting PedroPathing over to SystemCore, and I've hit a set of open questions around the "correct" replacement for the built-in FTC telemetry (and expansions on it). Basically everyone uses it because it's built in, trivial, and obvious. You don't have to open something else, and the interface is simple enough that it's accessible from Blocks.

Most advanced teams were using FTC Dashboard, and some of us switched over to Panels for a much more robust telemetry experience. (Both have the ability to draw paths & robots on a field, which is super handy). I think that's AdvantageScope? I'd love a pointer to some examples...

I'm also very much missing the @Configurable capabilities of those two libraries. Is there something similar in the WPILib ecosystem? (changing various static values without a redeploy: The speed of deployment makes this a little less useful, but being able to just tweak values willy-nilly until you get things correct before making the code changes is a much simpler workflow...)

[ThadHouse]

Neither Tunable or DsGamepadChooser are available in a release yet. Tunable is still in that PR that was posted above, and DsGamepadChooser is merged but not in a release.

[kevinfrei]

Yeah, DriverStationDisplay looks great. Do I have to build a full WPILib and go figure out how to install it, or is there some way I can switch the WPILib dependency to be the source code and just have it built from source "as needed"? (I had a repo configured that way for our shared command library in Android, but the gradle code looks dramatically different from the simple stuff I learned to accomplish that)

[ThadHouse]

So normally you can, but right now you end up having to do a custom build of gradlerio to pick up newer WPILib with all the proper dependencies. You will also need to be using the newest beta 12 image.

The newer gradlerio requires some changes to the project files. I can try and create a project when I have some time.

[kevinfrei]

So normally you can, but right now you end up having to do a custom build of gradlerio to pick up newer WPILib with all the proper dependencies. You will also need to be using the newest beta 12 image.

The newer gradlerio requires some changes to the project files. I can try and create a project when I have some time.

Nah: Don't worry about it. I'll just switch it over to System.out for now, and when you do another release I'll switch it. I'd rather not add extra work to your plate right now.

[ThadHouse]

It’s easy enough I just need to be at a computer to do it.

Generally we publish all developer builds and they’re usually accessible with just a simple change. It’s just during alphas we make changes that are incompatible and need updated build files.

[kevinfrei]

Deployed code sometimes just...doesn't work?

I've had this recurring issue where I get failures that look like this:

********** Starting OpMode Field-centric drive **********
Auto-detected device ID: 3 on bus: 5
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483)
	at org.wpilib.util.ConstructorMatch.newInstance(ConstructorMatch.java:84)
	at org.wpilib.framework.OpModeRobot.constructOpModeClass(OpModeRobot.java:157)
	at org.wpilib.framework.OpModeRobot.lambda$addOpModeClassImpl$0(OpModeRobot.java:363)
	at org.wpilib.framework.OpModeRobot.loopFunc(OpModeRobot.java:679)
	at org.wpilib.internal.PeriodicPriorityQueue.runCallbacks(PeriodicPriorityQueue.java:176)
	at org.wpilib.framework.OpModeRobot.startCompetition(OpModeRobot.java:786)
	at org.wpilib.framework.RobotBase.runRobot(RobotBase.java:359)
	at org.wpilib.framework.RobotBase.startRobot(RobotBase.java:448)
	at first.Main.main(Main.java:25)
Error at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74): Could not instantiate OpMode DriveBaseTrig
	at java.base/jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance(DirectConstructorHandleAccessor.java:74)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:483)
	at org.wpilib.util.ConstructorMatch.newInstance(ConstructorMatch.java:84)
	at org.wpilib.framework.OpModeRobot.constructOpModeClass(OpModeRobot.java:157)
	at org.wpilib.framework.OpModeRobot.lambda$addOpModeClassImpl$0(OpModeRobot.java:363)
	at org.wpilib.framework.OpModeRobot.loopFunc(OpModeRobot.java:679)
	at org.wpilib.internal.PeriodicPriorityQueue.runCallbacks(PeriodicPriorityQueue.java:176)
	at org.wpilib.framework.OpModeRobot.startCompetition(OpModeRobot.java:786)
	at org.wpilib.framework.RobotBase.runRobot(RobotBase.java:359)
	at org.wpilib.framework.RobotBase.startRobot(RobotBase.java:448)
	at first.Main.main(Main.java:25)
Warning at org.wpilib.driverstation.DriverStationErrors.reportWarning(DriverStationErrors.java:40): 	SmartDashboard.updateValues(): 0.000004s
	robotPeriodic(): 0.000002s
	disabledPeriodic(): 0.022472s
waiting for can interfaces

whenever I try to enable the opmode. I don't change any code, I just redploy, and it works. Am I doing something weird? The reflection-based invocation of the user code is delightfully obfuscating, as usual. I added some System.out.println lines and it started working. I'll see if I can get a repro with more detail, but this has been a recurring "waaaat?" problem that I'd love any insight into.

[kevinfrei]

Any pointers as to where to find the simulator or simgui, or generally how to use the simulator?

[ThadHouse]

If you're just in gradle, ./gradlew simulateJava will fire it up. If in VS Code, The run config is default set up for running simulation, and as long as you haven't changed it, just hit F5. That will launch sim in the debugger.

https://docs.wpilib.org/en/latest/docs/software/wpilib-tools/robot-simulation/

Theres also docs here.

[kevinfrei]

The issue I was hitting was related to periodic being run before an opmode is started. That's being fixed soon, right? (I just added astarted member and conditionally run the code for now)

[ThadHouse]

Yeah, it’s being fixed.

One thing to make sure of is to use enabled and disabled as the terms. Started isn’t a thing in WPILib. Makes it easier to help triage.

[kevinfrei]

I used "started" because the method to detect that you've been enabled is called start. There's definitely confusion there, as I understand what you're describing and see that it's called "enable" in the driver station. Naming is hard!

[kevinfrei]

AdvantageScope log viewer: What am I missing?

Everyone seems to love this thing. How can I select lines and copy them to the clipboard? You know: the single most basic feature that anyone who's ever had to use logs to debug a problem will want to do? Seriously: This is the most basic, simple thing that anyone looking at a log would want to do, and this log viewer...just doesn't? (Just in case you thought my opinionated anger was only for WPILib stuff 🤣 )

[Gold856]

You... select the lines and copy them? I just did it, so I'm not sure what's being asked. I'm gonna assume you opened the log, and you are probably looking for the Console tab, and you probably want to drag the console field (whatever it's called) into the Console tab, which will display all the lines and allow you to select and copy them.

[jwbonner]

If you aren't able to select and copy the text in the console tab, that's definitely not the expected behavior. Feel free to open an issue, screenshots or recordings would be very helpful to see what you're trying.

[kevinfrei]

If you aren't able to select and copy the text in the console tab, that's definitely not the expected behavior. Feel free to open an issue, screenshots or recordings would be very helpful to see what you're trying.

Okay, I'm clearly in some view (that I got sent to by clicking something in the driver's station) that isn't what y'all are describing. I'll dig around, but the fact that the view I got sent to isn't selectable seems pretty weird and makes it deeply annoying. Or maybe it's a bug in the Brave browser? I know that it had some issues connecting to robot.local, while Chrome is just fine. I'll try poking around some more later today.

[Gold856]

Oh! You must mean the built-in AdvantageScope that launches with the Log Viewer button. You should be able to create a new Console tab and drag the entire Console field on the left into the Console tab and have it start displaying data there (although I don't know if we have the console data transmitted yet, so it might display the field, but then display no messages).

[jwbonner]

@Gold856 The version of AdvantageScope built-in to the Driver Station includes a default layout with the console tab selected and pre-populated, at least on the latest version of the DS.

I believe there are currently some edge cases with the new DS console decoding in AdvantageScope where the console text is completely missing (the perils of a brand new data format), but that doesn’t sound like what’s being described.

[kevinfrei]

Feedback from other folks at WCI

Our team attended the West Coast Invitational in Bonney Lake, WA over the weekend. I took the A301/SystemCore drivebase and let anyone who wanted to drive it around on the practice field, and talked to a number of coaches, mentors, and students.

General feedback was excitement around seeing the new hardware. Ignoring the general excitement, I saw two recurring pieces of feedback:

• The noise coming from the motors makes even the noisiest launchers from Decode sound pleasant. 50+ of these things on the field is gonna be an auditory assault. They should come with noise cancelling headphones.
• Every programming student that saw me edit, build, and deploy code in less time than it takes the Android build to do a "zero-change" build was super jealous, and can't wait until these things are available.

I'm probably going to be poking around more with SystemCore this week. I've got a couple clips to let me move SystemCore between the A301 bot and a bot that should be switchable between hybrid mode and a control hub.