Unable to control robot (2022 V4.0) using OpenDS

[drvladb]

Hello, When I try to control the robot from either my linux or windows laptop, I am unable to do any actions (enable/disable, estop, etc.) from the OpenDS while the Official FRC DS is connected and can enable/disable.

(Windows) DS Robot stats:

(Windows) OpenDS not working:

OpenDS does not work regardless of whether the Official DS is open or closed. In some cases, OpenDS is able to read NetworkTable data from Smartdashboard. No statistics or logs are visible. No information about the robot is also visible (ie voltage, other states) and no action can be taken (EStop). Controllers are visible and their states can be viewed:

[Boomaa23]

Hi, it is expected that having an official DS present will prevent OpenDS from working. Only one DS-like software can be connected at any one time (this is a limitation of the FIRST protocols, not OpenDS).

However, the behavior when nothing else is connected is strange. Please try restarting both the robot and OpenDS then only connecting OpenDS. I understand that intended behavior should not require the robot to be restarted, but it will help me to figure out if this is a bug I can fix. Thanks!

Also please launch OpenDS from the command line with java -jar [jar file] and include that output in a follow up comment.

[drvladb]

I understand that intended behavior should not require the robot to be restarted, but it will help me to figure out if this is a bug I can fix. Thanks!

As far as I can tell, this issue persists between restarts of both the robot and the laptop.

Also please launch OpenDS from the command line with java -jar [jar file] and include that output in a follow up comment.

JNativeHook: Global keyboard and mouse hooking for Java.
Copyright (C) 2006-2015 Alexander Barker.  All Rights Received.
https://github.com/kwhat/jnativehook/

JNativeHook is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

JNativeHook is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/.

WARNING: OpenDS update check failed. Ignore this warning if connected to a robot.

There are no unhandled exceptions, as far as I can tell.

[drvladb]

If possible, can you also point me towards where the implementation for the DS <===> Robot is done. I feel as if it would be helpful if there is a "debug" application that directly notes all the actions (communication) it is doing. This would help find where in the chain (be it the connection step or control step) the issue is occuring.

[Boomaa23]

OK I will work on fixing this issue when I have access to a robot next week. For now I know v0.2.3 should work, of course without the efficiency improvements of this version.

All robot <==> DS communication is over normal TCP and UDP sockets, so these actions should be visible with a packet monitor such as Wireshark. Robot-DS debugging at that level probably wouldn't be effective as the state changes all come from the UI, and can really only be debugged as network packages or by looking into the source fully. Ex: logging when a button is pressed would mean a hook into the UI component, which wouldn't function if the component was broken - expected behavior is not clear and no useful info can be determined.

I can direct you to the source section of the website to see how the component parts of the source code interact.

[drvladb]

OK I will work on fixing this issue when I have access to a robot next week. For now I know v0.2.3 should work, of course without the efficiency improvements of this version.

Cool, I'll test v0.2.3 when I have access to a robot

All robot <==> DS communication is over normal TCP and UDP sockets, so these actions should be visible with a packet monitor such as Wireshark.

I was more intending to say that there would be a debug log that says something like: OpenDS Protocol: Sending connection packet to robot

I can direct you to the source section of the website to see how the component parts of the source code interact.

Exactly what I was looking for, will take a look whenever I can.

[Boomaa23]

Great! Glad those docs work. I don't think a "sending connection" log is super useful since that needs to be sent every 20ms (keep-alive) so it'd be quite a bit of spam. I will think about additional stdout debugging though.

[drvladb]

super useful since that needs to be sent every 20ms (keep-alive) so it'd be quite a bit of spam.

Didn't put much thought into the example, so probably not, but especially in the connection steps and when enabling/disabling. Stuff like that could definitely go under a --debug flag and into stdout.

[Boomaa23]

@drvladb I've implemented a --debug flag as you suggested, as of commit e14926d34b15ad7d0954bc6998546bf5cb2bfc8b. Let me know if that's good!

[Boomaa23]

@drvladb I tested it out on a robot today and cannot replicate your issue. The software appears to be working.

[drvladb]

today and cannot replicate your issue

Interesting, I’ll have access to a robot soon, so I’ll check it it’s still a issue with the software (there can certainly be an issue with the environment).