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]

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]

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]

Since that isn't really an FRC requirement

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

[BBray_T1296]

Yeah, I figured as much :D 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... :D

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

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

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

[dellagd]

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

Did I miss something? :P

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

[Tom Line]

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

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

[AustinSchuh]

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

[Greg McKaskle]

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

[Mark McLeod]

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.

[Ether]

...

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

[rfolea]

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

I was wondering if someone was gonna post those ... Back story - during shipping between events a pair of 500lb steel sprockets were dropped right through the shipping crate and onto our robot (you can see them in the picture on the robot after we removed the crate scraps) and the cRIO took the full brunt of the force (last picture). Other than a bent connector and smashed module, the cRIO still functioned fine (in fact I still use it today for demos, tutorials and CSA duties ...). Unreal ...

I dare anyone to try that with the roboRio ... any Alpha Tester volunteers?

[Jon Stratis]

I dare anyone to try that with the roboRio ... any Alpha Tester volunteers?

FIRST has told us that they'll be asking for the control system to be returned at some point... I doubt they'll like it very much if we return a pile of scraps!

[Alan Anderson]

...during shipping between events a pair of 500lb steel sprockets were dropped right through the shipping crate and onto our robot...

I've always meant to ask -- did the drayage company put an "overweight" sticker on [what was left of] your crate?

[rfolea]

I've always meant to ask -- did the drayage company put an "overweight" sticker on [what was left of] your crate?

Actually, that's the funny part ... The Steel Sprockets smashed through the top of the crate - the rest of the crate was intact. It was a tall crate so the average person couldn't see down inside it, so it looked normal from the outside.

The only reason they knew something was wrong was they were missing two sprockets when they unloaded the truck and that the crate seemed to be a LOT heavier than when they put it on the truck!

[Team3266Spencer]

I would be curious to see how well it handles intensive vision processing.

[Tom Line]

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

Austin, can you suggest a test that would determine if there are jitter problems?

I'd guess you're talking about high-speed velocity control, but give me specifics on what caused you trouble in the past.

[AustinSchuh]

Austin, can you suggest a test that would determine if there are jitter problems?

I'd guess you're talking about high-speed velocity control, but give me specifics on what caused you trouble in the past.

Hi Tom,

Write a loop which sleeps for X msec, or runs code in a notifier at a specified frequency, and then reads the system clock and looks for how long it actually slept. Do this a large number of times and plot it. I would expect to see Gaussian noise of small magnitude if things are working right.

