Alpha Weekend #2, 2015 Control System
 

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! :D

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.

Re: Alpha Weekend #2, 2015 Control System
 

Thank you for keeping everyone updated. We appreciate it.

Re: Alpha Weekend #2, 2015 Control System
 

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?

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

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!

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

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!

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

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

Re: Alpha Weekend #2, 2015 Control System
 

At this point, they are very similar and it would not be hard to make a program work on both.

Re: Alpha Weekend #2, 2015 Control System
 

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.

Re: Alpha Weekend #2, 2015 Control System
 

For C++, one could also use GCC 4.8.0 and newer. Windows and various distros of Linux are supported natively. See http://firstforge.wpi.edu/sf/projects/c--11_toochain. There are also Eclipse plugins for it but I don't think they are officially packaged for Windows. One would have to track down the .jar files to place them in the dropins folder.

Re: Alpha Weekend #2, 2015 Control System
 

2 things:

1. Has anybody had time to look at using USB to communicate with a co-processor? Is this even supported? How comprehensive is wpilib in supporting this at the moment?

2. I believe this has already been adressed, but are there any updates on when the roboRIO will be released to teams? Would it be possible for the 2015 wpilib to get released first, or at least a beta version? I really want to get a chance to look at developing code for some of the newer features on the roboRIO.

Re: Alpha Weekend #2, 2015 Control System
 

<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.

Re: Alpha Weekend #2, 2015 Control System
 

Ah I must have just skipped right over that. Also thinking about it, that rule makes sense because of the integrated pullups. That could get bad if it has enough current to run the relay. Yeah my bad.

Re: Alpha Weekend #2, 2015 Control System
 

Also, hooking a Relay to a DIO will leave one channel of the Relay permanently on (corresponding to the DIO power line).

Re: Alpha Weekend #2, 2015 Control System
 

Okay, off topic, but r66 was mentioned so I hope this isn't too off base.
My team is currently in the middle of designing a swerve drive. Part of the design is a custom circuit board that would be mounted to each swerve module to reduce the amount of computing the ___RIO has to do, as well as improve modularity, wiring, and ease of replacement if a module were to fail. The board takes inputs from the SideCar (if using 2014 and older control system) or roboRIO itself over SPI. The circuit board then processes the inputs and turns them into PWM motor commands, which are sent to a Talon or other approved motor controller. Does this meet the requirements of R66? It could be interpreted as legal if one thought that the ___RIO was still providing the signals by proxy, or it could be viewed as an entirely separate entity, and therefore illegal. Another thought, with the integration of the various serial communication ports on the roboRIO, as well as the MXP boards, do you think that this rule could be omitted, reworded, or loosened in next years manual?
Thanks and sorry if this is off topic and/or confusing.

Re: Alpha Weekend #2, 2015 Control System
 

This doesn't meet the rule because there isn't anything specifically preventing you from leaving those PWM singles on after the robot is disabled. It's a safety issue for everyone at events.

Re: Alpha Weekend #2, 2015 Control System
 

Such a board would be considered a "CUSTOM CIRCUIT", per 2014 rules. The specific rule you're looking for here is R71:

There is no wiggle room in that rule - outputs from a custom circuit CAN NOT be connected to the PWM inputs on a speed controller.

I expect this particular rule might be changed a little bit for next year, in order to accommodate break-out boards attached to the MPX port on the RoboRio. Despite that, I doubt it will change enough to make your solution legal.

Re: Alpha Weekend #2, 2015 Control System
 

971 does the same sort of offboarding you are talking about, but in order to comply with R66 (among others) they have to send all PWM, relay, and solenoid output data back to the cRio before it gets forwarded to controllers. Thread

Re: Alpha Weekend #2, 2015 Control System
 

As others have already answered, this would not be allowed under current rules, and I would be shocked if the rules allowed it next year.

Now, if you're doing it just for the experience, don't let me dissuade you. It sounds like a fun controls design task.

If wiring simplicity is your desire, you can use the Jaguar's internal PID over CAN. That way the sensor wiring just has to run back to the Jaguar. The only reason we don't do this is because the analog encoder we use requires a 5V input and only outputs 0-5V. The Jaguar outputs 3.3V and is looking for a 0-3.3V input. It ends up complicating the wiring and requires a voltage divider in there to make things right.

On the other hand, we have run at least 6 (maybe 7... can't remember) simultaneous PID loops on the cRio and never got close to 100% processor usage and saw no ill affects to any of the controls. We were using the WPILib PIDController on C++, so with other languages/controller YMMV.

Re: Alpha Weekend #2, 2015 Control System
 

What support would you want to see in WPILIB, vs using the interface provided by the OS?