Alpha Weekend #2, 2015 Control System

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

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

[Joe Ross]

Originally Posted by 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.

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

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

[Thad House]

Originally Posted by Pat Fairbank

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

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.

[Mark McLeod]

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

[glennword]

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.

[AllenGregoryIV]

Originally Posted by glennword

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.

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.