Driverstation crashing on connect

[MrRSquared]

Hello, I love the beautiful interface for the new driverstation. Unfortunately both with the main branch as well as the branches that have an updated drvierstation, As soon as the driverstation connects with the robot, The driverstation crashes without error (even when launching in verbose mode).

Before launching, I get the following terminal messages on the robot.

INFO:nt:NetworkTables initialized in server mode
DEBUG:nt.th:Started thread nt-dispatch-thread-0
DEBUG:nt.th:Started thread nt-server-thread-0
DEBUG:nt.th:Started thread connection-notifier-0
DEBUG:nt:Listening on  1735

Then, when I connect, I get the following readout on the robot (no new info on the driver station.

INFO:nt:CONNECTED xxx.xxx.x.xxx port 49897 ()
INFO:root:ConnectionInfo(remote_id='', remote_ip='xxx.xxx.x.xxx', remote_port=49897, last_update=0, protocol_version=768); Connected=True
DEBUG:nt.th:Started thread entry-notifier-0
WARNING:nt:read error: [Errno 104] Connection reset by peer
INFO:nt:DISCONNECTED 192.168.1.29 port 49897 ()
INFO:root:ConnectionInfo(remote_id='', remote_ip='192.168.1.29', remote_port=49897, last_update=2686.530429185, protocol_version=768); Connected=False
DEBUG:nt.th:Thread nt-net-read-0 exited
DEBUG:nt.th:Thread nt-net-write-0 exited

I am wondering if I do not have something installed that I should, or if there is a bug. When I use an older version of the driver station, it seems to work.

[EmilyRobotics]

Should be fixed now

[MrRSquared]

I think it may still be present. When I try with the main branch, I get the exact same behavior. When I try using the eli-reworkrun branch, I get the following...

DEBUG:nt:Listening on  1735
Traceback (most recent call last):
  File "run.py", line 205, in <module>
    m.broadcastNoCode()
  File "run.py", line 108, in broadcastNoCode
    self.status_nt.putBoolean("Code", False)
AttributeError: 'main' object has no attribute 'status_nt'

I was not able to push code from the driver station, and I am using the original way to start the robot and connect.

Oddly enough, with both, Shuffleboard connects persistently.

[EmilyRobotics]

That looks to be a slightly different issue, but i'm working on a fix for that right now

[MrRSquared]

Thank you. That was quick :) I do realize that, yet, since it is preventing that branch from connecting and the main branch seems to have the same error, the bug may still be present (if indeed it is a bug and not a missing dependency or mix-up on my end with the connection process).

[EmilyRobotics]

Yeah it's yet to be merged into the main branch, probably will be in the next few days. Are there still any issues/bugs on this branch (eli-reworkrun)?

[MrRSquared]

That makes sense. Yes. I still cannot get that branch to work for me (I do admit it could be operator error. in fact, let's just assume any of my issues could be :). When launching run.py on the pi, it says something to the effect of "no comms" then exits (I am not on the device right now tog et the exact printout). This happens regardless of whether I have drvierstation.py open on launch or not. In fact, even when Shuffleboard is open before running run.py, it says there is no comms and then exits. I was wondering if I needed to send robot code from the driver station first, but I cannot figure out how to do that (when running deploy.py from the driverstation, the connection is always refused).

[EmilyRobotics]

Ah the issue is that the program that is launched on startup on the pi is now robot_setup.py, not run.py. Sorry for not making that change clear

[MrRSquared]

Ah. That would do it. Thank you. I will look into that when I get a chance.