Yes, we had a problem with a high accuracy velocity loop. On the cRIO, I was seeing a 100 hz loop returning anywhere from 5 to 15 ms (I think it was worse, but I'll guess low). You could hear it in the loop. The state space observer made the assumption that the timestep was constant at 10 ms to simplify the math. The loop would throw the motor into full reverse occasionally on our flywheel to deal with the large apparent change in velocity. Our programmer dealt with this by registering a timer interrupt on vxworks so our code would get run every 10 system ticks, but that was a lot more work than it should have been. You would expect that "sleep" on a realtime system would sleep for the correct amount of time if the priority is right. 254 never got it working correctly with Java, and I had to detune the observer to deal with it.

Austin

[Greg McKaskle]

The link below digs into this a bit and shows the jitter of various timing mechanisms in LV. It is not safe to assume that all programming resources on a realtime OS are realtime.

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Timing%20is%20Everything.PDF

Greg McKaskle

[marccenter]

I guess one really good way to test the hardware for potential issues is to beta test the hardware and software during the 2014 season. This is not directly related to the thread, sorry, but it would seem this would be the next logical step.

It would also seem if there are few perceived advantages given to a beta hardware/software test team over the existing cRIO2 system that this should be seriously considered. It also provides an excellent way for other teams to get a chance to see the system while at district and regional events.

[Jon Stratis]

I guess one really good way to test the hardware for potential issues is to beta test the hardware and software during the 2014 season. This is not directly related to the thread, sorry, but it would seem this would be the next logical step.

It would also seem if there are few perceived advantages given to a beta hardware/software test team over the existing cRIO2 system that this should be seriously considered. It also provides an excellent way for other teams to get a chance to see the system while at district and regional events.


That would certainly be a good test for the new control system, but there are a few problems with doing so:
- The new control system provides some significant enhancements, like increased processing power and USB host/device ports
- To the best of my knowledge the new control system has not been tested with the old FMS - there may be compatibility issues running it at an event
- The new control system could introduce bugs/issues that other teams wouldn't encounter, leaving those teams running it at a disadvantage in competition

That said, FIRST is doing a lot to test it. We've been asked to implement the new control system on our 2013 robot, and all the Alpha Test teams will be getting together in NH this fall for a weekend "event-like" testing. I imagine this testing would be similar to what they did for the communications issues last year, except obviously with a different focus. Regardless, we'll be running the control system on the FMS it's meant to be run on in a competition scenario to try and find issues.

We're also expected to bring the new control system with us to events January-April to help expose other teams to it. Since it won't be on our 2014 robot, it will be available for other teams to look at and ask questions about the entire competition, instead of being unavailable when the robot is on the field.

[Ether]

It would also seem if there are few perceived advantages given to a beta hardware/software test team over the existing cRIO2 system that this should be seriously considered.

What kind of serious consideration did you have in mind?

[Tom Line]

The link below digs into this a bit and shows the jitter of various timing mechanisms in LV. It is not safe to assume that all programming resources on a realtime OS are realtime.

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Timing%20is%20Everything.PDF

Greg McKaskle

I have an email in to Mark asking for the LabVIEW code he utilized for those measurements. With any luck he'll have it laying around and we'll be able to test the new system in the same manner. Lacking that, we'll write a new one and test the cRIO and rRIO.

[Ether]

The link below digs into this a bit and shows the jitter of various timing mechanisms in LV. It is not safe to assume that all programming resources on a realtime OS are realtime.

http://team358.org/files/programming/ControlSystem2009-/LabVIEW/Timing%20is%20Everything.PDF

Greg McKaskle

FWIW. I'm linking this post because it mentions Timed loops in the section about multi cores.

http://www.chiefdelphi.com/forums/showpost.php?p=1287550&postcount=172

Follow the thread for jhersh's response.

[Jon Stratis]

For those who are wondering, we had an un-boxing today!

[Tom Line]

For those who are wondering, we had an un-boxing today!

You beat us to it, darn you!

I was heartened to see the USB wireless adapter when I opened the kit. I look forward to checking boot up times.

For anyone wondering, this IS truly alpha. No covering on the PDB or roborio, and we're still waiting on cables to ship.

We don't even have instructions on how to plug it all together :D

I loved the lablemaker labels on the solenoid and relay modules.

Did you get a deck inside the box too? Plus the cup? And what type of shipping box did yours come in?

Team 1718's Alpha site is up and running, and we're starting to post pictures, measurements and weights as well:
http://www.fightingpi.org/Resources/Controls/Alpha/Alpha.shtml

[Jon Stratis]

Yes, we got the deck and cup, and it came in an identical box as yours, I just posted what I figured everyone would want to see first :). Unfortunately, we haven't had time to do more than take pictures... Last night we were meeting for other reasons (we had a local team over for a seminar, and inboxed it in the last few minutes while waiting for parents to show up. I can't wait until our Saturday meeting to start playing!

[Ether]

For those who are wondering, we had an un-boxing today!

Love the butcher-block wood table top. Is that maple?

[Jon Stratis]

Love the butcher-block wood table top. Is that maple?




I'm not sure about that one. It's one of the workbenches the school got for the new space. They're primarily used for classroom stuff (physics and engineering). The team has a couple of other tables it'll normally use to build the robot, but we can spill over onto these when needed, and the other tables were full last night :)

[Jefferson]

For anyone wondering, this IS truly alpha. No covering on the PDB or roborio, and we're still waiting on cables to ship.

We don't even have instructions on how to plug it all together :D



Yep, thin instructions with a high chance of failure, too much fun! We bravely,carefully (foolishly?) plugged it all up and got it running Monday night. There are good instructions posted now.

