2015 Control System Alpha Testing

I was just informed that our 2015 Alpha Test Control system should be arriving tomorrow morning.

Our team is thinking through how exactly to test the devices. At this time, we’ll be receiving:

roboRIO 1
Power Distribution Panel 1
Breakers (40A) 2
Voltage Regulator Module 1
Pneumatics Control Module 1
Battery cable 1
120A breaker 1
Serial cable 1
USB Cable 1
3-wire “PWM” cables 2
Talon motor controller 2
USB WiFi Radio 1

My question, which goes out to all the teams is this: if you had a chance to get your hands on the control system, what would you want to test and how would you do it?

Some things we’re going to look at initially:

  1. Time to boot (OS Running)
  2. Time to code-available (OS Running and code executing - tethered)
  3. Time to driving (OS Running and talking to the DS wirelessly, mainly a function of the USB Wifi Radio boot time)
  4. Code interoperability - running our 2013 code on the new system
  5. CPU usage - we’re going to do some A versus B vision tests to really stress the CPU and compare it to the 4 slot cRIO.
  6. ?

Remember a couple things before you make suggestions. We are a LabVIEW team, and we’re using this to train new members. So we can’t fill any C/C++/Java requests at this time.

In addition, we don’t have elaborate test setups. If you want PWM accuracy measurements with oscilloscopes, it probably isn’t going to happen… but we’ll try to accomodate requests if we can.

I’m sure FIRST will have a series of tasks that they want us to perform as well. I do know that this control system is going to be placed our on 2013 competition robot and tested on a FIRST field. We’ll keep a log of events on our web page: we hope to have pictures of the components up tomorrow. I’ll start a seperate thread on that when it happens.

Finally, please keep in mind that nothing we post is official. We will not be posting code or associated documentation that is released to us by FIRST. This has been a request from FIRST to prevent multiple revision levels and confusion if documents that are not ready are made public. We are more than welcome, however, to post our own code, pictures, and anything we learn about the unit.

We will be demoing the controller at a later date and throughout the 2014 competition season.

Tests in a more physical way:

-How heavy is it (rRIO, PDB, Radio, Breaker)
-What are each part’s footprints? are they bigger/smaller/different shaped than current system?
-Are mounting procedures similar? are ports easily accessible? (current PDB is tricky)
-No more sidecar? what is the status on that?

As far as software goes (though I have no experience in LabView):
-How does it handle multiple (or many) threads?
-Can it process images faster? Targeting? (our targeting took retro-reflective feedback, determined the useful return, calculated target distance, and sent numbers to other systems for shooter speed and left/right alignment)

Great questions. So,

  1. Weight and dimensions of each component, and comparisons to current system.
  2. Mounting system for each component.
  3. Connectivity and component layout

As for threading, LabVIEW is inherently parallel. We don’t have to do to anything special to have things process concurrently. LabVIEW handles that all itself. How would you test something like that?

As for the processing images, that’s 5 on the list.

With regards to the sidecar - no, it’s not needed. Almost all the standard I/O that you’re used to is now built directly into the controller itself, and it has a small footprint and is very light (comparitively). Expansions are allowed through the I/O port on the top of the controller. There will be an external pneumatic controller (if you need to use it). General info about the RoboRio can be found here: https://decibel.ni.com/content/docs/DOC-30419

Be sure to post plenty of pictures!

As another alpha team, I just wanted to remind the CD community that we are under an NDA so there will be things we cannot answer. We will look to this thread to see what the community asks for to see how we can help. Just remember we may not be able to give you what you want.

If we get the familiar with the system in time we are going to attempt to bring it in our 2013 robot for an offseason events. Also, we will be bringing our unit to any fall workshops in the Southern California area.

Information on the USB host ports would be interesting. Are there any native USB storage or camera drivers? Can labview access them?

I guess if I had seen this earlier it would have eliminated a few questions before I posted.

The design sure harks back to the pre-cRIO days.

just though of an important question:

-Will it survive being run over by a hummer like the cRIO can?

-Will it survive being run over by a hummer like the cRIO can?

Uh, … no. Since that isn’t really an FRC requirement, it isn’t worth the tradeoffs – weight, cost, etc. Similarly, the modularity used in industry is also removed – it was added back in a new way.

To the USB question, the USB ports can do whatever the drivers allow, UVC is the video standard, and UMS is the memory-stick standard. You can get a pretty good idea of what is supported by looking at the standards on wikipedia and identifying the linux support.

