Issues connecting to simulator

[CrispyBacon1999]

I have a user of my wrapping package reporting issues with connecting to a simulated robot. I can't seem to reproduce it on my end, but it definitely seems like an issue that's stemming from this package as well. It seems to only appear when modifying networktables values from the client side, rather than robot side.

The error they're reporting is NT: DISCONNECTED NT4 client '1700087460502@1' (from 127.0.0.1:61606): binary decode error: mpack_error_type. More details can be found at this issue: CrispyBacon1999/ntcore-react#149

[cjlawson02]

Thanks for the report Josh,

@fisherjacobc, can you provide a minimal robot code repository similar to your environment so I can reproduce this?

---

Also, @CrispyBacon1999, let me know if you are interested in owning this package... or if you have the bandwidth to help me with the NT 4.1 migration and adding global listeners. My priorities have shifted, and my primary focus is my job and college right now

[CrispyBacon1999]

I haven't looked that deep into NT 4.1 yet, but it's possible that's what's causing the issues. My local testing was done using my team's 2023 robot, which wouldn't have the new 4.1 things, so I could see small conflicts causing issues. Looking at the way they have the negotiations handled, it theoretically shouldn't cause issues, but you never know.

I'd definitely be down to help out with adding 4.1 support as well!

[cjlawson02]

Glad to hear!

TL;DR I don't think this is 4.1 related

From the spec: https://github.com/wpilibsuite/allwpilib/blob/main/ntcore/doc/networktables4.adoc#motivation4.1

Version 4.1 uses a different WebSockets subprotocol string than version 4.0, so it is easy for both clients and servers to simultaneously support both versions 4.0 and 4.1. Due to WebSockets implementation bugs in version 4.0, version 4.1 implementations must not send WebSockets PING messages on version 4.0 connections.

[cjlawson02]

I don't think this is my client. My client connects to the robot in the form of ntcore-ts-<uid>

https://github.com/cjlawson02/ntcore-ts-client/blob/main/packages/ntcore-ts-client/src/lib/util/util.ts#L201

This message says NT: DISCONNECTED NT4 client '1700087460502@1' (from 127.0.0.1:61606): binary decode error: mpack_error_type. 1700087460502 is not in the client ID form I use

[CrispyBacon1999]

Interesting, so it's likely another app connecting and having issues, but the errors are being sent through and displayed?

[cjlawson02]

That's what it seems like at first glance. This is one of those things that's hard to debug without the same environment. Looking at your linked issue, it sounds like it just disconnects and reconnects? Maybe in NT4.0, there's a bug that reloads all clients when it gets an error like that

[CrispyBacon1999]

In case you didn't see (in the other issue), example code for the issue is at https://github.com/FIRST-TEAM-339/kilroy-dashboard.

[cjlawson02]

Could be robot code issue

[fisherjacobc]

Since I was just testing out NT Tables, I didn't really have anything sophisticated code wise, but I had stuff in a subsystem (using commaned-based). Below is the minimal code relating to the values I want to change through the subsystem.

package frc.robot.subsystems;

import edu.wpi.first.networktables.NetworkTable;
import edu.wpi.first.networktables.NetworkTableEntry;
import edu.wpi.first.networktables.NetworkTableInstance;
import edu.wpi.first.wpilibj.RobotController;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;
import edu.wpi.first.wpilibj2.command.SubsystemBase;
import frc.robot.Constants.*;
import frc.robot.enums.DriveGears;

public class DashboardSubsystem extends SubsystemBase
    {
    private NetworkTableInstance inst = NetworkTableInstance.getDefault();
    private NetworkTable table = inst.getTable("kilroy");

    private NetworkTableEntry autonomousMode = table
            .getEntry("autonomous/mode");
    private NetworkTableEntry leftRightNone = table
            .getEntry("autonomous/left-right-none");

    public DashboardSubsystem()
        {
            // this.autonomousMode.setPersistent();
            this.autonomousMode.setInteger(2);
            // this.leftRightNone.setPersistent();
            this.leftRightNone.setInteger(1);
        }
    }

I should have also mentioned this before, but in my console I get a warning of "Topic /kilroy/autonomous/mode is not announced, so it cannot be updated" which I traced back to coming from ntcore-ts-client if that helps at all.

[cjlawson02]

@CrispyBacon1999 @fisherjacobc I think I may have found something

