An open-source, cross-platform Driver Station...

[SoftwareBug2.0]

Since I mentioned that I was excited to try this out I thought I'd give an update. At our latest meeting one of our students tried the program out on Ubuntu 14.04 and here's what he found:

1) Our robot wouldn't connect.
2) Our switch panel wasn't recognized.
3) Gamepad inputs were mishandled.

We haven't taken the time to really dig into it, so it these might all be things that could be easily overcome but the out of the box experience was a bit underwhelming. I'll now elaborate a bit about the problems:

1) Maybe we had a network misconfiguration somewhere? I don't know; we've been able to download code to it from the computer we used. I guess I'll have an excuse to teach people how to use Wireshark.

2) We've never tried to do anything with our switch panel on Linux before so it might be a driver issue rather than a bug in the program. There are some diagnostics we can run. But since our switch panel is TI Launchpad-based and not doing anything unusual software-wise this seems like something that other users might run into as well.

3) We had some axes turned into only three values: 0%, 50% and 100%. We used a Logitech F310, (the most common one). When we talk directly to the kernel we get the proper values out so the issue is somewhere in userland. I'm confident that this could be either fixed or worked around. However, the fact that this wasn't working right makes me suspect that nobody had tried our OS/library version combo with a robot before.

Has anybody else tried the program out with a robot? If so, how did it go for you? And can you describe your setup?

[spat]

Originally Posted by SoftwareBug2.0

Since I mentioned that I was excited to try this out I thought I'd give an update. At our latest meeting one of our students tried the program out on Ubuntu 14.04 and here's what he found:

1) Our robot wouldn't connect.
2) Our switch panel wasn't recognized.
3) Gamepad inputs were mishandled.

We haven't taken the time to really dig into it, so it these might all be things that could be easily overcome but the out of the box experience was a bit underwhelming. I'll now elaborate a bit about the problems:

1) Maybe we had a network misconfiguration somewhere? I don't know; we've been able to download code to it from the computer we used. I guess I'll have an excuse to teach people how to use Wireshark.

2) We've never tried to do anything with our switch panel on Linux before so it might be a driver issue rather than a bug in the program. There are some diagnostics we can run. But since our switch panel is TI Launchpad-based and not doing anything unusual software-wise this seems like something that other users might run into as well.

3) We had some axes turned into only three values: 0%, 50% and 100%. We used a Logitech F310, (the most common one). When we talk directly to the kernel we get the proper values out so the issue is somewhere in userland. I'm confident that this could be either fixed or worked around. However, the fact that this wasn't working right makes me suspect that nobody had tried our OS/library version combo with a robot before.

Has anybody else tried the program out with a robot? If so, how did it go for you? And can you describe your setup?

Networking...

The 2015 protocol relies on mDNS for finding the IP of the robot, however, it may not work neatly with every OS. I am working with that issue. For the moment, try to ping your robot and put the IP of the robot in the "custom address" field in the preferences dialog.

About the joysticks
Our team does not have your kind of joysticks, we only have Xbox 360 joysticks. The problem is that I have not made a mapping for your joystick, and the application will apply an Xbox 360 mapping to "un-mapped" joysticks.

I will see if I can get your joystick to test it, if so, expect an application update soon. For the moment, try to use an Xbox 360 controller or configure the keyboard/virtual joystick.

Thanks for your feedback!

[SoftwareBug2.0]

I will definately try giving the IP address of the robot to the station. That would be an easy fix.

Regarding the gamepad, for some reason I was thinking that the Logitech F310 was what came in the kit last year, which is why I was surprised that it didn't work. Looking it up I see it was the Xbox controller. Now I get why it might not work right out of the box.

[spat]

Originally Posted by SoftwareBug2.0

I will definately try giving the IP address of the robot to the station. That would be an easy fix.

Regarding the gamepad, for some reason I was thinking that the Logitech F310 was what came in the kit last year, which is why I was surprised that it didn't work. Looking it up I see it was the Xbox controller. Now I get why it might not work right out of the box.

I changed the code that reads the joystick in such a way that it does not apply any kind of mapping, in other words it will use the values reported by the kernel. Especially if you are running Linux or Mac OSX.

Be advised, while your joystick might work, it may report the order of axes/buttons differently than the official Driver Station. Please take that in consideration before enabling the robot.

As a side note, I have tested the application with gNewSense 3.1, since Unity and/or Gnome run very slow on my computer.

You can download the latest snapshot of the code here. You can check the Travis build file to compile the DS.

[Greg McKaskle]

I'm happy to hear your statements on the safety issue. I wasn't making claims directly about your DS implementation, by the way, just more generally making sure that people don't get carried away and forget about the potential for harm.

You mention different keys. With any implementation, things may need to adapt. This is no issue as long as people in charge of the robot know the procedures for the one they are using.

Greg McKaskle

[timytamy]

Originally Posted by Greg McKaskle

I'm happy to hear your statements on the safety issue... (snip)

Slightly off topic, but in terms of having the e-stop key mapped to the shift key, this seems (to me) like a really sensible thing to do given spat's explenation. Is there any reason why future offical driver stations can't re-map e-stop to the shift (or maybe have it on both space and shift for historical consistency)