Greg McKaskle

That’s what you think! goes and launches Photoshop

Yeah, I figured as much :smiley: just had to ask anyways. It would be schadenfreude to see you smash a brand new rRIO though.

While we intentionally fried a couple of Talons last year just to see how robust they were, I don’t think we’ll pursue the same testing regimen with the roboRio… :smiley:

There was the one FRC situation I know of … see attachments.

Of course in the grand scheme of things, it doesn’t do much good when the cRIO simply gets mashed through the bottom of the robot and crate. The energy has to go somewhere. The cRIO may survive, but you still have to build it a new body.

I hope Rick doesn’t mind me bringing back painful memories.
Greg McKaskle



Why, was it too hard to fry them? :smiley:

Wait, was there a registration for becoming an alpha tester/how did these teams get selected for this?

Did I miss something? :stuck_out_tongue:

To echo Tom Line, we’ll be doing similar testing from a Java perspective, and I’ll be keeping an eye on this thread so we can try to duplicate tests and independently confirm results/find differences between different languages, if applicable.

dellagd - You can see the official Alpha Testing announcement here: http://www.usfirst.org/roboticsprograms/frc/blog-2015-control-system-alpha-testing

FIRST had a process for selecting teams to invite to be Alpha Test teams (There was no open registration for this - invite only, as far as I know). If you have questions on their exact process, I recommend asking them in a comment on the above blog post.

So… Um… should we be durability testing the rRio for that particular circumstance? I’ve got a couple team members who have an incredible knack for destroying robot parts…

I’m curious how the rRio deals with a second high bandwidth USB device being used at the same time as the usb radio. Are both ports connected to the same root hub so that they share the bandwidth? Having written a USB driver for work, I have learned enough to be skeptical of USB.

I’m also curious what the bandwidth is to the various digital inputs and outputs. How fast can you actually read them by polling? I have seen other controllers (Chumby Botball Controller, I’m looking at you) get this very wrong. Hook up an encoder, and count the edges in polling code. See how fast you can spin it before loosing counts.

What rate can the controller actually read encoders? Edges/second. How many encoders can it support?

We used (before it lost us a regional) a feature in WPILib which let us read an encoder immediately after a hall effect had a positive edge by firing an interrupt. This was awesome since we could use it to figure out when a joint passed the homing position without having a polling delay. Does this work in the new version?

How is the timing jitter? ± ?% Am I going to have to work really hard to get my timing accurate to avoid control loop problems like on the cRIO? I can’t count how many control loop problems ended up being timing jitter problems…

Tom, the shipping company has graciously volunteered to do that testing.

Austin, I was going to send you a URL to the specs, but what I could find was pretty light. I’ll try to answer them here.

USB bus can be overloaded, but so can ethernet. The effects when you do so are different, and you are correct in being skeptical. It will be tested in this situation.

As for other I/O rates – the roboRIO is a similar architecture to the cRIO and all other NI RIO devices. RIO stands for Reconfigurable I/O, and that means an FPGA is user-programmable to handle the hard-real-time duties like building a decoder from some digital inputs. The I/O speeds of cRIO are determined by the modules, so the roboRIO digital speeds are actually far higher.

I don’t have the details on count and speed, but it I believe it is the same number of encoders at about 10x the speed.

As for jitter of the RT code reading the encoder, that is something you control. VxWorks is a realtime OS and you should be able to measure and control jitter, but the base templates and frameworks in FRC avoid many of those features in order to keep the code clean. The RT-linux OS will offer many of the same features, but if you don’t use them, you are trading simpler code for jitter. How much jitter are we talking about, and do you know what was causing it?

Greg McKaskle

The symptoms generated by the new system under low voltage conditions (momentary dips as well as a dead battery) would be of interest. The effect of low voltage brownout on a maxed out USB power output, various communications types, PWM/Relay/Digital outputs, voltage regulators, peripherals like the pneumatics breakouts, in addition to how the system handles staged shutdown. The shutdown response to a short on the different types of power pins (what doesn’t get cut), overloading the power draw of the USB ports, that type of thing.

Ability of software to detect and report or act on these power outages.

How the system responds to the overload of time unconstrained loops and other common rookie programming mistakes - grind to a halt or critical operations take priority.

Easy to write a test program that exercises every I/O at once. Identify limits, e.g. max number of encoders supported, and what happens when you try to go past those limits. Test and verify the limits they’ve told you the new system has.

^This. Spoken like a true veteran of realtime embedded programming:)