My Experience Setting-up FRCSim

Getting into It

FRCSim has a lot of promise. Extend your SolidWorks CAD with some joints and physics, and roll around a virtual field?! Yes, please! Just imagine all the awesome experimentation you could do with it to improve the quality of the control system. Test your autonomous mode! Tune your PID control gains! Be sure your drive team has the controls they need! And all prior to getting to an FRC competition. I’m also interested in using it as an education tool: it has the potential to open up programming to non-programmers in FIRST and to educators outside the program as well! However as with many new technologies it is a delicate system. A lot needs to be configured correctly in order to get the basic functionality working well.

So I thought it might be useful to share my experience getting FRCSim up and running. The wpilib folks have already put together an excellent user’s guide which leads you through the process of installing and configuring the toolchain, so I won’t be copying that effort here. Instead, these are my experiences so far, and recommendations on how to best install, tweak, test, and navigate the system.

Before jumping into the user’s guide for yourself, you may find it useful to print off a copy which is also available as a PDF.

Installing Ubuntu

The installation begins with Ubuntu, a popular distribution of the linux operating system. There appears to be some support for OS X, but I don’t have a Mac to test this. Ubuntu is well detailed in the user’s guide, and I’ve had a great time with it in the past. I used it as my daily driver operating system in college, back when it really starting to gain popularity.

The top of the Installing Ubuntu page suggests using the older 14.04 LTS (Long Term Service) since the wpilib folks have an automatic installation script for the whole FRCSim toolchain. When I first attempted the procedure, I wasn’t interested in running old software. Later on the same page, the Running in a Virtual Machine section also mentions FRCSim should work with the more recent 15.10 Ubuntu version. So I decided to move forward with that, and started the download of the 64bit .iso.

While that was downloading, I had some installation options to consider. Some folks may want to dual-boot as it would be ideal from a performance perspective. Installing the operating system on the hard drive would avoid throughput bottlenecks typically seen in live booting from a DVD or USB drive. This would also avoid weathering a USB drive faster than usual. But sharing this with my team (FRC Team 3182 – Athena’s Warriors) and anyone else who’s interested was and is paramount! So I scrounged up a 16GB USB drive, plugged it into an open port, and prepared the installation.

By the time the download completed, I had VirtualBox up and running. I created a new virtual machine in it, making sure that the USB drive was available to it. I started the virtual machine, selected the .iso I downloaded as the boot medium, and followed the standard installation procedure using the USB drive as the “hard drive”. And after that completed, I had a shiny new live USB drive with a stock Ubuntu 15.10 ready to go! (The user’s guide has a little more detail on these steps.)

Installing the FRCSim Toolchain

With my fresh installation of Ubuntu ready to run, I booted into it and began installing the FRCSim toolchain. As I mentioned earlier, if I had chosen to use Ubuntu 14.04, the wpilib folks provide a script and one-step procedure to install almost everything for you. Very nice! Unfortunately, that’s not compatible with newer Ubuntu versions. So instead I had to follow the more complicated, but not impossible manual procedure. Saving you the boring hour or so, the installation went along without any issues.

Or so I thought. When I first tried to run FRCSim, I got a rather cryptic error:

