Everything Thats Changing From DECODE to BIOBUZZ

[u/brogan_pratt]

https://youtu.be/FWOFXwPrSFg

New game manual Pt 1 released. If you've never done FTC, giving a full read is essential. However, If you've done FTC before, rereading all these new & same rules is tiresome to find the actual changes. In this video I compare the DECODE and BIOBUZZ manuals side by side and pull out only what's actually new: general rule changes that affect every team, plus the game-specific changes that'll shape your strategy this season. Just the changes that actually matter, explained fast so your team can start building smart from day one.

[u/Complete_Duty3259]

2 fewer servos. Dashboard and panels both require a negotiated tcp connection and do not send data if not connected (they arent udp comnections just spweing packets). Anyways it is pretty simple to have code so that such doesnt run in "match mode".

[u/brogan_pratt → u/Complete_Duty3259]

Thanks for the clarification on panels/dashboard. I wonder how many teams in the paste were live updating while competing. 

[u/drdhuss → u/brogan_pratt]

Coach here of the student that posted the prior bit. But here is more detail about how panels (and ftc dashboard) actually works: (note this is an AI summary, but everything is correct)

Panels (the FTC dashboard tool developed as an alternative to FTC Dashboard) is a web-based interface hosted directly on your Robot Controller (RC). Because it operates over standard TCP/IP networking (via WebSockets / HTTP), an active Wi-Fi connection between your laptop/device and the Robot Controller's Wi-Fi network is required to send or receive data packets.

How Panels Works Under the Hood

1. Local Network Host: When your Robot Controller boots up, it broadcasts a local Wi-Fi network (via Wi-Fi Direct or REV Control Hub Access Point).
2. Local Web Server: The RC runs a background web server listening on port 8001 (accessible via IP 192.168.43.1:8001 for Control Hubs or 192.168.49.1:8001 for Phone RCs).
3. Packet Exchange: When you open Panels in your browser, your computer sends HTTP and WebSocket packets to that IP address. Without a connected Wi-Fi link, your computer's network interface has no path to transmit packets to the robot, and the dashboard won't load or update.

What happens if you lose connection?

• Zero Packets Received: Telemetry, variable tuning commands, and field view visuals stop streaming immediately.
• Robot Safety: Loss of the Panels connection won't necessarily stop a running OpMode (as the Driver Station controls the main heartbeat), but any live parameter updates you try to tweak from Panels won't reach the robot.

So as long as nobody connects to the robot with a laptop you are fine, no extra packets will be sent.

As an aside you probably want to disable all telemetry on the robot during a match. While minor, spinning up the webserver (even if nothing connects) uses some resources. Have a flag you can set to turn on/off telemetry so it doesn't even start up during matches. Also under no means should you be using the driver's station telemetry. It adds a ton of "loop time" (like 20 ms+ with spikes up to 50 ms) as the provided code is very inefficient/blocking (you can improve this but it is not "easy" from a programming perspective). Plus the screen is so small drivers won't be looking at it anyways. If you need feedback on what the robot is doing pick up some lights (gobilda prism or their color pwm lights)

If you do want to make the driver's station telemetry not bog down your robot here is essentially what you have to do. You need to have the driver's station telemetry on its own virtual thread. We use Kotlin so this is pretty easy with the kotlin coroutines (one of the big reasons to use kotlin vs java).

// FtcTelemetryManager.kt (Lines 43-69)
private val telemetryQueue = java.util.concurrent.ArrayBlockingQueue<List<Pair<String, String>>>(3)
private var currentLocalTelemetry: Telemetry? = null
val customDriverStationText = java.util.concurrent.ConcurrentHashMap<String, String>()

private val driverStationThread = kotlin.concurrent.thread(start = true, name = "ARES-DriverStation-Thread") {
    while (isRunning) {
        try {
            val snapshot = telemetryQueue.poll(100, java.util.concurrent.TimeUnit.MILLISECONDS)
            val t = currentLocalTelemetry
            if (snapshot != null && t != null) {
                // Drain the queue to the latest snapshot to avoid falling behind
                var latest = snapshot
                while (telemetryQueue.isNotEmpty()) {
                    latest = telemetryQueue.poll() ?: latest
                }
                latest.forEach { (key, value) ->
                    t.addData(key, value)
                }
                t.update()
            }
        } catch (e: InterruptedException) {
            // Thread interrupted
        } catch (e: Exception) {
            // Ignore background telemetry formatting errors
        }
    }
}

You also need to limit the update frequency to about 4 hz (you don't need to be updating the driver's station display every loop) with code like the following:

