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]

Motor PID testing 5/18/2026

I had partial success with motor testing today.
I setup a testbed with a single free running GoBILDA 435 RPM motor and a pair of GoBILDA 1150 RPM motors running a geared down drive.
I set the DistancePerCount constant to 1.0 so the code essentially read encoder pulses as distance units.

Note: these motors had a typical top speed of about 2500 CPS at 12V

Starting with the unloaded motor I Ran a characterizing opmode to determine kS and kV constants for velocity feed forward.

I determine that values of: kS = 0.5 and kV or 0.004 provided very good velocity control with no PID constants.
I'd recommend these as good default values for an unloaded GoBILDA style motor.

Next I moved on the the drive motors which were loaded by the geared drive. One motor was driving 3 wheels.
I created a test opmode that would enable me to step the velocity target for a motor up and down in increments of 500 CPS.

The unloaded motor moved quickly between the requested velocities, but the loded motors did not reach the requested velocities.
This is because the system was essentially still open loop (with no PID gains)

So I then started experimenting with the PID gains.
I determined that a P gain of 0.006 was a good compromise between rise-time and stability.

However, when I tried to determine the kI gain that would allow the motor to adapt to high drag, I was not able to effect any change.

I feel that there is a probem with the Integral calculation (or constant use). I could apply extreme I values from 0.001-100.0 and all it did was make the drive chatter when I requested zero velocity. Once I requested a non zero velocity, it didn't seem to have any integral term.

I wondered if the integral term was being zoned, with a very small window, but I was not able to find the code that actually did the calculation.

Have I missed something? If not, could somone point me to the output calculation code so I could review it.

Code:

[gearsincorg]

Looking at the changing velocity values during my testing, I see that there is a 20 CPS resolution.
You said you are running it faster... How fast is it actually running?

Just spitballing here.....
I am thinking that this 20 count resolution is because you are taking the encoder counts per cycle and dividing it by the cycle period (0.05 or 1/20) sec to get (in my case) counts per second. so 20 Hz ?

[ThadHouse]

https://github.com/wpilibsuite/scservices/blob/main/expansionhub/VelocityController.cpp

The PID controller is here. Its running at 83.3 Hz

For encoder counts, we're just reporting exactly what the expansion hub gives back to us. The only manipulation we do is a distance per count computation, but since you've set that to 1 that goes away.

[gearsincorg]

I checked the lib code and didn't see any issues. So I redid some of my testing and WAS able to see the impact of the Integral term on the lower RPM motor. Apparently the High RPM motor wasn't able to overcome the added load I was introducing because even with more drive power it didn't have enough torque to maintain the correct speed.... so no issues there.

I was able to come up with a set of PID and FF constants that worked well. The thing I also verified was that if I changed the DistancePerCount factor, I also needed to adjust all but one of the constants to obtain the same stable velocity behavior. As seen in my new test program.

Ultimately I wasn't able to get the velocity response as stable as I wanted because the call to set the iZone was not exposed (that I could see). So, the integral is kicking in when there is a large jump in velocity demand. It takes a moment for this to wind down.

I haven't tried using setPositionSetpoint() yet. I'm still trying to figure out what the S term is on the position controller.

[gearsincorg]

Hardware Arrives !! 5/21/2028

Exciting times. FedEx just delivered the rest of the Alpha Test hardware:

Inventory list:

8 x A301 motor packs (each with two gearboxes and mic mounting hardware);
1 x Battery charger
1 x M18 Red Lithium High Output CP3.0 battery
1 x Battery Dock
1 x length of spline shaft.

I though I was missing the main power cable, but then I checked the bag of cables I originally received with the System core.
Amagine my chagrin when I found not only a 18V power cable, but a 12V XT30 adapter cable as well. I guess I didn't need to cababalize that CAN/power cable to get up and running... D'oh!

[gearsincorg]

General testing 5/22/2028

I noticed something on the current driver station that is differernt from the FRC DS, and somewhat annoying :)

While the system is enabled, if you hit the spacebar (in any window) the robot goes into Emergency Stop mode ... normal.

However, when it's E-Stopped, the Restart Robot Code and Reboot Robot buttons are grayed out.
Which means the only way to get out of E-Stop is to power cycle the robot.

I don't think this is the case in FRC.
Since those buttons are on a different panel, it takes a definate action to release the E-STOP so it doesn't seem like a safety issue to keep them enabled. And it saves the time for the OS to boot and wifi to come alive etc. when you hit spacebar by mistake.

Just providing some developer feedback :)

[Gold856]

I got the perfect trick for you. https://github.com/wpilibsuite/FirstDriverStation-Public/blob/main/docs/KeyboardShortcuts.md

[gearsincorg]

ESC I. too cool. thank you :)

[ThadHouse]

Btw it’s not actually a different behavior from the ni ds to disable those buttons. It did so too.

