2015 Control System Alpha Testing

[Tom Line]

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.

[BBray_T1296]

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)

[Tom Line]

Originally Posted by BBray_T1296

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,

6. Weight and dimensions of each component, and comparisons to current system.
7. Mounting system for each component.
8. 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

[cgmv123]

Be sure to post plenty of pictures!

[kaliken]

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.

[mman1506]

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

[BBray_T1296]

Originally Posted by Tom Line

https://decibel.ni.com/content/docs/DOC-30419

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?

[Greg McKaskle]

-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

[cgmv123]

Originally Posted by Greg McKaskle

Since that isn't really an FRC requirement

That's what you think! *goes and launches Photoshop*

[BBray_T1296]

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

[Tom Line]

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

[Greg McKaskle]

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

[cgmv123]

Originally Posted by Tom Line

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

Why, was it too hard to fry them?

[dellagd]

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

Did I miss something?

[Jon Stratis]

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