You can make the needed serial cable. We sacrificed an old db9 cable and soldered on the female PWM. You can watch the boot sequence from there. You can also FTP and SSH into it to poke around more.

I had my first Labview experience Wednesday, just trying to get something going on it. :D

[Jon Stratis]

Well, we started getting it setup today. The programming team got everything installed on a couple of computers, taking 15-20 mins each, roughly. Not too bad for a full install.

On the electrical side of things, we started putting together all the wires and such we'll need for a full board to control last year's robot. We're going to make a whole new board so we can put them side by side for comparison pictures. One of the students started bending up a new board (Polycarb, should be the same dimensions as the old board). And we're setting up the layout to be very similar to the old board. Now, just waiting on a delivery from AndyMark with some new speed controllers (which we would have gotten for the new robot in January anyways, now we have them a little early!)...

We also found out that, in true Alpha Test fashion, they aren't quite ready for us to get Java code deployed - hopefully they'll get something to us in the next week or two so our programming team can get something working and deployed. In the mean time, we'll get everything onto the board for the MRI (Minnesota Regional Invitational) event next weekend! Who knows, I might even try to convince the programming team to do something in Labview before then :p

In the attached picture, you can see things starting to come together. The yellow/green pair wire is for CAN. You can see it going from the RoboRio (not actually attached there) to the PCM (Pneumatics Control Module), and then from there to the PDB (not actually attached here). Having the CAN on the PDB on that side of the board does make for a long wire run down there with this layout... something to keep in mind for our layout in 2015.

One thing that was insanely nice with our work today - the new attachment terminals that are being used! They're used for CAN, power to the PCM and VRM (Voltage Regulator Module), and all other connections into the PCM and VRM. No more messing around with a tiny screw driver, having to get it placed just right to open the terminal, then having to hold the screwdriver, device, AND wire at the same time to get everything in place. Now you simply push down on a button right next to the terminal and slide the wire in. It really couldn't be easier. Removing the wires is just as easy, too!

[cgmv123]

Well, we started getting it setup today. The programming team got everything installed on a couple of computers, taking 15-20 mins each, roughly. Not too bad for a full install.

On the electrical side of things, we started putting together all the wires and such we'll need for a full board to control last year's robot. We're going to make a whole new board so we can put them side by side for comparison pictures. One of the students started bending up a new board (Polycarb, should be the same dimensions as the old board). And we're setting up the layout to be very similar to the old board. Now, just waiting on a delivery from AndyMark with some new speed controllers (which we would have gotten for the new robot in January anyways, now we have them a little early!)...

We also found out that, in true Alpha Test fashion, they aren't quite ready for us to get Java code deployed - hopefully they'll get something to us in the next week or two so our programming team can get something working and deployed. In the mean time, we'll get everything onto the board for the MRI (Minnesota Regional Invitational) event next weekend! Who knows, I might even try to convince the programming team to do something in Labview before then :p

In the attached picture, you can see things starting to come together. The yellow/green pair wire is for CAN. You can see it going from the RoboRio (not actually attached there) to the PCM (Pneumatics Control Module), and then from there to the PDB (not actually attached here). Having the CAN on the PDB on that side of the board does make for a long wire run down there with this layout... something to keep in mind for our layout in 2015.

One thing that was insanely nice with our work today - the new attachment terminals that are being used! They're used for CAN, power to the PCM and VRM (Voltage Regulator Module), and all other connections into the PCM and VRM. No more messing around with a tiny screw driver, having to get it placed just right to open the terminal, then having to hold the screwdriver, device, AND wire at the same time to get everything in place. Now you simply push down on a button right next to the terminal and slide the wire in. It really couldn't be easier. Removing the wires is just as easy, too!

It looks really clean, though once the speed controllers and associated wiring get added it will get a bit more cluttered. :)

Is there any particular reason as to why the main breaker is on the negative side of the Anderson leads? That seems a bit weird and could make it easier for current to bypass the breaker.

[Tom Line]

It looks really clean, though once the speed controllers and associated wiring get added it will get a bit more cluttered. :)

