Alpha Weekend #2, 2015 Control System

[Tom Line]

We just finished up the second Alpha weekend in New Hampshire, so now is probably a good time to give an update on what's been happening with the new 2015 hardware.

As a preface, we're a LabVIEW team, and our test robot from Ultimate Ascent has 11 talons, drivetrain encoders, a gyro, a photoeye that we're using as a counter for speed control, an analog string pot and an analog potentiometer.

Back in September, most of the components weren't working correctly due to a combination of hardware and software issues. I'm happy to say that a couple hours into Saturday, everything on our robot was functioning correctly. There were no significant differences in LabVIEW code.

We did get some bad news going into this weekend. Unfortunately the ASUS wifi dongles simply didn't play well enough together to supplant the current DLINK radios. So this weekend we spent all our time on the field using the DLINK radios. Bummer, but I'd much rather use a well proven product than spend a season with connectivity problems.

We all got new pneumatic control modules this weekend. While we put ours on the robot, we don't have any pneumatics so I can't comment on the functionality. I know the other teams spent a pretty fair amount of time working with the pneumatic systems and code, discussing backwards compatibility, and how automatic compressor control should work since the new PCM closes the loop itself with the compressor.

We got a chance to play with a new, updated driver station that utilized mDNS so we didn't need a static IP on your RoboRio for our driverstation to find it on the network - it used the RoboRio name instead. This could eventually lead to a point where it's unneeded to set a static IP on the driverstation either, but we didn't test that out at all. No word for certain if these features will make their way onto the competition field or not.

We spent a lot of time testing what happens when the RoboRio browns out. We were able to continue running our robot until the point where we started seeing dips into the 5-6 volt range.

I'm happy to say that deploy times have been reduced significantly for LabVIEW. We were one of the unhappy recipients last year of the bug that left us waiting long periods for our code to deploy (using the run arrow). Seeing it go over in 20-30 seconds was great.

Imaging happens over USB now with a new imaging tool, and our experience was a huge improvement over last year's as well. One try and it was done. It was also faster.

NI also mentioned that they're looking at not requiring a RoboRIO reboot when new code is permanently deployed via LabVIEW, which will be a nice improvement if they manage to work it in.

A portion of the weekend went towards safety discussions as well. Especially on how the expansion port and potential break-out boards will be handled. It opens up a whole new realm for creative teams, and adds a whole new layer of potential complexity for those poor inspectors!

I feel like I've only scratched the surface in this list, and I'm sure the Java and C++ teams will have more to add. HUGE thanks go out to FIRST, NI, and CrossTheRoad Electronics for all the work that went into this weekend. As always, everything mentioned here is on a "maybe" basis, and nothing is definite until we get our kit of parts in January.

[AllenGregoryIV]

Thank you for keeping everyone updated. We appreciate it.

[AllenGregoryIV]

I have a question about the new control system.

When tethering the RoboRIO are teams using USB tethering? If so how are teams doing really long tethers like you sometimes need on practice fields? We have a 75' Ethernet cable for that now but are teams buying really long USB extension cables for the RoboRIO?

[Jon Stratis]

You can tether to the RoboRio through either USB or Ethernet, after everything is set up (I believe you need to start with USB to get it set up initially). With the switch back to the DLINK radios, there should be no difference for you at competition when tethering in the pits or on the practice field.

[AllenGregoryIV]

Originally Posted by Jon Stratis

You can tether to the RoboRio through either USB or Ethernet, after everything is set up (I believe you need to start with USB to get it set up initially). With the switch back to the DLINK radios, there should be no difference for you at competition when tethering in the pits or on the practice field.

Is the DLINK switch official? I knew they had to do that for the practice I wasn't sure if that was a final decision or not.

[Jon Stratis]

I doubt anything will be official until the first weekend in January, but at least so far it's our best guess. If they find a way to get a USB wifi dongle to work for us and switch to it, then you'll still have the available ethernet port on the RoboRio to use for tethering. In that situation, it probably won't be as accessible as the DLINK has been for the past few years, but with a short ethernet cable and a female-female connector, you can make it as accessible as you want.

[Tom Line]

I'll add in when you plug into the USB of the RoboRio with your laptop, it shows up as an ip address in the range (from memory, might be wrong) 172.X.X.X

Obviously, the current driver station doesn't care for that, and if you use labview you'd need to adjust the IP address you're deploying to in your project.