Also, I'd like to raise a concern in that the keyboard mapped e-stop dosen't seem to work when connected to the FMS. Normally, this is not an issue as the FMS has e-stops. However I was doing some testing recently with some robots and FMS light, and through some combination autonomous became activated when it shouldn't have been. We then had a robot running wild, while I madly mashed the space bar. Thankfully no-one was injured.

[Greg McKaskle]

Remapping keys:
This sounds like a good thing at first, but imagine if the brake and accelerator pedals, the blinkers, horn, and other key features could be remapped in a consumer car. The user/consumer would then be in charge and would have a more custom and arguably better experience -- until a valet or stranger needed to drive their car. My car lets me remap a few roller buttons, but they are never to critical features or safety features. Even those changes cause confusion sometimes since I'm not certain what they do at that moment.

Similarly, I'd prefer that DSes try to match the ad hoc standards of the official DS. I haven't heard back from Spat yet, but it sounds like an implementation issue and not a "better" standard. If it is, we will certainly consider something like you mention.

Of course if a device doesn't have a keyboard, it still needs safety actions, and those will have nothing to do with a spacebar. So I hope that a few folks will develop good standards and others will generally follow them.

Offseason Estop:
If I correctly understood your request, I think you'll see it implemented this season, much as you requested.

Greg McKaskle

[spat]

As the readme in the project says, the aim of the LibDS library and the QDriverStation itself is too look and behave as close as possible as the official Driver Station.

The problem about the e-stop trigger key is an implementation issue. I would like to follow the 'standards' of the official DS and be able to stop the robot with the spacebar.

However, the behavior of the application when the spacebar was pressed depended on which widget was focused/selected. In other words, you could never be certain if the spacebar would trigger the e-stop, and a driver should be able to stop a misbehaving robot immediately.

Until I find a fix for this issue, I allowed users to trigger the e-stop function when pressing any of the shift keys. Of course, the option will be remapped to the spacebar when I find a safe method of detecting keyboard input (maybe with SDL, which also gets joystick input).

[krieck]

The user interface looks great. I've been wanting a Mac based driver system for a long time, and I'm looking forward to putting this to work.

I'm afraid I also can't connect to my roboRIO. I am able to ping and ssh to my mDNS address. I tried updating the custom address to the actual IP, but that didn't help.

I am currently seeing the following error messages:

qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated

[Ben Wolsieffer]

I tested the DS a few days ago (rev 8c65fc4df43e4f644d8939f0fee5978e82dad794) and it did not work. I could ping the roboRIO, but the DS didn't connect. I did not check the console output. I was using Arch Linux.

I'll test the latest revision sometime in the next few days.

[spat]

I have checked this issue, mDNS does not play very well with Qt...so I am currently making my own implementation for it to work on mobile and desktop devices (without the need of installing Bonjour or Avahi).

If you compile the latest version, you will need to set a custom/static IP for the robot to work, since my implementation is able to send query messages, but I still haven't put the code for interpreting response messages. Of course, this will be solved when I release the next binary installers.

As a side note, the development release will change the color of the communications LED to yellow if the DS is able to ping the robot, but does not receive any responses to the DS packets.

You can get the latest code here.

[spat]

Originally Posted by krieck

The user interface looks great. I've been wanting a Mac based driver system for a long time, and I'm looking forward to putting this to work.

I'm afraid I also can't connect to my roboRIO. I am able to ping and ssh to my mDNS address. I tried updating the custom address to the actual IP, but that didn't help.

I am currently seeing the following error messages:

qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_client_callback
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get0_next_proto_negotiated

The error messages are the logs of the auto-updater, they do not have anything to do with the DS/robot stuff.

On some systems (e.g. OS X 10.11 and Android) mDNS failed to report the robot IP to the Driver Station. To avoid this issue and to make the DS work on mobile devices, I began implementing an integrated mDNS responder, which will be available on the next major release, hopefully fixing these issues on all operating systems.

If the DS fails to connect to the robot, you can:

- Compile the latest version (code and instructions are here) and try it out. If so, you will need to set the custom IP, since I implemented the code to send mDNS queries, but I still have to work on interpreting mDNS responses...this will be fixed before the next binary release

- If you don't want to go through the compilation procedure, the QDriverStation will notify you when I upload the binary installers (which will be in one week or two from now). Just be sure to launch the DS with a working Internet connection from time to time.

[raystubbs]

Looks like this project is really getting along. That's awesome, maybe I'll get to try it sometime.

[Ben Wolsieffer]

I tested the DS a few days ago (on Arch Linux) and was able to control a robot, but there were a few issues.

There seems to currently be no way to rearrange joysticks, unless I am missing something. I was able to work around this by unplugging the joysticks and reconnecting them in the right order.

When I first enabled the robot, it started driving away without user input, but was able to be stopped using the emergency stop. We spent around 30 minutes practicing with the robot afterward and this never happened again, but it still makes me a little scared.

After the robot was e-stopped, I could not reenable it until I had restarted both the driver station and the robot at the same time. I think this was because the DS immediately e-stopped the robot when it reconnected. I'm not sure if this is the intended behavior or a bug.

Thanks for your work on this project.