Is there any particular reason as to why the main breaker is on the negative side of the Anderson leads? That seems a bit weird and could make it easier for current to bypass the breaker.

I didn't see any direction on how to wire the PD panel.

There's a couple headaches around the PD board and the power lugs. To start, the positive power lead is VERY VERY close to the CAN board. Like 1/16" close. We actually put a lock washer under it to raise it so it's 1/8th away.

Next, one of the members already boogered up one of the power lugs. The mounting lugs are aluminum, and it took 2 seconds for it to be cross-threaded. We've fixed it, but I'd love to see those lugs get changed into something more durable. On the plus side, the power lug fasteners are m6 machine screws, so there's no messing with box end wrenches or crescent wrenches on the power distribution panel.

Note that some of the names are changing. The PD Board is now the PD panel. There are a couple other terminology changes.

The push-to lock connectors are FANTASTIC. You can put components next to the modules that have them, because you don't need to put a lever tool in and mess around with them. No PWM crimping is a welcome change.

We'll be doing a major web page update tonight including more pictures and specs on some of the components.

I haven't seen anything in the documentation showing the breaker must be on the negative side, but I admittedly haven't dug into it. Working Saturdays sucks....

[Alan Anderson]

One thing that was insanely nice with our work today - the new attachment terminals that are being used! ...Now you simply push down on a button right next to the terminal and slide the wire in. It really couldn't be easier. Removing the wires is just as easy, too!

It actually could be easier. You could push the wire in without having to push the button next to it. And guess what? It actually is that easy (if you're using wire appropriate for the terminal).

[Michael Hill]

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.

I'll third this. Also, what is the voltage drop-out? Also, do we have access to the FPGA at all?

[yash101]

To make sure that I understand, are we switching control systems this year? Also, are we getting rid of the old cRIOs?

[Ether]

To make sure that I understand, are we switching control systems this year?

Post#1:

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

[Jon Stratis]

It looks really clean, though once the speed controllers and associated wiring get added it will get a bit more cluttered. :)

Is there any particular reason as to why the main breaker is on the negative side of the Anderson leads? That seems a bit weird and could make it easier for current to bypass the breaker.

Good point... I didn't notice it before. We'll get it fixed on Monday!

[Greg McKaskle]

The voltage dropout is what was specified in the RFP. I believe it differs for different components.

At this point, the FPGA is still closed to ensure safety. I'd personally love for it to be open for off season projects not involving 3HP of motors.

Greg McKaskle

[Tom Line]

Alpha Test Task 1 (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Task%20List.shtml)

Power Distribution Panel (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Power%20Distribution%20Panel.shtml)

Pneumatic Control Module (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Pneumatic%20Control%20Module.shtml)

Voltage Regulator Module (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Voltage%20Regulator%20Module.shtml)

roboRIO (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/rRIO.shtml)

Hopefully there aren't too many typos. It's late and I'm tired.

[AllenGregoryIV]

Alpha Test Task 1 (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Task%20List.shtml)

Power Distribution Panel (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Power%20Distribution%20Panel.shtml)

Pneumatic Control Module (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Pneumatic%20Control%20Module.shtml)

Voltage Regulator Module (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Voltage%20Regulator%20Module.shtml)

roboRIO (http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/rRIO.shtml)

Hopefully there aren't too many typos. It's late and I'm tired.

Thanks for the pictures, lots of good information. Can you post mounting hole sizes and the stud size for the PDP?

[Jon Stratis]

Thanks for the pictures, lots of good information. Can you post mounting hole sizes and the stud size for the PDP?

We can't be sure about mounting holes on anything yet, especially for the PDB and RoboRio. Specifically concerning the PDB, if I had to guess the mounting holes will be in the corners like in the current PDB. Since we just have the boards and no casings, however, there are no actual holes, just a corner that's missing a small part.

The studs are M6.

[AllenGregoryIV]

We can't be sure about mounting holes on anything yet, especially for the PDB and RoboRio. Specifically concerning the PDB, if I had to guess the mounting holes will be in the corners like in the current PDB. Since we just have the boards and no casings, however, there are no actual holes, just a corner that's missing a small part.