The temporary driver station we've been using has a work around. I haven't tried using the new one that we got at Alpha.

So for right now, we've been continuing to tether through the dlink so we don't have to play with network settings. We set the ethernet port on the RoboRio to the standard IP address, 10.te.am.2

[apples000]

Forgive me if this is on a website, or already posted, but I have a few questions about the new control system.

1. How are the times to deploy code, reimage, reboot, or connect?
2. What is the overall quality of the board and its software?
3. Are there any tools to monitor the CPU/RAM usage of the system? If so, what is the typical usage?
4. Have you confirmed the brownout voltage, or seen any part of the system drop out?
5. How well does CAN work? Are there still issues with floods of errors?
6. I2C/SPI/Serial timing? Does it work?
7. Encoders-how fast with 4x sampling, can it still do averaging? Does it have issues with getRate?
8. How much of the linux operating system is exposed? Have you used any linux features yet?
9. We're one of those teams that just wants a single solenoid for shifting so we don't want the fancy pneumatics bumper, but we use more than 4 relays on most robots. How much current can the DIO source? Enough for a relay? Can the super expansion port do it?

10. Most importantly, what are the plans for the cRIOs? Can we use them on a practice bot next year? When LV/windriver licenses run out, do we end up with really expensive paperweights? That would really suck. A lot.

11. How robust is communication? How often is there an issue between any parts communicating with each other?

12. How easy is it to troubleshoot these issues?

Thanks!

[Joe Ross]

Originally Posted by Tom Line

I'll add in when you plug into the USB of the RoboRio with your laptop, it shows up as an ip address in the range (from memory, might be wrong) 172.X.X.X

One advantage that is that the usb ethernet acts as a DHCP server, so you do not need to configure the IP address of your programming computer(s) to the 172 address. That is definitely nice.

[Jon Stratis]

Originally Posted by apples000

Forgive me if this is on a website, or already posted, but I have a few questions about the new control system.

1. How are the times to deploy code, reimage, reboot, or connect?
2. What is the overall quality of the board and its software?
3. Are there any tools to monitor the CPU/RAM usage of the system? If so, what is the typical usage?
4. Have you confirmed the brownout voltage, or seen any part of the system drop out?
5. How well does CAN work? Are there still issues with floods of errors?
6. I2C/SPI/Serial timing? Does it work?
7. Encoders-how fast with 4x sampling, can it still do averaging? Does it have issues with getRate?
8. How much of the linux operating system is exposed? Have you used any linux features yet?
9. We're one of those teams that just wants a single solenoid for shifting so we don't want the fancy pneumatics bumper, but we use more than 4 relays on most robots. How much current can the DIO source? Enough for a relay? Can the super expansion port do it?

10. Most importantly, what are the plans for the cRIOs? Can we use them on a practice bot next year? When LV/windriver licenses run out, do we end up with really expensive paperweights? That would really suck. A lot.

11. How robust is communication? How often is there an issue between any parts communicating with each other?

12. How easy is it to troubleshoot these issues?

Thanks!

1. Times are great! Definitely improved over the cRio, at least for Java and c++
2. Quality seems great. They took a lot of feedback from the alpha teams in some of the small details to make sure things would be great for teams.
3. We haven't tried yet, but it's Linux and you can easily open up a terminal window, which means you should be able to do realtime monitoring.
4. We haven't seen the RoboRio drop out at all... The motors have drained down and stopped working before we got to that point with low batteries.
5. We're setting up a test for CAN right now - we've moved the system over to a new robot with 6 jags on CAN... Testing swerve drive with it
6. Haven't tried them.
7. We'll be testing that with the new drive system - 4 encoders and 2 potentiometers are present for drive feedback.
8. From what I've seen, pretty much all of it. Haven't really done anything special with it, though.
9. You can see full specs here: https://decibel.ni.com/content/docs/DOC-30419
10. We've given that feedback to FIRST, WPI, and NI, and they are well aware of the need to continue supporting the cRio.
11. We haven't had any communication issues at all.
12. Honestly, we haven't had much need to troubleshoot anything. We had a potentiometer break on us, but that was just as easy to figure out as with the cRio.

[Mark McLeod]

Originally Posted by apples000

10. Most importantly, what are the plans for the cRIOs? Can we use them on a practice bot next year? When LV/windriver licenses run out, do we end up with really expensive paperweights? That would really suck. A lot.