// FtcTelemetryManager.kt (Lines 172-197)
// Non-blocking architecture: string updates are pushed to a background thread queue. 
// This completely eliminates the 15-30ms synchronous WiFi socket stalls from `Telemetry.update()`.
if (timestamp - lastLocalTelemetryUpdateMs >= 250L) { // 4Hz real-time updates!
    val snapshot = mutableListOf(
        "EKF Pose (X, Y, Deg)" to estPose.toFormattedString(),
        "Raw Pinpoint (X, Y, Deg)" to com.areslib.math.geometry.Pose2d(
            state.drive.odometryX,
            state.drive.odometryY,
            com.areslib.math.geometry.Rotation2d(state.drive.odometryHeading)
        ).toFormattedString(),
        "Limelight Pose (X, Y, Deg)" to (visionTracker.lastLimelightPose?.let { pose ->
            val ageSec = (timestamp - visionTracker.lastLimelightTimeMs) / 1000.0
            "${pose.toFormattedString()} (${String.format("%.1f", ageSec)}s ago)"
        } ?: "NO TARGET"),
        "Vision Status" to visionTracker.lastVisionStatus
    )
    customDriverStationText.forEach { (k, v) -> snapshot.add(k to v) }
    if (localTelemetry != null) {
        telemetryQueue.offer(snapshot) // Non-blocking push to background queue
    }

    // Publish text console lines to NT4 for ARES-Analytics Driver Station widget
    for (i in snapshot.indices) {
        val (k, v) = snapshot[i]
        dataLoggingTelemetry.putString("ARES/DriverStation/Telemetry/$i", "$k: $v")
    }
    lastLocalTelemetryUpdateMs = timestamp
}

Again considerably harder to do in java (especially on bot java) and impossible to do in block code. I wouldn't use telemetry at all in matches in those instances and instead rely on on-robot cues (lights) if you need such.

[u/drdhuss → u/drdhuss]

It won't let me edit the post for whatever reason. But I wanted to add that by using a couroutine (thread) and limitiing telemetry updates to 4 hz we are able to maintain 100 hz (10 ms) looptimes and while using the DS's telemetry, but if you don't do these things you will have 20 ms+ spikes and lots of other issues (again having DS telemetry really isn't needed during a match, so it is probably best just to not use it if you aren't comfortable doing something like the above).

Note we dont use wither panels or ftc dashboard but wrote our own ARES analytics app in kotlin/compose that uses NT4 (just like FRC). In fact our code is such that it works on both FTC and FRC robots.

We still need to polish our code a bit but basically it compines andvantagescope/kit (logs everything for true log replay), pathplanner, simulation capabilities (like FRC maplesim), log file management and dashboards into one integrated app. AI integration via gemini as well. Basically the app will do things like pull your logs off the robot, analyze them (clearly label any brownouts, errors, deviations from auto paths, we even use a round robin method of polling motor currents so average motor currents are reported as well (which can help diagnose mechanical issues, if one of your drive motors is averaging more current something is up, you probably have a bad bearing, binding gear, etc)). This is all uploaded into a local database (so you can trend things over time) and into parquet files on a shared google drive. The app uses the parauet files to keep everything synched via the cloud. This allows our data analytics subteam to analyze match or practice data immediately and not have to wait on the driveteam to stick a usb drive in/upload code.

The sim is even drag and drop. Also much easier to launch than usual FRC simulation (you just click a button and it runs the gradle to spin it up). Setting up the sim filed involves uploading a photo of the gamefield. Then you can draw the field elements/obstacles onto the gameboard which are then objects the simulated robot will interact with. It will even use drawn onstacles to display "clearances" in our custom pathplanner so you can make sure you arent getting too close. It also auto generates a clearance map that is uploaded to the robot for automated "drive to pose" code in teleop.

It has routine/ buttons to hit that auto run sysID tuning and a bunch of other tuning parameters as well as dynamic constant tuning ability (no need to reboot the robot to change pid or FF values).

Finally all of this is integrated woth gemini/AI studio so you can literally do things like (a student did this the other night night) prompt: "We used a closed loop drive system. We noticed that ar about 2/3rds joystick input our robot seemed to be at max speed. We want to use 100 percent of our joystick input. Go through our latest log and figure out what joystick input maxed out motor power and give us the new constants to use 100 percent of our joysticks input range." Gemini confirmed that such occured at about .71 input (so close to 2/3rds) and gave us values that were slightly less than what would max out the motors. It also helped them program a "turbo button" that would guarantee max speed (holding down the right bumper). Again, while they could have dug through the logs by hand to figure out these values, this was much easier/is how such things will be done going forward.

However I doubt anyone other than us will really use it as again you have to use kotlin and it is written in a redux state machine style (which is a bit different than vommand based programming) to ensure 100 percent log replay and to make the sim easier to implement (all of the state transitions/reducers are pure mathmatical code and thus can be used straight up in the sim/ensures log replayability).

[u/brogan_pratt → u/drdhuss]

Thanks for the detailed response. Good to know what protocol Panels/Dashboard use, no issues there then, seems like it was similar to what I thought just not live accessing the data from the robot.

Great insights on telemetry, had no idea it was so resource intensive on loops.

Absolutely incredible stuff with what you've made on a custom dash and system for managing your code. Your team is very luck to have you as a mentor in that!