It did not have esc I thought, that’s new :) and solves the problem in a much better way.

[gearsincorg]

A301 first run. 5/22/2026

Spent the evening installing and updating libs and firmware to get the A301's running.

First key instruction:

Read this page from top to bottom: https://github.com/wpilibsuite/SystemcoreTesting/blob/main/A301.md

I installed the REV Hardware Client 2 (RHC2) onto the System core and then was able to update the firmware on two A301 motors.
I just assembled a 2 motor test configuration on my desk.

After that I used the RHC2 to play with the motors, running them in the three modes (velocity, position and duty cycle).
Note: don't forget to use the driver station to enable the robot for this to work.

Then installed the new REVLIB library.
Note, if you can't use the standard online install, download and unzip the ofline lib file into C:\Users\Public\wpilib\2027_alpha5

Next I built a simple test program to run the two motors as if they were on a robot.
I used the prefered "velocity" mode for the motors and they ran well up to the speed designated on the gearboxes.

The only annomily was that the standard motor.setInverted() call that we would use to reverse the motors on one side of the robot was depricated. I tried calling it anyway, but both motors ran in the same direction. Not sure what the intent was here.

Anyway, I'm totally psyched to see the motors running.

[jfabellera]

That inverted issue is left over from SPARK because of its config system.. That will be fixed in the next release

[gearsincorg]

I've just noticed something new with the way my System core is booting.
It doesn't do it every time, but I've seen it a few times, and video'd it one time.

When I power on, the screen is blank for about 20 Sec, and then it goes through the normal spash creen sequence and gets to the normal status screen. But while it's starting up, the RED status LED on the SC is also flashing.
Once it's done this initial boot, it seems to immediatly do a second boot sequence, with the same splash screen again.

Looking at the video, it looks like the CAN bus does not start up the first time around.

The voltage from the Milwalkee battery say 16V. (it was charged yesterday).

It did it the first two times I powered it up today, but now it's not doing it.
I have a MotionCore attached with two A301's on ports 0 and 1 (see pic on last post)
I also have the RHC2 installed.

dual.boot.mp4

[ThadHouse]

Can you make a new issue for this? I’ve seen it once too.

[gearsincorg]

Is there a particular log file I can get that might be relevant? There are a lot, so I'm not sure which is relevant.

[ThadHouse]

I don't think so? My guess is the io daemon is starting too early, it's crashing, and thats boot looping the fw flasher. Likely CAN related, as the screen is showing X for CAN.

[bhjelstrom]

The boot log from the system tab will have everything we need since this isn't actually a system reboot. Do note this is just a microcontroller enumeration issue that we are actively working on. It is not related to CANBus or any other hardware elements, and there are multiple watchdogs in place that get it to a working state while we work on the root cause.

[gearsincorg]

IMU investigation 5/27/2026

I started experimenting with the onboard IMU today.
I initially just observed the IMU data on the Systemcore's web status page.
I did all my testing in "FLAT" mode, which I assume means the SC is laying FLAT on the robot (or table in my case) with the connectors facing up.

I can guess what LANDSCAPE mode means, but I'm not 100% which way "PORTRAIT" would mean. that is, which end of the SC would be up?

I was assuming that the SC would use the FRC convention of X axis forward on the robot, and the Y axis off the the left of the robot.
This would imply that rotatin around the Y axis would be PITCH and rotation around the Y axis would be roll.

Anyway, in FLAT mode I could see the angles changing and based on what I saw, The end of the SC that has the FIRST logo appeared to point in the +X direction. WHich puts the +Y axis pointing towards the side with all the USB and digital ports.

Another way to look at is, if you locate the corner with the two I2C connectors and lift it UP, you get a positive PITCH and ROLL.

So to try verify this observation I thought I'd create a program an display the IMU data how a program might see it.
I built a small Command Based program with a single IMUsubsystem

When I then moved the SC around it's three axes, I got very different orientations, as shown below

Movement                   SC Web display      Dashboard display
Rotate the SC CCW          +ve Yaw values      +ve Roll values
Lift the Smart IO side UP  +ve Roll values     +ve Yaw values
Lift Ethernet end UP       +ve Pitch Values    +ve Pitch values

You can see that the Dashbord values are completly switched (including the yaw).

As I explored further, I found an additional call.... getYawRadians() which does appear to rotate around the correct axis.

So, I'm trying to figure out what's up with the other getAngle calls.

[gearsincorg]

Any comments on this IMU issue.

ie: Should I expect the three getAngle() calls to track the IMU data displayed on the SystemCore diagnostics page, or is there some other logic in play here.

If this is unexpected I can do some more analysis to determine if the other IMU orientations are working or not.

[gearsincorg]

A301 robot design. 5/28/2026

Is there a CAD model for the updated A301? (including the 4mm threaded holes).

