2818 G-FORCE Progress Updates

[gearsincorg]

First Post: 5/4/2026

G-FORCE picked up it's System Core and Motion Core at Worlds on Sat, and we are eagerly awaiting our A301 motors and Battery supplies. Our fist task will be to retrofit the SystemCore into our 2025 "Into The Deep" robot. This bot has a good mix of Motors, Servos and sensors.

We'll probably do two different setups. One that uses the 4 available motors for the drive, and then another where we run the various manipulator motors instead.

Question: Can we run two expansion hubs to drive all 8 motors ????

In the interim, we are locating and reviewing the available documentation so we're ready to go as soon as we have hardware.

Mr. Phil.
Lead mentor and FTC Tech Team Member.

[ThadHouse]

Yes, you can run 2 expansion hubs (You can actually run 4). Each just needs to be connected to a USB port on systemcore directly. RS485 is not supported.

[gearsincorg]

Looking for clarification on the correct orientation for the Encoder adaptor PCB.

The SystemCore adapter boards are labled with the IO port numbers so the correct orentation is clear.
The Motion core adapter PCB appears to have it's Encoder ID numbers blacked out. I'm assuming this is because they are incorrect.

So.. is this the correct way to insert the boards? Picture coming...

[ThadHouse]

Yeah the printed order was incorrect. The blacked out numbers side faces the inside of Motioncore.

[gearsincorg]

First Power Up: 5/5/2026

We canabalized a motor cable by switching to an XT30 connector at one end. This will enable us to power the System core directly from a battery/switch, or from an expansion hub. (We figured we wouldn't be getting 20 x A301's any time soon).

The Systemcore fired right up.

On the small display: we had signs of life at 18 seconds, and a full status screen at 25 seconds. Nice!

[gearsincorg]

I'm having trouble with flashing the new OS...

I beleive I've done it correctly, but I'm not getting anything on the display now, and I can't connect to the internal web page.

I'm using the Limelight Hardware Manager 2.0.7 for Windows
I connected to the SystemCore and sucessfully extracted and flashed limelightsystemcorebetacm5-limelightosr-beta-9.zip

The flash process seemed to end correctly, although the final lines of the flash log don't match the final lines form the "Flashing Instructions" Video....

When the flash is complete, I see a bunch of new drives in Windows Explorer.
But when I unplug the USB and cycle the power, I just get a blank screen (on systemcore).

When I plug the USB back in, I don't hear the "connect" tone, and no new device appears.
If I try browsing to http://robot.local/ It just times out waiting.

If I do a ncpa.cpl command on windows I don't see the SC as a device on the network.

Since I haven't been able to configure the device's network settings, I don't know if I should be able to see a SSID, but none are visible if I go looking.

I even tried repeating the full flash process again, but with no sucess.

Can you see what I may have done wrong, or have missed out.

I've attached the flash log file.
Flash Log.txt

[ThadHouse]

We probably need to mark a newer release.

https://github.com/LimelightVision/systemcore-os-public/releases/tag/limelightosr-beta-10-138

This is the one you should use. My guess is that image is old enough it doesn’t work with the newer flasher.

[gearsincorg]

OK, I'll give it a try...

[gearsincorg]

Well, that worked a lot better :)

[gearsincorg]

New OS loaded 5/6/2026

We have now sucesfully loaded the new beta-10-138 Operating system, and configured the team name, SSID and password.
We can access the internal web-setup page via USB and WiFi.

[gearsincorg]

Driver Station 5/8/2026

Installed and fired up the Driver Station on Windows 11.

First time I tried to install it, windows complained that it couldn't verify the publisher, so I just accepted the "unsafe" status and it loaded right up. (Oddly, it doesn't complain any mor if I try to re-install it).

After setting the Team number to match the SC, and plugging int the USB, it connected and started displaying battery voltage etc.
Also worked with only WiFi and with both.

Question. Will there be a naming convention for the WiFi SSID?
>> I used 2818-SC to be consistant with the old scheme while recognizing the System Core as the controller.

