hi guys I don’t know if you saw the new controller the NI roboRIO and we from team 1382 are thinking if the veteran teams will receive this controller or just the rookie teams
anyone have notice of that??
All teams, both veteran and rookie, will receive one of the new roboRIO’s in the 2015 KOP.
We’re excited about the roboRIO but concerned about pneumatics. Apparently they will be controlled by using a CTR CANipede http://www.crosstheroadelectronics.com/RCM.html
Does anyone know of additional information sources for the CANipede?
Will it do both 12V and 24V pneumatic solenoids?
They are not controlled by the Cross the Road Electronics CANipede. They are controlled by a new CTR product, the Pneumatics Control Module (PCM), which isn’t available yet. You can see more details in the image linked here: http://www.chiefdelphi.com/forums/showthread.php?p=1267723#post1267723
Realize this is all for the 2015 season. The 2014 season will be using the familiar components.
As an Alpha test team, I can provide a few details of the new PCM for 2015.
First, it goes on the CAN bus, and is extremely easy to hook up - the connectors are very easy to use (compared to the fairly difficult ones on the Jaguars). This also means that you can daisy-chain several of them together.
The PCM has specific ports built in for the compressor and pressure switch. I am hopeful this will eliminate problems teams have had getting the compressor working correctly.
Finally, there is a jumper on the PCM that lets you switch between 12V and 24V. This is for the whole module - if you have both 12V and 24V pneumatics, you’ll need to use two PCMs, one for 12V and the second for 24V.
Are we looking at a complete transition to the new control system in 2015? Or will there be a transition period in which teams can use either new or old systems? If not, what are people planning to do with all their obsolete cRio, etc stuff?
It’d be a maintenance/troubleshooting nightmare to permit two different control systems on the field at the same time.
And after all that expense NI/FIRST is going to to donate the new system to every team.
Not to mention the conflicting directions on how to hook everything up.
We’ll be using our old cRIOs the same way we use our old IFI controllers-running old robots for demos/practice/prototyping.
They will still be useful as programming training resources, since they use the same or similar code.
I’m pretty sure the intention is that everyone switches over for their competition robot. Honestly, I don’t know why you wouldn’t want to - the new system is smaller, weighs less, and is more powerful than the old system.
I don’t know what the final decision was, but there was a significant discussion during the Alpha Testing weekend about maintaining some sort of development capability for teams with the old system. It’s obviously very important for all of us - my team has 4 cRIO’s, and that’s an expensive pile of “junk” if we can’t continue to develop on them for training in future years.
As a Alpha Team Mentor, I can understand your concerns of moving to a “New” Control system.
Note, this isn’t the first time FIRST has done this transition. We had this transistion from the old IFI system to the NI cRIO 8-slot 6 years ago.
That was a drastic change, but allowed for more creativity. The IFI system was slower, used RF, like an RC car, instead of 802.11 for communications, could only use an alalog camera like the cmu2 camera. There were two ways to program it, a graphical language or Ansi C (not natively object oriented, like we have now with C++/Java etc.). It had a microchip processor in it, so you had to use the MPLAB IDE for text based programming. The Crio opened up many different languages, and additional capabilities for teams.
Please be assured FIRST is taking every possible measure to make the transition for teams to the new RoboRio to be seamless.
This should be a welcome change, from the hardware side of things its linux, its faster, it combines the crio and digital side car in one unit, and it cheaper!
From the software side of things, the WPI libraries and Labview should have a very similar interface as to what you are acustom too now with the current cRIO.
Also, I noticed your location is in CT. My team is hosting the Groton District Event, in Groton CT on March 8th and 9th. As an Aplha testing team, I will be working on displaying the new 2015 hardware, and have it powering our 2013 robot. The idea is to let teams get to see it, touch it, and get a early introduction to the RoboRios capabilities while at the event. If you happen to drop by, please look for me if you have any additional questions.
Hope this helps,
Kevin
Missed you guys at Suffield this year, but it was probably wise of you to stay home in the snow-filled afternoon. Seeing the new system will be a great thing at Groton. I just wanted to get a jump on telling the team that they have a higher goal for funding 2015 if they want an Athena for practice AND competition. We’re using our 8-slot on our demo machine now, so the concept is not totally foreign. I “missed” the IFI era so to me it sounds a bit like the guys around the robotic cracker barrel talking about the “olden days.”
Yea we were simply not ready to compete at Suffield, although the weather implications did make staying home a bit easier.
As for the RoboRio, at least for the first year FIRST is attempting to keep the programming interface the same, so the code you write for it should be backwards compatible and run on an 8-slot and 4-slot. Their may be some port addressing differences, but that is yet to be seen. I.e DIO pin 1 on cRIO could be pin 0 on RoboRio.
This was a very important point during alpha Testing. Many teams have multiple cRIOs, and while eventually they may need to be scrapped like most teams have done with their IFI controllers, using them during off-season testing, and demo bots, and keeping the cRIOs running for the first year of the transistion is a something FIRST is trying to accomplish.
In the long run, keeping the code backwards compatiple may be easier for Labview and C++ Teams than it might be for Java Teams.
Java teams are currently restricted to JavaME which is what we run on our current cRIO. The new system will use JavaSE which has many new programming constructs. In order for the WPIJava Library to become more efficienct and make use of the additional features of JavaSE, it needs to be re-written, and some interfaces will likely need to be changed.
I don’t believe this will happen within the first year of the transistion, but I believe it will happen.
So in all, I don’t think you need to get multiple controllers off the bat, your existing cRIOs should still be helpful in off-season, and pre-season testing with minimal to no code changes, if you can live with performace differences between the two processors their might be.
Hope this help,
Kevin
This concerns me from the perspective of I’ve always viewed the DSC as a disposable pile of crap that I expect to short out and die if I look at it funny (having said that, I fully expect the bagged DSC to hear me and commit ritual suicide just to prove me right). Have the DSCs become less unstable or can I assume I’ll have to start keeping spare roboRIOs around?
Lol. Well I personally haven’t had a lot of trouble with DSC when wired properly. Most of the problems we have had early on were from our own misuse. But in recent years we have been pretty good at keeping the DSC running happy.
Any idea on what/how your current DSC is failing?
The RoboRio has a 34-pin Expansion custom electronics port that allows access to shared pins on the controller. Depending how the hardware failed you may be able to recover using this port, instead of swapping out a whole new controller.
I would look at it this way. In the current system if you have a DSC problem, it could be power to the DSC, the CRIO, the Module Cards, the cable from the card to the DSC, or problems on the DSC itself, or the thing plugged into it. Lets assume code and mechanical is correct.
Any of of these issues makes troubleshooting a longer/harder task. The new RoboRio, it is either a controller problem, or not. You don’t need to worry about cards, power not getting to the DSC, or the cable from the module to the DSC being frayed, not seated correctly, etc. It should be easier for a lot of teams, and when you think of it from that perspective and FIRST trying to reduce the entrance learning curve for new teams, this was a smart move.
While I can not speak on the specifics of how the new controller is designed, whether or not you need to swap out a RoboRio because the rails failed depends on how they failed. If you broke pins off the board, you could move to another pin, if you fried a register that controls data on the bus, and that register is also used for the expansion slot, and all other pins are used, then you may need to swap out a Rio.
Although I am not sure how one could do that, I am sure in FRC everything is possible. And planning for the worst is always advisable. At every competition, we have a spare 4-slot cRIO ready to drop in to our bot at a moments notice, incase we happen to fry it. And I would advise my team to do the same next year with the RoboRio. Fortunately, we havent had that happen yet. <>
Hope this helps,
Kevin
During the RoboRIO Q/A at NI Week, it was stated that the inputs and outputs would be well protected against reverse polarity, shorts, and ESD. I suspect that NI has more experience designing robust hardware then FIRST (who designed the DSC) does.
The suicidal DSC wasn’t a problem with the IFI controller, and I don’t think it should be a problem with the RoboRIO.
Kevin, the latest DSC death was actually our fault. I was really more concerned that the new controller would cook as easy as the DSC does now and that’s a lot pricier. Joe’s helped calm these concerns. While we all know to be careful around electronics sometimes it doesn’t happen, something about HS students, sleep deprived mentors, and hard deadlines.
Thanks, can’t wait to chat roboRIO with you at Groton next week.
And if it makes you feel even better, we’ve been running the alpha test setup on last year’s robot now for several months without issue. And this particular setup was shipped without the plastic enclosure - it’s just the bare circuit board, mounted by standoffs at the very bottom of the robot. Given it’s exposure, we’ve been a little more careful with it than we normally are, but it seems to be durable enough.
Does the roboRIO provide a ground connection for CAN bus?
CAN bus connection
I’m concerned that a floating ground will affect stability.
What is the proper CAN wiring for the Jaguars? Wire colors have different meanings in the Jaguar docs (page 24 in this doc) where red and green and used for CAN high and low.
Put another way, is there documentation for wiring CAN into the roboRIO?
As the entire electrical system is isolated and powered from the PDP, I would imagine the entire system has a common ground, which should help your stability concerns. From that respect, this isn’t a very complicated system.
The RoboRio, PCM, and PDP all have appropriate CAN interface - 2 ports on the RoboRio, clearly labeled High/Low, 4 ports on both the PCM and PDP to facilitate daisy-chaining, again clearly labeled High/Low. Honestly, it’s something you could give to a freshman with no knowledge and 9 times out of 10 have it wired up correctly. It’s just that easy.
The recommendation for CAN cabling is twisted pair but not shielded. CAN is a differential bus, so neither signal is typically grounded, and if you were to ground something, it would be the shield that would surround both signal wires.
From the beta images I’ve seen thus far, most teams aren’t even using twisted wires, just two adjacent wires. There will be documentation for CAN wiring. I believe that beta teams have it now and like everything else, it is being scrutinized.
Greg McKaskle