Our hardware team would like to use it when creating 3D printed mounting hardwares.

[jfabellera]

#261 (comment)

[gearsincorg]

Kiwi Bot. 5/28/2026

Yesterday we started designing a 3 wheel Omni Bot (Kiwi Drive) for the A301 motors.
Consistent with the Vendor Starter Bots, we plan to include a Pollen intake and an unlikley manipulator to try out the A301 motors in servo mode.

While we were waiting for the H/W guys to design 3D printed motor mounts and spline clamps for the new bot, the software crew stripped down our 2024 Power Play robot (also a kiwi drive) and installed a legacy hardware (Systemcore + expansion Hub) setup to get more familiar with wpilib programming.

Even with open-loop motor control, the three wheel configuration was very stable, and easilly controlable. Driver response was very tight.

kiwi.drive.mov

FWIW: We have a fond history of designing round Kiwi-Drive robots.
They provide the ultimate effeciency in holonomic drives.
We designed our first one for Velocity Vortex.

[ThadHouse]

That’s awesome to see. That was kind of one of our goals for the expansion hub setup. We wanted to make it good and have fast loop times, which is why there are the limitations it has. Cool to see it’s not getting in the way though.

[zachwaffle4]

Is the code you're using for testing on GitHub?

[gearsincorg]

The repo WAS private, because it was a random collection of mini projects.
But I just made it public.

https://github.com/gearsincorg/Alpha

The readme gives a 1-line description of each of the projects. Each folder is it's own VSCode project.

Bear in mind this code is part of the testing/experimental process so the quality and completeness of the code is low...
Sometimes it was just created to see how something works, with no intent to keep/maintain it.

So... Use with caution :)

[gearsincorg]

More IMU testing... 5/31/2026

I've spent several hours running test in the IMU trying to establish it's behavior in the three orientations FLAT, LANDSCAPE and PORTRAIT.

I have some observations.

1. The public class OnboardIMU code comments need to be more specific about the actual orientations.
   eg: for Portrait mode, the SC is on it's end, BUT which end of the SystemCore is UP, and which axes corrospond to Pitch and Roll for that orentation. The current comments get you about 30% of the way there. It's really important for this to be nailed down for advanced navigation and non-flat playing fields.

2. The current getYawRadians() needs some work. This method takes the raw IMU yaw value and subtracts an offset, (this enables it to be reset to zero by updating the offset). Currently the yaw value wraps at a "random" angle based on the last saved offset. The code should normalize the yaw to +/- PI before it returns it, so that the range of values are consistent.

3. There is something unsusual in the way the X,Y and Z axes relate to Yaw, Pit and Roll in the three configuration.
   Generally Yaw maps to the X axis, and Pitch & Roll map to Y & Z. Although I can't tell if Pitch always maps to Y because I don't know the exact orientaions (see 1 above).
   I use the term "generally" because in the "Lanscape" orientation, Yaw does not seem to map to ANY axis. ALL axes remains unchanged when pure Yaw is occuring.

[ThadHouse]

Can you make an issue for these in the WPILib repo? These are targeted enough where they're a good issue to put there.

[gearsincorg]