Java and LV are both good for the foreseeable future.
The Windriver license will expire, but others have looked into using an alternate toolchain.
UCPP: cross-platform C++ toolchain

[Bryce Paputa]

Is there a possibility of a CAN motor control other than the jags?

[Jon Stratis]

Originally Posted by Bryce Paputa

Is there a possibility of a CAN motor control other than the jags?

Possible? Yes. However, we haven't seen one in our testing, nor been told that one is coming. I've heard rumors (unrelated to Alpha Testing) of both CAN Talons and CAN Victors. I don't know if or when we'll ever see one of those, though!

[Greg McKaskle]

I'll add just a bit. Responses marked with ***s.

1. How are the times to deploy code, reimage, reboot, or connect?
*** Since the OS has protected processes, it is far less common to reboot, more common to restart. Reboot is similar to cRIO, but restart is about five or six seconds.

2. What is the overall quality of the board and its software?
*** One of the design goals/requirements was to be able to short any pin to any other on the board. Shorts and over voltage are indicated with LEDs and diagnostics. This is a new SW platform for NI, but several products have already released with it. I'm sure the beta will find some things, but it seems relatively robust entering beta.

3. Are there any tools to monitor the CPU/RAM usage of the system? If so, what is the typical usage?
*** The device hosts a Silverlight-based web page that is used for common configuration and monitoring. It shows CPU and resource on the page. You can also SSH and use top or other tools. Typical is too broad for me to give numbers for. But I'm happy with resource usage to this point.

4. Have you confirmed the brownout voltage, or seen any part of the system drop out?
*** This was a major focus of the alpha 2 weekend. Things are still being tweaked, but the robots were intentionally run with weak batteries to observe brownout behaviors of roboRIO, VRM, and PCM.

5. How well does CAN work? Are there still issues with floods of errors?
*** This is being entirely reworked to simplify device state management and error conditions.

6. I2C/SPI/Serial timing? Does it work?
*** I'm not sure what you are specifically asking about. These are included in the testing station with kit sensors.

7. Encoders-how fast with 4x sampling, can it still do averaging? Does it have issues with getRate?
*** Joe or Doug can answer this better than I. Ultimately, encoder rate will be significantly higher. I'm not sure what it is right now. Averaging is still present. getRate will still have noise issues near its limit.

8. How much of the linux operating system is exposed? Have you used any linux features yet?
*** 99.44%. I'm not sure I understand the question. We believe it is a good configuration out of the box, but you are the admin and it can be upgraded for other devices and libraries using standard mechanisms. I use the shell quite a bit.

9. We're one of those teams that just wants a single solenoid for shifting so we don't want the fancy pneumatics bumper, but we use more than 4 relays on most robots. How much current can the DIO source? Enough for a relay? Can the super expansion port do it?
*** Not sure I can do better than point you to the specs or ask for a more detailed question.

10. Most importantly, what are the plans for the cRIOs? Can we use them on a practice bot next year? When LV/windriver licenses run out, do we end up with really expensive paperweights? That would really suck. A lot.
*** Agreed. The goal is to allow them to be used for training, second robots, etc.

11. How robust is communication? How often is there an issue between any parts communicating with each other?
*** I'm not sure what devices in particular is being referred to. The USB connection vastly improves the imaging experience. The PC has a virtual NIC that bridges over USB. This auto assigns IP and doesn't go up and down during the imaging. Similarly, it comes up faster during reboots. CAN is being reworked to fail more gracefully when a cable or device fails. It also has full bandwidth since it isn't being bridged.

12. How easy is it to troubleshoot these issues?
*** Any in particular?


*** Another question was asked about the DLinks vs USB dongle. The plan was to develop and compare multiple options for robot communication. It was, unfortunately, not possible with the schedule and other constraints to make the roboRIO into a sufficiently good integrated wifi device. FRC demands are high, but volumes are low. The USB dongle was attractive, but bugs in linux drivers cause issues when used on an official field. This will be reevaluated when schedule permits. The DLink or a similar bridge solution was included as a known reference point. To this point it has been used in about one million official matches. Diagnostics and configuration improvements are underway. Additional communication options were investigated and some are still under evaluation.

Greg McKaskle

[Bryce Paputa]

Any idea if we will be able to easily port roborio code to the crio for use on practice robots? Specifically java code.