I really like the updated DS layout (I'm familar with the FRC driver station). The only thing I thought was missing was the ability to clear the log screen. We use this a lot when we are getting periodic overruns in FTC. A clear screen makes new messages more obvious.

[gearsincorg]

Robot Code 5/11/2026

Spent some time today re-discovering that the ExHub example doesn't deploy and run.
Anyone following the Testing Instructions closely will go down this dead end :(

So I used @cadandcookies's sample code and got the robot depoyed and running as a basic Timed Robot.

Comment: One thing I discovered during this process was that there was NO indication (that I could find) about what was going wrong with the robot with the ExH code. The Driver station flashed between "No Robot Code" and "Waiting for Robot Code" but there were no other errors, or prompts or stack dumps that I could see. The VSC "RioLog" was silent on the matter, likewise the Output, Terminal and Debug Console tabs.

In the future where will coders be able to view runtime errors?

Question: I added a simple SmartDashboard string to my teleopePeriodic, but it does not appear as an avaiable widget on the Elastic Dashboard.
I'm using Elasitic 2027.0.0. - Alpha 7 and all the other system data is being displayed (volts, temp, etc) but there are no SmartDashboard items. Am I just premature, or should I be sending dashboard data another way?

SmartDashboard.putNumber("Drive",-controls.getGamepad(0).getLeftY() );

[ThadHouse]

Did you update WPILib to alpha 6? That fixes a crash with the opmoderobot base class.

Essentially that symptom means code is crashing in a crash loop. Currently if it’s a Java crash the log for that ends up in the systemd log which is accessible from the web viewer. We’re working on getting that into the DS should be In the next WPILib update. But I bet you’re still on alpha 5, which that template will auto crash.

[gearsincorg]

Hi. Yeah, you guessed it. I had gone and checked for an update and saw Alpha 6. I installed it and the problem went away.
I just came back here to remove my comment only to see your reply.....

Should I be able to register somewhere for notifications on when there is a new wpilib release? I did check for WPILIB updates in VSC but none showed up.

Any thoughts on why I still cant send stuff to elastic?

[gearsincorg]

Robot Code 5/11/2026

Working with the DefaultTeleMode example program.
I set up a digital output on the systemcore that I can just toggle (i'm interested in fixed and variable periodic rates).

I notice that the standard periodic() task is being called regardless of whether the opmode is enabled or disabled.
I get pulses all the time.

Just wondering if this is a bug, or intended.

[ThadHouse]

Intended behaviors. The dio can toggle no matter enable state. Only pwm output can’t.

[ThadHouse]

Wait, actually that might not be true. I would need to check. I was only thinking about the dio toggling while disabled, not the function call itself.

[gearsincorg]

It seems like it's more complicated now...

Scenario 1)
If I have tele mode enabled when the syscore is powered up, I get pulses (periodic() runs) immediately (no enable required).
if I then switch to auto, pulses stop (good)
but if I switch back to tele I don't get pulses.

Scenario 2)
If I have Auto mode enabled when the syscore is powered up, I do not get pulses
if I then switch to Tele, pulses start (good)
if I then switch to auto, pulses stop (good)
but if I switch back to tele I don't get pulses.

It's like the calls to periodic() are enabled ONCE when Tele mode is initiated, but they don't run after that.

Since I don't know how to get diagnostic data onto the dashboard, I really don't know what state my code is in.

[PeterJohnson]

Yep that’s a bug. Can you open a github issue here for it?

[gearsincorg]

Yes, I can do that.
It's interesting... there appears to be some automatic transitioning going on, and that may be the problem.
I put the same monitoring in the Auto Opmode and it seems to be working OK, but I did notice that when you disable Auto, it automatically transitions back to Tele. I wonder if there is some other code in there looking for am auto transition that is preventing teleop from running twice.

I'll add it as two issues.

[ThadHouse]

The automatic transition to teleop happens in the DS automatically, and is expected. I'm suspecting this is all a single issue, where periodic() is getting ran when not expected.

[zachwaffle4]

Kind of. The problem was that opmode callbacks were added and removed during opmode transitions as opposed to enable/disable transitions, which (should be) fixed by wpilibsuite/allwpilib#8888.

Once the system switches away from the TeleOpmode (eg: switching to auto) , it does NEVER run again, even if you switch back to it.

What part of the opmode never runs again even after switching back to teleop?

[zachwaffle4]

Oh I just noticed #263. Thank you!

[gearsincorg]

[gearsincorg]

I just noticed that I can change Elastic's "Target Server" from SystemCore to "Robot Code".

Now I can see my Dashboard values... :)

That was probably my fault when I first started trying to use Elastic. "SystemCore" probably seemed like the correct option.

[ThadHouse]

Ah. Yes we need to make that clear. The systemcore one is for the system server. Not robot code.

[gearsincorg]

Periodic methods 5/12/2027

I’m investigating general OpMode performance to gauge improvements with the new system.

My first task is attempting to measure end-to-end command latencies by using digital inputs and outputs. I wanted to compare Android / Hybrid / SystemCore performance.

But I’ve hit a roadblock in my understanding of the new system.

I can see that the PeriodicOpMode class has an enabled Periodic rate of 20mS.
I have a Digital Output bit (GPIO0) that I toggle each periodic() call, and I have verified that it maintains a roughly 25Hz frequency (20 mS per half cycle).

I also saw that there is an addPeriodic() method whereby you can create additional period callbacks with different
periods.

From my FTC CSA work, I know that teams work hard to reduce the cycle times of their control loops so I was interested to see how fast this new callback could be run. So I created a new fastPeriodic() method which toggles a different DigitalOutput bit (GPIO1) and I have experimented with different periods for this callback.

I started off slow and set the period to 0.1 sec (100 mS), and I verified with an o’scope that the new pin was toggling every 100 mS.
Key: The bottom Yellow trace is GPIO 0 (default 20mS period), and the upper Blue trace is GPIO1 (fastPeriodic().

The confusion started when I tried to decrease the period below the default 20mS.
At 5mS the pin started to have somewhat erratic transitions.

At 1mS the GPIO was pretty much random noise.

So I guess my question is: What is the expected min periodic interval to be able to get consistent timing performance, and/or am I doing something wrong here (eg: should not be using periodicOpMode).

[gearsincorg]

I Definately agree that documenting expected performance will be a great benefit to teams. There are many FTC teams that currently optimize mSecs out of loop times for advanced control.

I am generally just exploring the limits... and also determining the optimal ways to do the things (it will help in my future CSA tasks).

I don't have any specific use cases that require precise GPIO writes, although it's not unheard of for somone to pulse an output pin to indicate a code condition during debugging... I've discovered that that is not a good technique in this system :)

I'm intrigued why Reading the GPIO is not a simmilar problem to writing, or are these being updated in the background.?
And are analog reads also not a bottleneck?

Before I move on, how much would this unseen asynchronous loss of "writes" encroach into other areas? eg: I2C, USB commands over to the Expansion Hub, and CAN. If I understand this better, I won't go down another rabbit hole. (Is there an architecture document somewhere I could read?)

[zachwaffle4]

I now understand that "when" the callbacks are added by the framework effects when calling addPeriodic() is effective. ie: only works if done before the frameworks adds them, yes?

Yup. This will be made more clear in the javadoc in future versions.

Based on this new info... if the user wants a new periodic function to run while the opmode is disabled, they would need them to be operational BEFORE start() was called, so defering adding till AFTER start() would make this impossible, so not a good idea.

What I actually meant was immediately before start during the same framework loop iteration (which is separate but at the same period as the opmode loop) that the robot is enabled. We could keep the framework's use of opmode.getCallbacks the same as it is in alphas 5/6 (where callbacks are added immediately following opmode construction) which would allow callbacks to run while disabled, but it would prevent callbacks from being added during start (which might be what you want?). We could also add opmode callbacks following construction and following start if that's what is wanted/there are use cases for it.

Conversly, If they only wanted some some periodic code to run once the opmoode is enabled, it seems like they would just need to check the opmode's enabled state. Can the OpMode read this directly, or would they just need to do it based on start() being called.

RobotState.isEnabled() can be used to see if the robot is enabled regardless of which opmode is selected.

It does seems like the doc comments for addPeriodic() need to define the calling scope (as in it must be done in the constructor to work).

The next update will define this more clearly (depending on what we end up deciding what the calling scope should be).

[ThadHouse]

I'm intrigued why Reading the GPIO is not a simmilar problem to writing, or are these being updated in the background.?
And are analog reads also not a bottleneck?

Yes, reads are updated in the background in that same periodic loop, both analog and digital. So they're updated 1000 times a second, no matter if you're reading them or not. When you do a read, you just get the last read value.

Something to think about in this system everything is asynchronous.

By definition CAN is asynchronous, and the Expansion Hub implementation is asynchronous as well, so they will exert similar behavior.

I2C is the only one without this behavior, as the writes are direct on the CPU and not asynchronous. And reads are just a write in disguise.

Thats definitely one of the biggest things that is going to be different in this new setup vs the Control Hub. Since essentially all IO is asynchronous, IO calls are essentially free. But if you do multiple writes to the same port in a single loop, its likely only the last one done in your control loop will be the one actually applied to the system.

[gearsincorg]

re: addPeriodic():

We could keep the framework's use of opmode.getCallbacks the same as it is in alphas 5/6 (where callbacks are added immediately following opmode construction) which would allow callbacks to run while disabled, but it would prevent callbacks from being added during start (which might be what you want?). We could also add opmode callbacks following construction and following start if that's what is wanted/there are use cases for it.

As long as the user knows that AddPeriodic() needs to be called in the constructor, I don't see a problem with only adding the callbacks following construction.

Adding opmode callbacks following construction AND following start might be nice, but it does not seem necessary.
Using RobotState.isEnabled() to skip code when not enabled seems like a good compromise.

Also, allowing the user to also add callbacks in start() might make is seem like you can add them anytime, which would not be the case.
So "constructor only" would eliminate any confusion.

[zachwaffle4]

My PR to fix #262 now also updates this documentation :).

[gearsincorg]

OK, so we have to watch out for multiple writes to the same port in one cycle... .Good to know.

How does this impact multiple writes (or commands) to say... A smart CAN bus motor.

eg: What if If we have to set several parameters on a single motor.. eg: setting the mode, configuring the max power and setting a target position. If these are individual commands can we issue them in quick sucession or do they need to be paced ? Will these overwrite each other or will they be buffered up? My mind is filling with what-if's.

[ThadHouse]

CAN is going to depend on the vendor, but I believe most will actualy make the configuration calls blocking, or at least wait a bit for a response.

Configuration is usually separate then position settings, which generally are automatically repeated. All of that is handled by the vendor for the CAN motor controller, so its hard to give generalizations.

CAN is generally a queue though, so writes won't be dropped from the queue unless its full, which generally will only happen if there is no devices at all on the bus.

The reason IO is different is because its part of the pub sub architecture, so the periodic loop just writes the last received value when that loop runs.

[gearsincorg]

OK, that makes sense... Thanks.

[gearsincorg]

Motor run Modes 5/13/2026

I am experimenting with the various motor run modes (on the Expansion Hub).
I have setThrottle() and setVoltage() working but I can't figure out how to get setVelocity() to work.

When I try, the motor does not move at all.

I see that there is an enable() method on the motors (which I'm not sure what it does), but the setVelocity() method does it's own enable() call so I figure that's not the issue. I also called setCountsToDistance() to make sure there wasn't some null scale factor.

I did wonder about the PID values, but it's odd that I can call to read them, but I did not find a place to be able to set them.

Here's my code.

[ThadHouse]

You set the PID constants by getting the PID object from the motor, and then calling the set functions on that object. All the gains are 0 by default, which is why it won't work.

[zachwaffle4]

You can do something like frontLeftDrive.getVelocityConstants().setPID(0.01, 0.0, 0.0); in your start method; the position constants can be similarly obtained and operated on with getPositionConstants().

[gearsincorg]

That's very helpfull, thanks.

Given that the defaults are 0, it might be helpfull to reference the getVelocityConstants().setPID() method in the setVelocity doc comments. Just so folks would know where to get started. It wasn't intuative to me that I needed to do a "get" in order to "set" these values.

Since the expansionhub.ExpansionHubMotor class is only going to be used on legacy FTC hardware, I was thinking it might be helpfull to default the velocity (and position) PID values to those of the current Expansion Hub firmware? It would probably also require a unity distancePerCount value.

This suggestion assumes the wpilib code is actually using the Expansion Hub closed loop firmware to set the velocity and position.
If this is not the case I guess it might be difficult to come up with an equivalent set of PID constants.

It just seems to me that this would be a hurdle that it would be nice to avoid during the transition. Not all teams are comfortable setting PID values in order to get speed control. Typically they just put the motors in "RUN_USING_ENCODER" mode and get pretty good speed control.

[ThadHouse]

It’s not using the built in PID, because we can run it faster externally. I agree we probably want to come up with some kind of default values to use.

[gearsincorg]

Motor PID testing 5/18/2026

I'm working on developing some more understanding regarding motor controls, and I'm stuggling know the best way to analyse data.

Without a Telemetry feed, I can't just display the data I'm collecting.
Unfortunately AdvantageKit does not work with a beta 5 or 6, so I'm looking for other advice/suggestions.

So I'm not sure what the best form of logging to use, to be able to easilly create and display test data.

Can I log to a file? and how would I then get that file?
Any code snipits would be very helpfull.

In other words, how are the developers doing testing?

Phil.

[ThadHouse]

AdvantageKit definitely works with Alpha 5/6. What's specifically not working?

[jwbonner]

AdvantageKit is not updated for alpha 5/6, and the OpMode/DS changes are significant breaking changes to the parts of WPILib that are the most integrated with logging and replay. I would not expect the current releases of AdvantageKit to work correctly.

[ThadHouse]

Oh, I misread AdvantageKit for AdvantageScope. You can just use SmartDashboard calls currently, and then AdvantageScope to view that.

[spacey-sooty]

For logging for now I'd suggest looking at Epilogue https://docs.wpilib.org/en/stable/docs/software/telemetry/robot-telemetry-with-annotations.html#new-for-2025-robot-telemetry-with-annotations-java-only it's shipped with WPILib and will allow you to log to a file or live to network tables.

[gearsincorg]

Thanks for the great advice. Sometimes I have trouble remembering which world i'm in...
Sometimes I miss key elements in this odd wpilib environment (not quite FRC, not quite FTC)

[gearsincorg]

Observation: 6/10/2024

I just measured boot up times again, factoring the extra delay before the WiFi becomes active on the SystemCore.

We're sitting at 51 seconds, which is longer than the Control Hub's time-to-live.

Do we anticipate that this time can be made shorter with more customization?

[qwertychouskie]

Considering I currently have the new OS and DS software on the Driver Hub booting in ~12 seconds (from "first moment of physically pressing the power button" to "DS UI is showing"), so I'd expect that SystemCore boot time will get some optimization work before shipping. Granted, the ~12 seconds is not considering Wi-Fi connection time (wifi network connectivity configuration is not built into the DS yet), and the DS has a lot fewer things going on than the full robot controller, but on the other hand, there are avenues of Driver Hub optimization I haven't even considered yet (like u-boot's falcon mode), and that 12 seconds will almost certainly go down as I further optimize.

Personally, I'd consider anything longer than 20 seconds on SystemCore from switch on to robot code running to mean there's some major missing optimizations. Things like the web UI, on-bot VSCode, etc I would expect to take longer to load, but loading of critical components (NT server, heartbeat kernel module, DS communication service, the robot code itself) should be able to happen very early in the boot process, while deferring the non-critical stuff until the critical stuff is up (so they aren't fighting for CPU/IO/etc). https://www.phoronix.com/news/Boot-Time-Wizard-Linux might also be helpful.

[gearsincorg]

Hardware notes: 6/12/2026

A small epiphany: Since the spline shafts have an 8mm OD, it's possible to use all of the 8mm goBILDA clamping hardware.
eg: the 1309 Series Sonic Hub (8mm Bore) and the 2910 Series Aliminum Clamping Collar (8mm ID).

I don't think I'd use these on an aluminum spline shaft, but for steel, I think they's be OK for morderate torque (wheels or simple retainment).

West Coast Products does have some existing shaft/clamp options.
https://wcproducts.com/products/splinexs-accessories

It would be interesting to see if you could convert a 6mm clamp into an 8mm spline clamp using a pill broach.
It is an expensive option...

[gearsincorg]

Articulated Arm: 6/14/2026

This is a long post with several observations. So, apologies in advance.

I decided it was time to start using the A301 motors in an arm. So, I designed an articulated arm with a shoulder and elbow joint. I used a direct drive motor at each joint with the 215 RPM gearbox on each. The first (Lower Arm) segment is 280mm long and the second (Upper Arm) segment is 260mm long. This size was chosen so I could 3D Print each segment.

I wanted to experiment with different motor control methods, starting with the built-in ones and moving on to more home-brew methods.

Design Strategy: The arm is coded so that the end-point moves orthogonally. That is up/down DPAD buttons move the endpoint vertically (Y direction) and left/right DPAD buttons mover the arm horizontally (X direction) so the code does the Inverse Kinematic calculations to determine the desired joint (motor) movements. This seemed like the most challenging requirements for motor control.

The arm is pictured below. I used 8mm goBILDA Hub Clamps to attach the arm segments. I calibrated the Absolute encoders (using RHC2) to have the required zero offset positions.

My first approach was to use the A301’s absolute position mode. On startup, the code reads the motor angles and determines the resultant X/Y position in space. It then uses the DPAD controls to move the target X & Y position. Each 20mS interval, a new desired X,Y position is generated and the IK code determines the desired angles which are sent to the A301’s using the setPosition() mode.
This method was effective, and quite responsive, although it was a bit jerky. In the video below you can see the arm endpoint moving orthogonally under DPAD control.

Basic.Position.mp4

In an attempt to make the movements smoother, I moved the control loop to a faster periodic thread. Strangely this did not move the movement appreciably smoother. I then realized that the jerkiness was due to the button scanning rate, so I modified the code so that the button action requested a movement velocity, and the control loop interpreted this movement request into more frequently updated positions. So, still using setPosition() calls but with the target position updated more frequently. This produced a much smoother movement (see video below).

Smooth.Position.mp4

I was able to push the control rate up to 1000 Hz, although this ended up not being necessary for smooth motion. At this rate the SC was running at about 80% CPU utilization (remembering that it’s doing the Inverse Kinematic function every cycle).

Next, I decided to try using the A301 Velocity control mode and have the code convert the orthogonal velocity requests directly into motor velocity requests.

This approach was MUCH less successful.

The motors just DID NOT respond as expected. I had thought that since the setPosition() had no trouble acheiving the needed velcities, the setVelocity() mode should be even smoother. After much testing I decided that the A301’s internal velocity controller was not configured to be highly responsive to the varying loads presented by the arm. Specifically, the varying load caused by gravity acting on the motor at the end of the arm. Even though the position controller was able to respond instantly, the velocity controller took upwards of a second the build sufficient torque to lift the motor when it was extended horizontally.

Since my code was assuming that both motors were responding similarly to velocity requests, this disparity caused completely invalid arm movement combinations.

The video below shows the lower arm struggling to respond to small velocity requests. The tip is being requested to move horizontally, but the Shoulder motor needs to lif, and it does not respond quickly enough.

Velocity.Motion.mp4

My assumption is that the A301’s position control loop is using maximum velocity to move between positions so its response is more immediate and so it can have higher gains. Whereas the velocity control loop must allow a full range of velocities, so it’s tuned for a stable response at all speeds.

This points to the need for either: 1) A velocity control mode that allows for a few different feedforward models like Arm and Elevator or 2) Specialty control will require the user using external PIDF controls.

The third portion of my Arm testing (in progress) is to see if I can implement better control using purely external closed loop code coupled with the motor setThrottle() controls. Results to follow.

[ThadHouse]

Just curious, where'd you get 50ms and 20Hz from? By default, the WPILib control loops run at 50 Hz (20ms).

[gearsincorg]

Sorry, I miss-typed. I'll fix that.

[gearsincorg]

Although the arm is shaking at a lower frequency than 50 Hz, so it seems like something else must be at play there. More investigation is warrented.

[gearsincorg]

Articulated Arm: 6/17/2026

Just finished evaluating a Closed Loop Position controller for the arm where the loop is closed in code, rather than in the motor itself.
As with the other control modes, this mode uses the A301's absolute encoders for reading the position of the arm, and Inverse Kinematics to determine correct arm angles for the desired motion.

Because the loop is being closed in code, I was able to implement a throttle bias to overcome the weight of the arm, based on its current angle from horizontal. I determined this bias by zeroing out the PID coefficients and moving the arm to the horizontal position. I then increased the holding power until the arm no longer drooped under gravity. I did try also adding a kS (static friction) term to overcome the motor’s throttle deadband, but this addition disrupted my controller, so I eliminated it.

The code reads the DPAD button and determines a jog velocity in the X and Y axes, and then calculates the updated joint positions. The setThrottle() call is used to drive the joints towards those new positions, with the control loops correcting for position error. The control loop runs at 200Hz. See video below.

Closed.Loop.mp4

After some tuning I was able to generate smooth control with only a Proportional term for each joint. It’s seen in the video below pushing a 1Kg filament spool.

Pushing.mp4

[gearsincorg]

I was asked to compare the performance of the Onboard A301 Position control vs my best shot at an external PID controller.

I wanted to compare apples with apples so I set both code bases up with a 200 Hz control/command loop with interpolated joint position every control cycle.

Since my code has a DPAD jog velocity constant, I compared the control cycles with both a fast and slow jog.

With a fast arm Jog (in the 12-14 inches per sec range) there wasn't much difference between the two control methods. Both were equally responsive, and seemed to have good control

With a slow jog (4 inches per second) there was a noticable difference.

• The A301's Onboard Position control was more responsive and held tighter control. The arm did tend to vibrate as it moved even when I increased the control rate. This vibration wasn't due to backlash or other mechanical issues because if I held the arm as it moved it still vibrated. I don't know if this is some internal deadbanding that happens in Position mode, but it was more visually annoying than anything

• With the offboard (java) PID I wan't able to get the arm to move precisely to follow the slow motion. It either lagged behind or oscillated. I tried adjusting the gains, and playing with a kS term to overcome friction, but I wasn't able to get it to respond quickly to small changes. My caveat is that I'm not a PID expert, so it's likley that somone can probably get a better response. but it's hard to predict.

[jfabellera]

I'd expect that increasing the frequency of the encoder position data would help in both cases, more so in the offboard PID

Unfortunately adjusting status periods isn't support in the current release.

[gearsincorg]

Oh, that's right, the feedback rate is fixed. Is that 50ms?

[gearsincorg]

ARM control update.

It turns out the the Jerkyness that was occuring with the Arm under Onbaord Position Control was not a software/firmware issue, but rather a motor issue. The motor on the upper arm seems to be jerky by nature. Even unpowered the output seems more coggy than the other motors. I replaced that motor and now the arm is much smoother with no code changes. Discussions with REV would indicate that there are still some manufacturing tollerences that need to be refined.

[gearsincorg]

I just had that weird "motors won't run" bug/condition again.

It hapenned just after I downloaded a small code change. I have more data this time.

Despite the DS shows the robot being enabled/disabled, all the motor LEDS stay in the classic "disabled" slow blinking purple.

I captured the Systemcore and Motioncore status pages this time. The video below shows that everything appears to be working but there is no CAN bus activity showing on the systemcore page. The odd thing is that the Motioncore page DOES show that the 5 motors are present, so there must be some communication happening between the SC and MC. The second part of the video shows the exact system after a power cycle.

Motor.Disable.mp4

[jfabellera]

I like that video transition

[gearsincorg]

QUESTION: What gets displayed on the new "Display" pane on the Driver Station? Is this something that the user code can utilize?

ps: thanks for the log reset button :)

[zachwaffle4]

This is user-controlled display that is similar to the current FTC DS telemetry view. In Alpha 7, there will be a DriverStationDisplay class with static methods like DriverStationDisplay.addData, addLine, and updateLines.

[gearsincorg]

Announcement: I'll be taking the G-FORCE A301 Kiwi Drive robot to the MTI (Multinational Tech Invitational) event this weekend and will be demonstrating the new control system. The crew from 19458 will also be demonstrating their Systemcore Legacy robot.

In addition to the Kiwi Drive, our bot features an I2C Octoquad Odometry module with two Odom Pods, a Logitech camera doing AprilTag tracking, a two-axis arm doing Inverse Kinematic control, Autonomous path following (PathPlanner hack) and a demo Driver station with Live vision and robot field rendering.

[qwertychouskie]

If you have an extra driver hub on hand, consider loading up the OS image from #308 (comment), it'd be cool to show it off with the actual DS hardware you'll use :)

[gearsincorg]

I’ve spent the last two days (20 hours) at MTI, demonstrating, explaining and taking-feedback on the new control system. It’s worth saying that although the teams at this international event are “world class”, in many cases their organizations ALSO work with a wider group of associated teams of all experience levels, and so I felt I was getting a good-cross section of teams by talking with coaches. I estimate I spoke one-on-one to between 120 and 160 people.

People came to the conversation with many viewpoints such as:
• Never heard of the new control system.
• Heard of the system and eager to learn about it.
• Knowledgeable about it and pleased to get “hands on”.
• Looking forward to change.
• Concerned about change.

No matter what their viewpoint, people were eager to learn more about the system.

Here is a summary of responses after our discussion/demonstration.

1. Everyone left eager to try the new system.
2. Coaches appreciated the transition process with “legacy” hardware support.
3. Teams were particularly hopeful for improved performance.
4. Everyone appreciated the Raspberry Pi Compute Engine approach.
5. Everyone was happy with the language support options.
6. Everyone liked the Driver station capabilities, but wanted to know what the hardware platform would be.
7. No-one was very happy about the removal of mini and micro servo capability.

I feel strongly that being able to see and talk about the new system removed most “concerned” coaches fears about adopting the new system.

To address the general concern about loss of the smaller servo options, I went to each of the 44 team pits and asked teams how many smaller servos they were using this year, and why. It became clear that the mini and micro servo demands were very game specific.

No teams were using micro servos this year, but all of them said they used them on manipulators or transfers last year. Many teams were using slim or mini Axon/Swyft servos this year, but they were doing it to get faster motion rather than smaller size.

One interesting concern came up several times when discussing this with coaches. The consensus seemed to be that skipping mini/micro servos would not be a major handicap for the high-end teams because they would be able to engineer solutions using complex mechanisms, 3D printed parts and custom software. Plus the added expense of the A301’s was incidental.

However, with rookie, or limited-resource teams it would have more impact. Normally they would be able to purchase and use a $10 Amazon micro servo to directly actuate a lightweight end-effector. But the new system would require a more complicated and costlier solution, using tools or equipment (like CAD and 3D printing) that they may not have access to. This did seem like a handicap for getting the widest adoption overall.

The only other consistant comment was that the high-performing teams wanted to definitely know that the new motors would perform at least as well, and hopefully better than the current motors. If this wasn’t the case they would be hesitant to change. I was unable to really provide any assurances on this.

Based on this, I’ve tasked myself with performing my own test as we move forward to determine some of these parameters, so I can answer with confidence in the future.

[gearsincorg]

I just did the A301 Firmware upgrade (to alpha 15). I heeded all the warnings, and it was painless…

Just wanted to describe the steps in more detail for others:

DOWNLOADING new files.

1. Download the new A301 firmware (.15) to your hard drive from here:

2. Download the Rev Hardware Client 2 (RHC2) to your hard drive from here

UPDATE Rev Hardware Client

3. Connect to the SystemCore via Wi-Fi and navigate to robot.local
4. Click on Add Package
5. Drag the RHC2 file and drop it on the popup. It will remove any prior version and install the new one. Exit when done

UPDATE A301 firmware

6. Run the new RHC2
7. Click on the Orange “Update Manager” at the top right
8. Select the Device Type of A301
9. Click Select All
10. Click Select Firmware Update (Even though it looks grayed out)
11. Select “Custom” and then “Choose File”
12. Point to the A301 firmware you just downloaded. (ends in _15.dfu)
13. Click “Install” and wait for it to complete.
14. Close the popup when done. Exit browser.

UPDATE REVLib library

15. Open VS Code and your project.
16. Open the WPILIB Pallet (CTRL SHIFT P)
17. Select: WPILIB: Manage Vendor Libraries
18. Click: Check for Updates (ONLINE)
19. It should show at least the new REVLib library. Select it and click “Update”
20. Rebuild your project and correct any REVLib calls that may have changed.

[gearsincorg]

Battery Issues: 7/24/26

I just went to power up my A301 robot for the first time in about 5 days and I discovered that I had left the battery switch on, and the battery was dead.

When I went to charge it, the charger responded with a flashing red/green LED, which the ledgend on the side listed as "broken".
Undaunted I unplugged and re-plugged the battery several times over the next hour, and it's still reading BROKEN.

If I really need to replace a $130 battery every time a kid (or coach :) forgets to turn off the robot at a weekly practice... phew...

[Kevin-OConnor]

Yes, the dock does include Low Voltage Cutoff which I would have expected to prevent this. I agree it's concerning that discharging with that official dock can so easily result in a battery state that will not be charged by the charger. While the current system also suffers from over-discharge of batteries causing permanent damage, the increased cost of the battery does make that more painful and is an area we were hoping to see improvement by moving to the tool battery ecosystem.

[gearsincorg]

A little AI research returned this information:

Milwaukee REDLITHIUM batteries feature low-voltage discharge protection, but the cutoff mechanism is managed by REDLINK Intelligence through communication between the battery and the cordless tool rather than a hard electronic power switch inside the battery pack itself.

How the Protection WorksSystem Communication: The onboard electronics in the battery talk to the electronic speed control board inside your Milwaukee Cordless Tools or Milwaukee Tool-Managed Shutoff:

When cell voltage drops to a safe minimum threshold during operation, the tool's computer stops the motor to prevent permanent over-discharge.

Risks with Custom DIY Adapters No Standalone Cutoff: Because the power-cutting FETs/transistors are located on the tool's electronic board and not directly severing the main output terminals inside the battery, a bare battery connected to a non-MILWAUKEE DIY project (via an adapter without its own circuitry) will not shut itself off.

Over-Drain Danger: Running a raw Milwaukee battery down on a custom light or a non-communicating device can drain the pack past the point of recovery, causing the charger to reject it with a flashing red/green error light.

[Kevin-OConnor]

Yes, at least Dewalt and Milwaukee function that way while some others put the LVC in the battery pack itself.

The prototype battery dock contains the official Milwaukee OEM battery adapter inside it which should be handling this correctly. I have run my prototype robot to low voltage cutoff at least once without issue, but that was monitored and so I swapped it out soon after it shut off vs this longer term situation. It seems like something clearly something went wrong in this case and allowed your battery to be discharged beyond the desired level. There are some other considerations within the dock that had to be made to work around some issues with battery shutdown during "idle" which may be related. We'll definitely dig into this further.

[qwertychouskie]

I'm rather unclear on the battery rollout plan as a whole, I tried to get clarification around when the alpha test kits first started rolling out to teams but didn't get very far in all the rollout craziness. If you are able to clarify some things I'd greatly appreciate it:

• Is the plan to use Milwaukee batteries in the final Limelight product, or was Milwaukee just chosen for the initial alpha test? (I heard claims that Milwaukee batteries/components were donated, and that's why they were used for the alpha test, but haven't been able to verify that.) While Milwaukee batteries can be gotten for a decent price e.g. from Amazon, in-store prices are significantly higher than basically all other tool battery brands. (Honestly I'd probably recommend Ryobi batteries for their price if it weren't for the shape being very poor for robots...)
• Perhaps this is more a question for FIRST, but is it planned to only allow a single battery dock model, or will other comparable battery docks also be considered legal? For example, our team uses goBILDA and has a bunch of DeWalt batteries, so if legal, we'd almost certainly prefer to use the goBILDA® Smart Dock.
• Will the final Limelight dock have the ability to move the switch, like the goBILDA dock?

[Kevin-OConnor]

• Is the plan to use Milwaukee batteries in the final Limelight product, or was Milwaukee just chosen for the initial alpha test? (I heard claims that Milwaukee batteries/components were donated, and that's why they were used for the alpha test, but haven't been able to verify that.) While Milwaukee batteries can be gotten for a decent price e.g. from Amazon, in-store prices are significantly higher than basically all other tool battery brands. (Honestly I'd probably recommend Ryobi batteries for their price if it weren't for the shape being very poor for robots...)

The battery dock is currently being developed by REV, not Limelight. We have not finalized plans for number or brands of dock SKUs to get the local availability and pricing we want across all regions.

• Perhaps this is more a question for FIRST, but is it planned to only allow a single battery dock model, or will other comparable battery docks also be considered legal? For example, our team uses goBILDA and has a bunch of DeWalt batteries, so if legal, we'd almost certainly prefer to use the goBILDA® Smart Dock.
• Will the final Limelight dock have the ability to move the switch, like the goBILDA dock?

We have not yet finalized any of these plans around the battery dock to be able to answer this question. I have certainly seen the feedback related to the particular switch location on the prototype dock as well as some feedback on the idea of the switch being hard integrated at all vs. remote switch.

[gearsincorg]

Investigating vision processing. 8/2/2026

I had no idea that the vision system was integrated into the Systemcore until @alan421 made an obscure post about cameras.

Just .... wow...

So I've been investigating and comparing to what I'm used to with Limelight, PhotonVision, FTC and plain OpenCV.

My first questions relate to camera specifics.

1. I'm using an off-brand camera that systemcore identifies as: "Unsupported". It seems to work fine, so what aspects do "Unsupported" refer to?

2. The Resolution and FPS are listed as 1280.720 30FPS. The preview video is clearly much less thatn this (maybe 640x480) but I could find any way to temporarily increase this for clearer calibration, or image comparisons. (Oh.. I just found the "Focus" page)

3. Is calibration currently operational? What is the process? Take snapshots on main camera page and then proceed to calibration page? I can't tell if snaphots are full or reduced resolution. It would be nice if the calibration process showed full resolution.

Next: Apriltags.
Having used lots of systems, I was interested to see which axis display convention this library used for the Tag's RGB x,y,z lines. It appears that it's the unique WPILIB convention of Z up (neither in nor out of the tag image) It's a shame this doesn't match the Offical Apriltag convention (also used by OpenCV and FTC) .. but oh well.

I will note that the drawing order of the Red, Green and Blue lines make it hard to get the correct 3D sense of the RED line (that is pointing out of the page). It appears to be drawn first of the three lines, so it's often occluded by the green and blue lines, which makes it "appear" to be pointing back INTO the page, although it's position indicates that it's pointing out. This would be nice to get fixed.

[bhjelstrom]

Noted on the axis ordering

1. Unsupported means we have not purchased the camera, tested it, worked out all of its UVC driver bugs, calibrated it, etc.
2. Correct, focus pipeline is the solution
3. Take snapshots, which are at full res always. Then calibrate. After calibratoin, you can download a calibration mosaic or view the 3d calibration aggregator

Until about a month ago, we used the default apriltag coordinate system for apriltags. We recently unified all coordinate systems to match NWU, Right hand, +x = forward convention. In general it is nicer to have one 3D coordinate system convention which is often accompanied by one other "optical" 2d convention as is seen in LL, ROS, game engines, etc

[gearsincorg]

Upgrading to Alpha 13. 8/3/2026

I've just started updating my robot code form MTI to use the new Beta 15.

The first thing I noticed was that I was no longer getting any camera video, which wasalso displaying my Apriltag results (see June 23 post above).
I know that the new OS is doing a ton of it's own video processing, but I did not expect it to make my code fail.

I'm currently processing video as follows:

  /** The image-processing loop. Runs on its own thread until the JVM exits. */
  private void visionLoop() {
    UsbCamera camera = CameraServer.startAutomaticCapture(VisionConstants.kCameraDevice);
    camera.setResolution(VisionConstants.kCameraWidth, VisionConstants.kCameraHeight);
    camera.setFPS(VisionConstants.kCameraFps);

    CvSink sink = CameraServer.getVideo();
    CvSource outputStream =
        CameraServer.putVideo(
            "AprilTagDetections", VisionConstants.kCameraWidth, VisionConstants.kCameraHeight);

I currently display "CameraPublisher/AprilTagDetections" to get my processed video and data.

Although there is now ALSO a limelightsc3 SmartDashboard item, it does not contain any video.

Questions:

1. If I want to do independant video processing, how should I be obtaining raw video.
2. Where do I look to learn how to use the new built-in video system

[Kevin-OConnor]

1. The current OS definitely monopolizes the camera in a way that's unintended. Added Built-in vision functionality monopolizes camera #353 to track. Your code as is should be fine with the current WPILib release (but currently isn't because of the OS). The next WPILib release will split the Camera Server and Apriltag parts of the library out as "vendordeps" which you will have to opt into to help avoid too much clutter with the built-in Limelight functionality. But that code is intended to continue working.
2. The documentation that exists so far for the LL vision functionality is in https://github.com/wpilibsuite/SystemcoreTesting/blob/main/LimelightVision.md

[gearsincorg]

@Kevin-OConnor I'd like to have "video with apriltags" displaying on the Driver station for the CHS Mentors confernce this weekend. Do I need to revert the OS to get this working again by then?

[Kevin-OConnor]

Yes, if the built in LL stuff doesn't do what you want, reverting OS is probably your best short term bet

[gearsincorg]

So I figured it out. I had expanded the limelightsc3 item looking for something that would add itself to the elastic dashboard as a camera feed, but I didn't try just pulling the whole object. Once I did that I was able to get the feed I wanted. Now that I have that I can switch over to the limelight's apriltag data (I think :)

[gearsincorg]

Bug: When resizing the items on the web-based built-in Elastic view, CTRL + zooms in, but Ctrl - is ignored.

[gearsincorg]

Question: The placeholder for VS Code has been removed from the SystemCore web view. I assume it's coming back at some point.

[bhjelstrom]

It will come back at some point.

[gearsincorg]

wpilib apriltag vs Limelight 8/5/2026

So far I'm dissapointed with the integrated limelight Apriltag processing vs my initial wpilib.apriltag.apriltagPoseEstimator() usage

This may or may not be a fair comparison, because even though I'm using exactly the same robot,camera and drive algorithm, I don't have complete visibility into the limelight configuration so I don't know if there is a setting that is making a difference here....

My original code used AprilTagDetector and AprilTagPoseEstimator
With limelite I'm using the targetpose_robotspace to determine the position and orientation of the tag.

The immidate difference I see is that the Limelight estimator has a large yaw discontinuity near the zero degrees point. This is significant as my Tag approach code uses this value the get directly in front of the tag. I'm seeing a yaw jump form -23 to +14 degrees with minimal actual robot rotation, so it ends up jump-strafing left and right as it gets in front of the tag. I know that this measurment is based on image skew, and it's subject to image resolution and quality.... BUT the original code was very stable across the zero transition.

I know there are many different algorithms for estimating the tag orientation but Limelight and WPILIB must be using different ones. I know when we added Apriltags to the FTC_SDK, we took a lot of time to choose the most appropriate one.

My original code was using either 800x600 or 640x480 for the image resolution (I have to reinstall the OS to verify).

Limelight identifies the source camera as 1280x720, with a stream resolution (mode) of 320x240. I don't know how either of these relates to the actual image that's being processed.

I've tried changing the detector downscaling but it only effects the frame rate, and not the quality.

Bottom line, the X, Y & Z values are fine, but the Yaw angle is unusable.

So. I could do a simple point and approach with this data, but alligning in front of the target is very unstable.

I'm sweeping the yaw angle very slowly. Watch the YAW value on the display and see how the tag frame jumps.

2026-08-05.22-14-38.mp4

[gearsincorg]

I did an 80 image calibration and it greatly improved the accuracy of the AptilTag pose. The Yaw transition is smooth across 0 degrees. Yay!

One glitch in the calibration operation was trying to figure out to activate the "correct" calibration: There are three choices: Default, Custom or Latest.

In the end I saved the "latest" calibration, and then Uploaded it back again. That made it the "custom" one, which was then active.

What would have been more intuative would be for there to be a button above each of the three calibration sources. One should say "Active" and the other two should say "Activate" or something to that effect. Or conversely, one of the Advanced camera settings should be "Calibration source".

I also noticed that the Detector Downscale value made a LARGE difference in CPU processing. A downselect of 4 brought the CPU usage from 85% down to 60% without having a marked effect in the detection at moderate range. Pulling the camera alltogether dropped it to 40%.

[bhjelstrom]

I'm glad to hear that things are working now! We will look into making the calibration activation easier. We originally wanted to force teams to download the file to make sure backups were saved, but the new OTA update features take care of this now.

Also, unsupported cameras will always force you into a single video mode. There are many reasons for this, including the tendency for UVC cameras to have quirks related to video mode changes. Curated/Supported cameras feature a small number of modes (usually one or two) that we have selected as optimal for vision processing. We want downscaling to be the primary knob for Apriltag range, so we deliberately eliminate most video modes.

Default calibrations wont be live until alpha/beta 14

We have your camera on the way and can make it an officially supported model

[bhjelstrom]

While we have not calibrated the camera, we received the N60 (hopefully it is the same one that you have) and added support for it in the official alpha/beta 13 release. We now expose two modes: 1MP 30FPS default, and 2MP/1080P 30FPS

[gearsincorg]

That's great to hear.

I know there is a current "issue" to provide a "none" pipeline, and maybe that will cover my next suggestion.

1. With the new ease of adding multiple cameras there will definately be the need to be able to enable and disable camera processing. to manage CPU utilization. eg: A color camera doing object recognition in Auto that's not needed in Telop. So being able to cleanly switch cameras on/off will be a usefull feature.

2. Also, being able to dynamically change the Detector Downscale for a given pipeline will also enable teams to manage CPU usage.. eg: low downscaling when tags are far away and only ID's are required, vs high downscaling when a Tag is up close and high refresh rate is desired for aiming. (We currently have this with FTC_SDK)

3. Regarding exposed modes in general. I have noticed that when using a 4:3 aspect vs a 16:9, the squarer 4:3 usually provides a greater viewed region because it uses more of the image sensor area. 16:9 is often just cropped out of the middle of the sensor and ignores lower and upper areas. So when exposing different resolutions, having one of each aspect ratio is probaly more importent than just different resolutions of the same aspect ratio.

[bhjelstrom]

Agreed on 1, currently the idea is to switch to a viewfinder pipeline and switch back, but I think we will end up with a dedicated flag in the API for "forceViewfinder". I can see value in a further reduced mode that turns the stream black to minimize cpu as you're suggesting

Docs will soon be live which will help here, but you can call
(limelight).setFiducialDownscalingOverride(Limelight.DownscaleOverride)

The current thought is to always use the aspect ratio that exposes the greatest sensor area, and to stick with it across all exposed video modes. The reason for this is that calibrations scale up and down across modes as long as you don't change FOV. So for any cameras with 4x3 and 16x9, I think we have eliminated the 16x9 modes so far. Thoughts?