Weird. I just added the issue, and saw that it was on the list. (called" IMU Issues) And now it's gone. I'm reluctant to add it again just in case it really is there ...

[ThadHouse]

I moved it to the correct repo. wpilibsuite/allwpilib#8942

[gearsincorg]

Looking at the Log on the Systemcore, the date stamps on these all start in October on my unit.
I'm guessing that there is no battery-backed-up clock on the SC.

On the ControlHub, the clock is updated when the Driver station connects. Will this be a thing for the systemcore as well?
It would be really nice to get a valid timestamp on log files and data.

[ThadHouse]

Yes. It will be in the next set of updates.

[ThadHouse]

Yes. It will be in the next set of updates.

[gearsincorg]

A301 Kiwi Drive 6/1/2028

We took the Legacy Kiwi Omni Bot platform that we posted earlier, and updated it to use the A301 motors.

It was tricky to get the motors/wheel combination mounted. As a goBILDA hardware team, only having the two M4 holes was pretty limiting. We coudn't use the typical Quad mount blocks (because the only allignment option would have required either double threading the hardware, or drilling out the thread of the Quad Block). We eventually went with a single-hole low profile C channel.

Once we got that settled, it was a matter of getting all the pieces onto the short spline shaft and then stopping it from falling out of the motor.

We went with a large washer bolted to one end to keep the shaft up against the motor through-bore. At the other end we used a spacer and the supplied clamp to hold the wheel on. I felt that the black universal hub was definately needed, but we felt that the spline tollerance was a bit sloppy. The wheel was very loose on the shaft. We fixed this by insering a bearing into the far side of the omni wheel to keep it alligned. We barely had enough shaft length to keep the clamp engaged.

Given how tight we had to make this clamp, we're concerned that clamping onto the spline with a round clamp opening may eventually damage the spline. We're eager to see what new hardware the other vendors provide.

The electronics was next.
With so few cables, mounting was easy, except perhaps for the battery. The current dock is hard to work with. Since the battery needs to be slid out, it needs to be pointing towards the outside of the robot, but this puts the power switch off to the side.

Question: Is this close to the final battery dock configuration, or is there a more streamlined final design in the works.
Also, is it intended that the switch on the dock will be the Required main switch, of is it assumed they may be a secondary (more acessable) option.

[franklima260]

Any reason the '1201 Series Quad Block Pattern Mount (43-5)' would not have worked in this application?
https://www.gobilda.com/1201-series-quad-block-pattern-mount-43-5/

[gearsincorg]

That one would work. But we only had one of them :(

[gearsincorg]

Added OctoQuad I2C driver 6/5/2026

My team uses the OctoQuad Mk2 (from Digital Chicken Labs) to do high speed Odometry as well as providing 6 additional encoder ports.
So I asked the DCL developer if he could put together a I2C driver that I could test with the Systemcore.

I got the code back the same day, and so I set to work testing it out.
It integrated really well, and I paired it with a set of older goBILDA Odometry pods on our KiwiDrive test chassis.
The odometry is running nicely and the I2C appears to be keeping great accuracy.

I still have to do some more speed and reliability tests on the I2C, but I'm optimistic.

Sidenote: I've also been learning about using ClaudeCode integrated into VSCode, and so this test project is 95% pure AI.
That includes building the Kiwi Drive subsystem from scratch and adding the odometry.
I even had Claude build it's own OctoQuad driver for comparison (not included in this branch).
I'm really impressed with the process so far, which is saying something because I'm a born skeptic..

I've added this project to my alpha testing repo. It's in the "Alpha OctoQuad" folder.

https://github.com/gearsincorg/Alpha/tree/main/Alpha%20Octoquad

[gearsincorg]

AprilTags 6/7/2026

Today I played around with adding vision processing to the SystemCore.

Since running Photon Vision directly on the SystemCore doesn't appear to be possible just yet, I focussed on simply adding Apriltag Detection using OpenCV and the wpilib Apriltag Vision processing.

I was using a logitech C310 web cam, mainly because I had one, and I knew the Calibration values already existed in the FTC_SDK.
The resulting project launches the vision pipeline on a new thread so it does not block the 20ms Periodic tasks.

The code looks for camera0 (which I could plug into any of the 4 serial ports). When it detects a camera it looks it's VID and PID up in a calibration file (the one from the FTC_SDK) and loads the appropriate camera calibrations. It then looks for Aptiltags.
It then process any detections to determine their Pose, and then translates that into the Robot frame based on the camera location established in the constants file.

The main work is done in the AprilTagVision.java subsysem.
In my project, the periodic() method simply calls the method to send the key AprilTag data to the dashboard.

I've included a video here showing what I could create on the dashboard to go with this code. Because I didn't have "telemetry" I just had the code concatinate the list of tag data and display it on a single elastic widget (not optimal, but functional). Note that the CPU % doesn't seem to vary much from an idling systemcore. They always seem to be at 50% when robot is enabled.

The project code is in a new folder under our Alpha repo, called "AprilTag".
https://github.com/gearsincorg/Alpha/tree/main/AprilTag

So you can have simmilar fun, the project folder also includes an elastic-layout.json file which can be used to display the various video/apriltag data.

2026-06-07.20-59-44.mp4

Once thing I realized doing this is how easy the current FTC_SDK makes it to use AprilTags. What with managing the camera resolution, sources, calibration and processing, and the fact that we can build libraries of tags with different sizes and locations, with all of the backend work being coordinated through the VisionPortal with default or bespoke setups. Add the fact that the vision color search and color sensor functions are also built in. We really have been a bit spoiled.

I also just noticed the jump in PingTime during that video. I don't know if that was related to the apriltag processing or just the fact that my PC was busy.

One other thing, of you look at the XYZ data for the tags, you may notices that the Z range varies a lot, which is odd since they are all on the same page. But this is because wpilib wants to use one size for all the tags, so I had to pick a one size... I chose 4 inches. This matches the largest tag on that sheet. (ID 584)

[ThadHouse]

Vision support in the FTC SDK is definitely one place the FTC support was much better than the built in FRC support, mainly because the roboRIO supporting vision (Especially AprilTag vision) has pretty much never been viable. So our focus has been mostly on USB camera and streaming support, and not the actual tracking itself.

This is something we really hope gets improved in the future.

For the ping time, thats a bit high, but that happens, and not something I'm too concerned about, especially since it dropped back down. likely just hit a non ideal wifi spot, and had a ping spike.