[Err] [Plugin.hh:165] Failed to load plugin /home/ubuntu/wpilib/simulation/plugins/liblimit_switch.so: libboost_system.so.1.54.0: cannot open shared object file: No such file or directory
 gzclient: /build/ogre-1.9-VJX7tp/ogre-1.9-1.9.0+dfsg1/OgreMain/src/OgreRenderSystem.cpp:546: virtual void Ogre::RenderSystem::setDepthBufferFor(Ogre::RenderTarget*): Assertion `bAttached && "A new DepthBuffer for a RenderTarget was created, but after creation" "it says it's incompatible with that RT"' failed.

From that first line, it appears I’m missing one of the basic Boost libraries, but Boost was installed automatically as part of a step in the manual procedure. A little bit of googling turns up the issue in the wpilib issue tracker and on a chief delphi post. Boost version 1.54.0 is hard coded into the Gazebo plugins wpilib provides, but Ubuntu 15.10 only has the newer Boost-1.58.0 in its repository. Rather than force the Gazebo plugins to rely on a library they weren’t designed for (via for example symbolic links), I tried manually installing Boots-1.54.0.

To get the appropriate version of Boost, I needed to build it from source: the typical linux bootstrap, compile, and install. The Boost developers provide a very easy way of going about this using their own bjam utility. And following the advice in this stack exchange post, using checkinstall to make it a pseudo package sounded particularly appealing. This would treat the source build as any other package installed on the system. I’ve never worked with it before, so I gave it a shot and… checkinstall failed.

And this is where I began to re-evaluate what was important. 🙂 Why am I trying to install a pseudo package of an older Boost library on a newer Ubuntu release to appease the hard coded value in the Gazebo plugin? (Try saying that on one breath!) Why not just use Ubuntu 14.10 and the wpilib install script? What is truly important in life???

So, after I downloaded and installed the recommended Ubuntu 14.04, and ran the wpilib installer script, I had even more time to figure that out, worry free. 🙂

Hello World

The Simulating GearsBot with FRCSim page of the user’s guide walks you through creating a project in Eclipse, and simulating a sample configuration using an existing model called “GearsBot”. This is a good demonstration of what could be done with the right tools. The model is moderately rendered, joints and physics seems accurate, and the code is complete.

It runs great on my custom built high performance desktop machine, but my old Toshiba Portege R705-P25 laptop doesn’t fare so well. Built in 2010 with no dedicated graphics card, the physics and graphics simulations are a huge tax on the system. Frame rates drop to flip-book levels making FRCSim nearly unusable.

Fortunately, another sample model called “EKIPS” is low power friendly. While GearsBot doesn’t have every plate, mount, motor, and component rendered, (like the alternative “PacGoat” seems to have), EKIPS is just a few blocks and wheels. This minimizes the strain on my old laptop raising the frame rate above a usable 30 frames per second. Using this robot lowers the computational barrier for entry, allowing more potential programmers to have access to FRCSim.

There is no code provided for EKIPS, but expanding on some of the tutorials in Eclipse should be enough to at least get the robot rolling. For example, here’s some code that will drive EKIPS with a single joystick in arcade mode.

/**
 * This is a demo program showing the use of the RobotDrive class with the EKIPS
 * robot in FRCSim.
 */
public class Robot extends SampleRobot {
  // Simple robot handling instance variable
  RobotDrive myRobot;

  // A joystick instance variable
  Joystick joystick;

  // Robot class constructor. Inits channels for drive motors and joystick
  // USB id numbers
  public Robot() {
    myRobot = new RobotDrive(4, 3, 2, 1);
    joystick = new Joystick(0);
  }

  // This function is called when entering teleoperated mode
  public void operatorControl() {
    // Be sure the drive motor safety system is disabled. (This system will
    // prevent the motors from driving if not commanded at a regular interval.)
    myRobot.setSafetyEnabled(false);

    // While we haven't left teleoperated mode and the robot is enabled
    while (isOperatorControl() && isEnabled()) {
      // Command the robot to drive based on the joystick in arcade
      // configuration.
      myRobot.arcadeDrive(-1 * joystick.getX(), -1 * joystick.getRawAxis(0));

      // Wait 5ms to allow other processes time to run on the roboRio and not
      // bog down the system.
      Timer.delay(0.005);
    }
  }
}

Joystick Configuration

Time to drive that ‘bot! After running FRCSim, the simulated driver station (sim_ds), and the robot code in Eclipse, none of the joysticks I plugged into my computer showed up in sim_ds! Turns out that stock Ubuntu doesn’t have game controller support. To get physical joysticks to work in FRCSim I also had to download a couple additional packages:

• joystick – A set of testing an calibration tools for joysticks
• jstest-gtk – A joystick testing and configuration graphical user interface.

sudo apt-get install joystick jstest-gtk

No special configuration here. After these were installed, the joysticks popped up in sim_ds and worked fine. And running the jstest-gtk tool help me identify what button was what in the software.

Final Remarks

And with that, I’m off and running simulating to my heart’s content! Here are a few other random tips and things to consider as you begin simulating robots for yourself.

I find that running FRCSim, sim_ds, and Eclipse’s simulation target is a delicate game of spinning plates. If you’re having issues but everything seems to be coded and configured correctly, try restarting the FRCSim, or sim_ds, or both and rerunning the code in eclipse. I find it use full to have a separate terminal window open for each application, each in it’s own virtual desktop. This allows me to see more output from each application and get back to developing faster when an issue comes up.

Joystick axes, buttons, and id numbers may change between operating systems. Be sure to check your ids in the code when moving between Windows, Linux, and OS X before debugging other related issues.

Running a live system from a USB drive can weather it more quickly than using it solely for file transfers. While you should be fine while you experiment with FRCSim, one common way to prevent excessive wear is by disabling access time updates to files within the operating system. This is handled by the file system table file: /etc/fstab. Add the noatime option to your fstab by appending it to the options list preceded with a comma. For example, my fstab looks like this.

# <file system> <mount point> <type> <options> <dump> <pass>
UUID=ee3de0ce-7e50-46f5-b0b9-ca1548b961ef / ext4 errors=remount-ro,noatime 0 1

Finally, minimizing the workload on the GPU of your system by non-essential applications may lead to better overall performance. Unfortunately, Ubuntu’s default Unity desktop uses the same hardware acceleration your simulation is using! For resource-strapped systems such as my laptop, this is an issue. To get around it, you can install the classic version of Gnome’s interface, known as gnome-flashback to the package manager. And personally, I like this interface a lot more than Unity. 🙂

sudo apt-get install gnome-flashback