Is FTP going to be available by default on roboRIO

I see that it is available, but not sure if they’re going to turn it off or not.

sFTP, not FTP.

Yes, I know it has that, but will it have ftp also? Mine shows it as enabled by default, and I’m wondering if that will persist after kickoff.

I believe that the myRIO, the academic product, had webDAV and sftp on and ftp off by default. I believe that the roboRIO will enable the anonymous ftp by default.

Greg McKaskle

The FTP server will be enabled on the roboRIO image, but will not have user account support. I recommend against using the FTP server, but it was included because some thought it might be useful.

Thanks guys. I’m contemplating using it for file transfer, because dealing with ssh in python AND in a cross platform friendly way isn’t particularly easy, unfortunately.

However, at the moment I think I have ssh/sftp working, and have a path forward on some of the issues I was originally having. We’ll see what happens.

Is there any reason you wouldn’t just want to install your own FTP server on the roboRIO, or any other type of server for that matter? As far as I’ve seen there wouldn’t be any restrictions on that.

That solution has a bootstrapping problem.

[rhetorical question] To access the server, it has to first be on the roboRIO, and it has to be running. How does one get the server on the roboRIO (and get it running) without SSH? [/end]

This question actually comes from my work creating the RobotPy installer. We could ask the user to install it on the roboRIO directly via SSH/SCP, but that makes the bar of installing RobotPy just a little bit higher, which is not desirable. In previous years, we had a two step installation process – install python on your dev machine, run the install script which then automatically copies the right files to the cRio – and I’d like very much for it to stay that way.

FWIW I’ve come to terms with the problem and I’ve devised a way that I can maintain my cross-platform compatibility without too much pain and suffering.

The RoboRio comes preloaded with a SSH server, SFTP server, webserver (already in use), and an FTP server.

The recommendation made by Joe to avoid using FTP is predicated on the fact that by default, the FTP only accepts anonymous logins, and as such anything you transfer over will have permissions not set properly.

If you want the permissions of your files to be set to the user running the FRC Robot Code, so that you do not run into file permission issues when reading or writing the files you transferred then use SCP (via SSH) or SFTP and login with the appropriate user.

Could users re-config the FTP server after the fact? Sure.

However, since your questioning is based on running an install script, you should re-write your install script to SSH into the RoboRio and transfer the files to the proper locations. This is exactly how the C++/Java build scripts transfer the binaries from your dev machine to the RoboRio when writing code. You can access the RoboRio by using mDNS and asking the user for their team number, such that you ssh into roborio-TEAM#.local

To make your script more bullet proof, have it fall back to the USB address and check 10.TE.AM.2 address if it can not resolve mDNS.

If you want your script to be cross platform, you can do this in many ways, scp is loaded on Linux and mac by default so you can just use that command line, on windows you can pre-package your script with pscp.exe from putty to run as a command line tool, or you can use something like jsch.jar from project to provide your script scp capabilities on all platforms it is running on.

Hope this helps,

Yes, I’ve already examined the build scripts for how they work.

If you want your script to be cross platform, you can do this in many ways, scp is loaded on Linux and mac by default so you can just use that command line, on windows you can pre-package your script with pscp.exe from putty to run as a command line tool

And this is also the same conclusion that I had already reached.

I know you meant this to be rhetorical, but if someone is actually wondering what the answer is…

The answer is serial console. The RS-232 port on the RoboRio is a console out, and you can access the terminal when ever you like via serial.

This will allow you to have full access to the Linux operating system on the Rio and install anything you like including servers.

On a working Rio this is not necessary because it comes loaded with some servers by default, but if you have kernel panics or don’t have an OS loaded, the only way you can access the Rio to determine what is going on is via the serial interface.

So in short, there is always a way in.

Agreed that it would work, but would fail the ‘easy to use’ requirement, given that most computers nowadays don’t have serial ports. :slight_smile:

Every computer I ever owned has at least one serial port - Universal Serial Bus :yikes:

I’m just being idiotic. I know you meant modern computers are lacking a RS-232 interface.

Sidetracking off the main post, but in all seriousness, you can get a USB-to-serial converter for like $5.

We made our own for even less from radioshack parts, but here is one at amazon

I highly recommend every FRC team buy something like this, for those just in case moments. If you already have a serial to usb interface from an arduino or other microcontroller those will work fine.

As alpha and beta testers we deliberately tried to crash the RoboRio, and having one of these handy, definitely saved our butts numerous times.

These cables and ATX fuses will become a prized commodity at competitions this year, trust me!

However, with that said, safemode on the RoboRio should help you recover 99% of the time without ever needing to use the serial interface


On a following note, how long does it take to bring the Rio back to life in the event the OS is lost?

Also, what procedure and particular resources would be needed?

The typical procedure requires the imaging tool, a USB cable, and about five minutes. Lower level formatting of other firmware or other chips is quite rare.

Greg McKaskle