https://github.com/CrispyBacon1999/ntcore-react/blob/main/src/lib/useNTState.ts#L62-L63

We publish then immediately set the value. publish is technically an asynchronous action, because the server response (an "announce" message), needs to come back before we can set values

From the spec: https://github.com/wpilibsuite/allwpilib/blob/main/ntcore/doc/networktables4.adoc#topic-announcement-message-announce

Topic Announcement Message (announce)
The server shall send this message for each of the following conditions:

• To all clients subscribed to a matching prefix when a topic is created
• To a client in response to an Publish Request Message (publish) from that client

---

2 options:

1. refactor to make this a promise and track it's resolution (lot of work)
2. Queue values, then send when the topic is announced (easier, but kinda masks the problem)

The way I worked around this (and never noticed this issue) was by using a useEffect to setup my topics as publishers. I don't think I published values immediately either.

You could also make it a "publisher" on the robot side, which would mean the topic is already announced when the robot is connected

[fisherjacobc]

I'm just curious since I haven't done too much with network tables. Is setting a value not count as publishing on the robot side?

[cjlawson02]

You're right, the topic is published/announced already

I forgot that NT won't send the announce message unless the client is subscribing or publishing, so this is a client side issue.

[fisherjacobc]

So I guess either you would have to make a PR to ntcore-react or the developer would have to update it

[cjlawson02]

I think refactoring the async calls to promises is the best option. Resolve when server ack, reject on timeout? I can try to get to that when I have time (which is not very often), so feel free to look into it or PR. Then we will have to update ntcore-react.

It's more of an issue with my package

[cjlawson02]

https://github.com/cjlawson02/ntcore-ts-client/blob/main/packages/ntcore-ts-client/src/lib/socket/messenger.ts#L249-L253

This print statement says I will queue the value if it isn't announced

https://github.com/cjlawson02/ntcore-ts-client/blob/main/packages/ntcore-ts-client/src/lib/socket/socket.ts#L385-L389

But really I'm only queueing if we aren't connected to the robot.

---

TODO: either refactor queue, or make publish a promise.

I need to think about this more. Open to opinions

[CrispyBacon1999]

I think using promises for it is definitely the ideal way of doing it. Will probably be awkward for handling backward compatibility/deprecation, but it's probably not the end of the world.

[fisherjacobc]

Hey there! I saw there have been some commits on here that seem related to this issue if I am not mistaken? I am wondering if that is a fix for the issues I have been encountered, and if the react library should update to the latest version of ntcore-ts-client

[cjlawson02]

Hey @fisherjacobc you can try https://www.npmjs.com/package/ntcore-ts-client/v/1.0.0-beta.4 but I think I had problems with it. I'm in the middle of finals right now and I'll try to work on this in the next few weeks

[cjlawson02]

Closing this as issues should be fixed with https://www.npmjs.com/package/ntcore-ts-client/v/2.0.0-beta.3

Please comment if this should be reopened

[fisherjacobc]

Hey there! I got home and updated to be on 2.0.0-beta.3 and forked ntcore-react and updated to 2.0.0-beta.3 on there as well.

I still am getting the same error with the robot simulation, NT: DISCONNECTED NT4 client 'ntcore-ts-1704678409391@2' (from 127.0.0.1:49256): binary decode error: mpack_error_type

Also, nothing shows up in the devtools console besides the robot disconnecting/reconnecting, but I think those are statements from ntcore-react

[cjlawson02]

Can you confirm you are using the latest WPILib distribution?

[fisherjacobc]

Yep, I recently updated the robot sim to be 2024.1.1

[fisherjacobc]

I also made sure to have the items published/set when the robot is initialized

/**
   * This function is run when the robot is first started up and should be used
   * for any
   * initialization code.
   */
  @Override
  public void robotInit() {
    NetworkTableInstance inst = NetworkTableInstance.getDefault();
    NetworkTable table = inst.getTable("kilroy");
    IntegerPublisher entry = table.getIntegerTopic("autonomous/mode").publish();
    entry.set(2);
    IntegerPublisher entry2 = table.getIntegerTopic("autonomous/left-right-none").publish();
    entry2.set(1);
  }

[cjlawson02]

Hi @fisherjacobc please try 2.0.0-beta.5

[fisherjacobc]

Hi there! I waited until tonight when I could try seeing if it works with a real robot, since that's what really matters. Unfortunately, it didn't. Just kept looping and connecting/disconnecting...

Recording.2024-01-10.181449.mp4

I will try skipping the whole react thing and just see if I can update the states directly through ntcore-ts-client in just a test folder and see how that goes.

[CrispyBacon1999]

Logically, there should be no way that the issue stems from it being in the react library, but it's definitely worth testing whether it happens with base as well.

[CrispyBacon1999]

@fisherjacobc One thing I did notice after looking at your code is that you're explicity declaring the uri you connect to as roborio-XXXX-frc.local. You realistically shouldn't need to do that and can just get away with using team={"XXXX"} instead. Not really sure if that would affect anything, but it's definitely worth a shot.

[fisherjacobc]

Ok so, while just trying to test setting the value, it has some errors of it's own

Error: Server sent no subprotocol

import { NetworkTables, NetworkTablesTypeInfos } from "ntcore-ts-client";

const main = async () => {
  const kilroy = NetworkTables.getInstanceByTeam(339);

  const autonomousMode = kilroy.createTopic<number>(
    "/autonomous/mode",
    NetworkTablesTypeInfos.kInteger
  );
  await autonomousMode.publish();
  autonomousMode.setValue(1);

  setTimeout(() => {
    autonomousMode.setValue(2);
  }, 3000);
};
main();

[cjlawson02]

I will try to take a look this weekend

[SpiffyJif]

Not sure if this helps but i'm getting a very similar error trying to connect to a local NetworkTables connection within Vite. I'm using 2.0.0-beta.5.

in App.tsx function (Vite):

const ntcore = NetworkTables.getInstanceByURI('localhost', 1735);

this is code for the local server I'm running with pynetworktables:

from networktables import NetworkTable

server = NetworkTables.initialize()

while True:
    print('ran')
    time.sleep(1)

When I start a client using pynetworktables with the same URI and port, it works fine and I'm able to communicate.

Here are the constant errors I get on the frontend:

This is the constant error I get from pynetworktables in the backend:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/_pynetworktables/_impl/network_connection.py", line 268, in _readThreadMain
    handshake_success = self.m_handshake(self, _getMessage, self._sendMessages)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/_pynetworktables/_impl/dispatcher.py", line 635, in _serverHandshake
    msg = get_msg()
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/_pynetworktables/_impl/network_connection.py", line 256, in _getMessage
    return Message.read(self.m_stream, decoder, self.m_get_entry_type)
  File "/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/_pynetworktables/_impl/message.py", line 153, in read
    raise ValueError("Unrecognized message type %s" % msgtype)
ValueError: Unrecognized message type b'G'

[cjlawson02]

@SpiffyJif
pynetworktables was a NT 3.0 implementation and isn't used with this library. This is a standalone implementation

The error you are getting says that it can't connect to a NetworkTables server running on your local computer (localhost)

The port for NT4.0/4.1 is 5810, so if you're running the simulator locally, you need to change the port. If you are trying to connect to the robot, you need to change "localhost"

[cjlawson02]

@fisherjacobc I tried to reproduce but I couldn't in the simulator. I'm using the template arcade drive robot file and your typescript code

Screen.Recording.2024-01-15.at.10.47.32.AM.mov

As you can see, the autonomous value changes from 1 to 2 after 3 seconds

[cjlawson02]

@fisherjacobc Do you still have any issues? I think everything should be solved at this point

[fisherjacobc]

Apologies, I forgot to get back to you. I am still getting the same error, the robot is currently using 2023.4.2 for the rio/wpilib stuff, would that be an issue?

[cjlawson02]

Maybe, I'm not sure. I think this might be a robot code issue though. Could you provide me a minimal reproducible example on the robot?

[fisherjacobc]

you can look at https://github.com/FIRST-TEAM-339/2024Base

[fisherjacobc]

Hey there, still encountering the issue. Currently still running on 2023.4.2, also even with the minimal arcade java example completely unmodified (created a new project) I still get the error of Error: Server sent no subprotocol

[fisherjacobc]

hey there, for whatever weird reason, it works perfectly fine if i remove the subprotocols when first trying to connect with the websocket...

will just use that as a patch and see how it goes from there

[cjlawson02]

Thanks for the update. I'll take a look when I get some time

[cjlawson02]

Hi @fisherjacobc is this still an issue with 2024 wpilib?