![]() |
Driver station coding and other
Okay, I accidentally caused another thread to get hijacked and locked, so I thought I should create a new one specifically for this topic.
After my first season, I'd like to say is that, truthfully, the FIRST tools are poorly thrown together. Although I'm not as experienced here as some people, I'd like to say a few things about them and ask if anyone agrees. The robot itself runs an unprotected FTP server. I really fear someone exploiting this, and I've already demonstrated that this is possible (no, I won't post the code). IMHO, they should either use a password, or, better yet, use encrypted SSH file transfer (SFTP). The compiler doesn't support anything besides Windows, and some of us prefer Linux. The IDE I don't care about (I never use IDEs, just makefiles), but FIRST is limiting users' experiences by limiting who can program and on what operating system. IMHO, they should provide a build of the WPI library and compiler for Linux. Another this is the library. Although it's obvious that tremendous effort was put into it, I can tell that it was rushed to be finished before the build season started. All I can say is that I hope it's better next year. Agree? Disagree? Another other notes? |
Re: Driver station coding and other
Do remember everything starts with bugs no matter what it is technologically. Things have to be fixed over time. I think if they keep this system it will eventually give us some better results. Interesting thoughts though.
|
Re: Driver station coding and other
Quote:
Quote:
Quote:
-Tanner |
Re: Driver station coding and other
Quote:
|
Re: Driver station coding and other
Isn't programming with the Java language already possible on non-Windows platforms?
Also, I should hope we can trust teams to be graciously professional enough to not hack the system. |
Re: Driver station coding and other
Quote:
Having said that I will repeat my claim that the robot is protected by WPA encryption when on the field. WPA encryption has not been fully cracked to my knowledge, although there are vulnerabilities with the handshaking which allow for offline dictionary attacks. I don't recall the exact length or nature of the keys in use but I believe they are randomly generated keys that at the very least contain lower case, upper case and digits. A key generated in this fashion, even of the minimum 8 characters, should take far too long to brute force unless you are extremely lucky. If I am wrong and you have a way to crack a WPA key in a timeframe that would be useful for attacking the FRC network please let me know what it is via PM and I will gladly test it and agree with you after confirming it works. An FTP password would either be obnoxious for teams (randomly generated) or more vulnerable to a dictionary attack than the WPA key (team chosen) |
Re: Driver station coding and other
I believe I read somewhere (don't bother asking for a link) that all of the bots on the field are isolated between the DS and the bot, so no team can access another team's bot. This is most likely why you get assigned a specific station, since only that one is setup to recognize your robot IP
Also, Java can be built from linux. That's the entire point of Java, to be platform-independent. The robot runs a VM, so Java code can be made from any old java compiler. Also, C++ is using a slightly modified version of GCC, so if you set the right command-line stuff I think a regular distribution of GCC might work |
Re: Driver station coding and other
I never tried connecting to the wireless network while at the competition, but software on the robot or driver station, which are already on the network, could access other robots' files. This would mean it would have to be someone in the competition doing it, but that's still a vulnerability.
The FTP is handled behind the scenes by the IDE, isn't it? I suppose changing it to SSH and adding a password would be easy and require minimal user interaction, since the IDE can save the password just like a web browser would for your email. As for the library, there was some messed up thing that had to be done with double inheritance with the Jaguar class, and I think a few bugs I can't remember. The naming scheme is also a bit arbitrary, but there wasn't anything too major (that I'm aware of), and I suspect that it's just because it's a relatively new technology. And Java programming on Linux and Mac, while possible with the special bytecode thing it uses, would still limit our choices. If my preference is Linux and C++, I shouldn't have to choose between the two, should I? |
Re: Driver station coding and other
Quote:
As for the FTP, while most teams use it simply for uploading code built through their IDE of choice quite a few teams use it for other things such as autonomous scripts, log files, and saving images. |
Re: Driver station coding and other
Quote:
|
Re: Driver station coding and other
Close. the field doesn't do VPNs, but it does do VLANs for each team. This means that traffic through the wifi router is effectively on six different subnets with no routing between. Also, the bridge is configured to join the network hosted by the field.
Greg McKaskle |
Re: Driver station coding and other
Quote:
|
Re: Driver station coding and other
Quote:
Building a cross environment on Linux would require - build a ppc cross compiler for x86 linux - integrate and test compiler in eclipse - test the method for downloading the code to robot - support all of the above for all the users versus - taking the existing wind river environment and deploy When you consider that supporting the environment on windows is taking all of the current volunteer time, you can see why adding another platform of limited utility to a small number of users is not a priority. If you can convince a small group of robo linux enthusiasts to build the environment, you could grow support for this endeavor. |
Re: Driver station coding and other
Quote:
Quote:
Quote:
Quote:
Quote:
In the meantime, I'll try getting GCC and WPIlib to work together on Linux and maybe write a small IDE in PyGTK. |
Re: Driver station coding and other
Quote:
Quote:
2) SFTP isn't very common, FTPS (SSL) would be a better option. Quote:
2) Java is already supported for ``Linux'' 3) C++ is not out-of-the-box supported on *NIX systems, people have gotten it working. Notable posts I've found are here, and here. I haven't tinkered with this, as we used Java this year, and have been pretty busy. Now that we've been knocked out of the competition, I think I'll get this working, and throw together a .deb package.* 4) LabVIEW can be developed on ``Linux'', but you must specially request the Linux version of LabVIEW (no cost for FRC teams). Though the RTM needed to deploy is Windows only. 5) Just be glad that the whole thing is open-source, and not a black-box system like 2008 and earlier. Quote:
*If anyone has any pointers on getting this working, or has experience with other package formats, PM me. |
| All times are GMT -5. The time now is 03:46. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi