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!

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

[Joe Ross]

Originally Posted by apples000

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?

Using a DIO to control a relay will likely never be legal.

[Thad House]

Originally Posted by Joe Ross

Using a DIO to control a relay will likely never be legal.

There's no rule currently saying you have to hook relays up to the relay ports. The only hookup requirement is that servos must be hooked up to PWM ports.

[Pat Fairbank]

Originally Posted by Thad House

There's no rule currently saying you have to hook relays up to the relay ports. The only hookup requirement is that servos must be hooked up to PWM ports.

<R66> Every relay module, servo, and PWM motor controller shall be connected to a corresponding port on a Digital Sidecar and be controlled by signals provided from the cRIO. They shall not be controlled by signals from any other source.