The studs are M6.

Thank You, I meant mounting hole sizes for all the parts, I should have worded that better. I know a lot of this might change but we can at least know what they are working with.

[yash101]

How can our team get a hold on one of these? I think it would help us start plamming the year and getting our control systems test board ready.

[Tom Line]

How can our team get a hold on one of these? I think it would help us start plamming the year and getting our control systems test board ready.

At this point, you can't. These systems are not for the 2014 (upcoming) season. They are for the 2015 season over a year from now. 9 teams are testing the systems for the next year. We'll probably test them until the 2015 Beta test starts in September of 2014.

[cgmv123]

Have they given you schematics or other component design files? I'll understand if they're under NDA, but they'd be interesting to study.

[Joe Ross]

Have they given you schematics or other component design files? I'll understand if they're under NDA, but they'd be interesting to study.

Schematics have not been posted. However, even if they were, they would covered by the NDA.

[Greg McKaskle]

Just so it is clear, NDAs are typically used to protect intellectual property between companies working together. But in this case, it is about keeping incomplete or preliminary information from causing confusion. The products are bare boards and are still being revved. It is a bit too early to have schematics in the wild.

Greg McKaskle

[Andy Baker]

Thank you all for posting this information and associated pictures. It is much work to be an Alpha Test team, and the rest of us appreciate your efforts.

I am sure that many people are looking forward to your tests and unveiled information. Keep it up!

Sincerely,
Andy Baker

[Mike Copioli]

To start, the positive power lead is VERY VERY close to the CAN board. Like 1/16" close. We actually put a lock washer under it to raise it so it's 1/8th away.

This will not be an issue when the PDP is inside it's enclosure. There is plenty of plastic between the two.


Next, one of the members already boogered up one of the power lugs. The mounting lugs are aluminum, and it took 2 seconds for it to be cross-threaded.

The Lugs are actually made of a copper alloy that is plated with tin. The material used is chosen for it's conductive properties (100-200 micro Ohms). However it is strong enough to apply the torque required to provide a reliable connection. As with any screw fastener the possibility of cross threading exists. We will just need to address this in the user manual.


The push-to lock connectors are FANTASTIC. You can put components next to the modules that have them, because you don't need to put a lever tool in and mess around with them. No PWM crimping is a welcome change.

I am glad to hear you like these. They are very convenient.

[protoserge]

We're a little late to the party... We are also a LabVIEW alpha test team.

We have a working setup with a window motor and AM9012 at present. Hopefully we will have it integrated into the robot by the middle of this week.

We will be blogging about our progress on our team's website. Here is the first installment (http://robobees.org/?subtopic=teamblog&action=article&id=40). Very high resolution photos are linked for those curious.

Hopefully, we will have a video overview up tomorrow evening that goes over each component and the noted features.

Here is our current test board:

