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

[Thad House]

Originally Posted by spat

The way the communications between the DS and the robot work would make this relatively difficult. But, given the appropriate network configuration, you could drive a robot with another robot...

You could run the DS on a Raspberry Pi attached to the robot.


Note I do not condone doing such thing. There is a very good reason they don't allow you to enable robots without having the driver station connected. Rogue randomly moving robots are VERY dangerous. Having the DS on the robot might sound like a good idea, until its randomly driving away towards a crowd of people and you have no way to stop it..

[Greg McKaskle]

I'm glad I'm not the only one concerned by the DS discussions on this thread.

The FRC robots can be very inspiring. Or they can hurt people -- permanently.

Especially when others are around your robot, please be sure that you all know how to operate it safely. That means whatever DS you are using works reliably and all present team reps know how to stop a robot being driven by, oh maybe, your grandma or a show-off teenager who thinks they are playing GTA with your robot.

Also consider making a demo-mode, with scaled down speeds and removing pointy things and spring-loaded whammies.

FIRST has left the protocol open, meaning that you can build your own DS. The robot code will default to safe if the DS crashes or the communications gets scrambled. But it will not be safe if the DS is unresponsive to the operator or goes into a loop sending commands with no way to stop it except for a tackle.

Please be safe. Test whatever DS you are using, and think of it as an important safety feature.

Greg McKaskle

[spat]

Originally Posted by Greg McKaskle

I'm glad I'm not the only one concerned by the DS discussions on this thread.

The FRC robots can be very inspiring. Or they can hurt people -- permanently.

Especially when others are around your robot, please be sure that you all know how to operate it safely. That means whatever DS you are using works reliably and all present team reps know how to stop a robot being driven by, oh maybe, your grandma or a show-off teenager who thinks they are playing GTA with your robot.

Also consider making a demo-mode, with scaled down speeds and removing pointy things and spring-loaded whammies.

FIRST has left the protocol open, meaning that you can build your own DS. The robot code will default to safe if the DS crashes or the communications gets scrambled. But it will not be safe if the DS is unresponsive to the operator or goes into a loop sending commands with no way to stop it except for a tackle.

Please be safe. Test whatever DS you are using, and think of it as an important safety feature.

Greg McKaskle

I agree with you.

As for this application, I have implemented a watchdog timer that will disable the robot and "reset" the communications if no robot response is received. As for the sending part, I do not use any loops, instead, I use some timers that run on a separate thread (to ensure that they are triggered at the correct time frames).

Our team has tested the application thoroughly, and at least with the robots of my team, we did not have any issues. Just as a side note, you can trigger the emergency stop by pressing the SHIFT key, not the SPACE key. The reason behind that is that some widgets or the OS itself may reserve the use of the spacebar key.

As for the discussion of a robot driving another robot, I stated that it is possible (theoretically), however, I would not want to try it and I do not condone such behavior.

Finally, I also agree with you about the "demo-mode". The robots that we use for public presentations have an option in the SmartDashboard to control the maximum speed that the motors/actuators can have, this can be useful for presentations, testing and in the competition itself.

Every team member should also have basic knowledge about how to operate a robot, being safe while driving it and know what to do when the robot misbehaves.

[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

[Alan Anderson]

Originally Posted by x86_4819

Imagine if you could run this on the RoboRIO itself over ssh.....

Or implement it in Javascript and have it delivered to a Chromebook via a web server on the robot.

[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.