http://farm8.staticflickr.com/7401/10262810035_a8a07229d6.jpg (http://www.flickr.com/photos/robobees836/10262810035/)
Alpha Test Hardware (http://www.flickr.com/photos/robobees836/10262810035/) by FRC Team 836, The RoboBees (http://www.flickr.com/people/robobees836/), on Flickr

[protoserge]

Reported spammer.

[PayneTrain]

Thanks for all of the alpha teams who post pictures of all of the cool toys NI and FIRST on top of going through all of the tests so everyone else's stuff doesn't catch on fire when it shows up in a year.

[Bald & Bearded]

Thanks to all the testers out there for the great information.

One thing I noted in the NI specs that is significantly different about the new system from the CRIO. In the NI specs it states that the OS is "Linux with Real-time extensions". This is a major change from VXWorks on the cRIO.
I know from experience that the timing and task characteristics (which a prior poster asked about) will be different.

I would be very interested to see how this affects threading, CPU utilization and associated behavior.

Like others I am concerned about the USB based network connection and it's throughput. In general, I just don't like USB for highthroughput applications like networking.

Also, how will this new setup affect those who use separate laptops or single-board computers for vision processing on the robot? I did not see on the USB wireless box if there were additional ports. I see one on the new control system. But if I am using a network based camera and a separate processing CPU would I be allowed to add a hub/switch to interface them? Suppose I wanted to have my vision processor send stuff to the DS like we did with the Kinect last year (or even for debugging)? I suspect many of these questions will have to wait until 2015 rules. But at the same time a lot
answers to these questions would certainly affect pre-2015 planning and training.

[Greg McKaskle]

The OS is not just for FRC, but will be used in industrial applications as well. NI has spent several years working with the linux community to characterize and improve jitter and determinism. You are correct to be skeptical, but on the positive side, the number of devices and services that can be run on the linux device is an order of magnitude better, and the jitter measurements look quite good.

The device has an ethernet port as well as two USB host ports. Both are technically expandable via hubs. I'll let you place odds on whether FIRST rules will have them open or closed. In addition, there is SPI, I2C, and serial -- all useful for communicating to devices.

Greg McKaskle

[protoserge]

For those of you interested, here is a quick hands-on of the system:

http://youtu.be/JP5bWXX0V2w

[Jon Stratis]

It's been a while, and I think the community is due for an update!

All the teams were out in NH this past weekend for an Alpha Test Weekend. Basically, FIRST set up a field, brought our robots and a few members from each team in, and we spent all day Saturday and half the day Sunday working. All three languages are mostly working (some features haven't been finished yet... after all, this is still an Alpha! We'll be testing those features as they get finished), all 9 robots were on the field competing, and we ran 6-robot matches. We had close shooting, full court shooting, and some level-1 climbs. All in all, just about everything you could hope for from the control system over a year before we'll all really be using it!

For our robot in particular, we came into the weekend with C++, and had no issues connecting to the field and driving around through every match we were in on Saturday. We went back to the hotel room Saturday night with new Java libraries, worked on it a bit, and came back Sunday. By lunch on Sunday we ran through a full match with no issues at all. So, two languages working basically identically in the same weekend on the new control system. It can't get much better than that!

For those of you wondering, we're still working on getting climbing working again. As you can imagine (if you've seen our videos), it's a fairly complicated process in the code, and requires quite a bit of fine tuning. We found that the potentiometer inputs we have for feedback are returning a different range of values (but still consistent, repeatable, logical values), and we've had to go through working on getting everything set up again. We have 3 positions working without any issue (our "driving" position, our "ready to climb" position where we can grab the first bar, and our "pull up" position to get us up to the first bar), so our problems are definitely not an issue with the control system... it's just getting our completely rewritten code all working like it should be.

We plan to continue developing both Java and C++, since we have them both at exactly the same points right now.

I want to give a big shout out to everyone at FIRST, WPI, NI, and CTRE for everything they did this weekend. They were all there with us helping us fix any issues we had, taking our feedback (always with a smile!), and overall just giving us an amazing experience for the weekend. FIRST has really put together an all-star team to get us this new control system!

[yash101]

At this point, you can't. These systems are not for the 2014 (upcoming) season. They are for the 2015 season over a year from now. 9 teams are testing the systems for the next year. We'll probably test them until the 2015 Beta test starts in September of 2014.

Yeah. I know that. However, I am wondering where your team signed up for this

[ErvinI]

Yeah. I know that. However, I am wondering where your team signed up for this
From what I hear, there was no application process for alpha testing. The 9 teams were chosen by FIRST, making sure that these teams were capable of carrying out alpha testing, that there was an equal distribution of languages used, and that each one could act as a mentoring team in 2015 in their own separate regions when the new control system rolls out.

[protoserge]

Yeah. I know that. However, I am wondering where your team signed up for this

As was stated in the picture thread, you do not sign up for alpha testing. FIRST sent a query to a select group of teams asking if they would like to test the new control system. From these teams, 9 were chosen to be part of the alpha test. Our team was a LabVIEW beta test team last year. I did not check to see if the alpha test teams were all beta testers at one point.

Pay attention for a beta test announcement. Most likely, this will be announced when there is a new software version release. You can apply to be a beta team. Your team administrator and mentors should receive an email from FIRST regularly, one of which will announce beta testing.