View Full Version : CRIO-FRCIII
Is there anywhere to ask questions about the new CRIO for the 2015 season? I meant to ask about it at St. Louis last year but didn't have the time.
Also, when's the earliest time to get our hands on it? I remember hearing fall of this year.
The FRC NI community page would probably be the way to go: https://decibel.ni.com/content/community/academic/student_competitions/frc?view=discussions\
Some information about the roboRIO is also in the documents section of the same page: https://decibel.ni.com/content/docs/DOC-30419
geomapguy
23-03-2014, 22:04
Is there anywhere to ask questions about the new CRIO for the 2015 season? I meant to ask about it at St. Louis last year but didn't have the time.
Also, when's the earliest time to get our hands on it? I remember hearing fall of this year.
https://decibel.ni.com/content/docs/DOC-30419
alex.lew
23-03-2014, 22:27
Also, when's the earliest time to get our hands on it? I remember hearing fall of this year.http://www.usfirst.org/roboticsprograms/frc/blog-2015-control-system-alpha-testing
Several teams were chosen as alpha testers for the Athena/roboRIO. You can check out their team websites for a summary of results, images, etc.
http://www.usfirst.org/roboticsprograms/frc/blog-2015-control-system-alpha-testing
Several teams were chosen as alpha testers for the Athena/roboRIO. You can check out their team websites for a summary of results, images, etc.
That's a shame, I know we would have loved to alpha test (I'm assuming it was either random selection out of teams that won Delphi's Quality award or submitted applications)
Anyway, thanks for the links!
NotInControl
25-03-2014, 15:42
What is your question about the 2015 Control System. I will try to answer it as best I can.
I am part of the Alpha Test Team.
Regards,
Kevin
Jon Stratis
25-03-2014, 15:47
That's a shame, I know we would have loved to alpha test (I'm assuming it was either random selection out of teams that won Delphi's Quality award or submitted applications)
Anyway, thanks for the links!
FIRST invited 15 teams (former Beta Test teams with good records) to apply to be Alpha Test teams, then accepted 9 of them, 3 per language. If you have any specific questions, I'd be happy to help - my team is one of the Alpha Test teams, and we've had ours working in both Java and C++ for several months now.
Well, for either of you I suppose
How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
Is it easy to upgrade / switch JRE's on the niRIO?
(not familiar with C++ on cRIO but our team is considering C++ for 2015) I've heard most about the upgrade from Java ME to SE but is it also being updated to C++11? (or does it already have C++11)
How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
What are the deploy times?
Jefferson
25-03-2014, 20:52
Well, for either of you I suppose
How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
Is it easy to upgrade / switch JRE's on the niRIO?
(not familiar with C++ on cRIO but our team is considering C++ for 2015) I've heard most about the upgrade from Java ME to SE but is it also being updated to C++11? (or does it already have C++11)
How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
What are the deploy times?
We are a C++ team, so I'll take a stab at some of your questions and leave the rest for others.
They are switching IDEs to Eclipse (as is C++), but the libraries are staying much the same. Somebody else will need to elaborate on any differences in the API.
Don't know
Windriver does not use C++11. It's stuck somewhere years back in C++ versions. We are using the latest version of Eclipse and C++11
Libraries aren't expected to change much, but there may be some differences for Java. Somebody chime in here.
Deploy times are pretty quick. It executes script in the command line in Eclipse that ftps the program to the robot restarts the program, no more restarting the OS on every deploy. The whole process takes around 30sec.
I have a few questions.
How long does it take for the whole thing to turn on, including the radio?
Is it still WPIlib for Java?
What's the radio look like? Are we still using the d-links?
How low does the voltage have to go to brown out the radio/controller?
Deploy times are pretty quick. It executes script in the command line in Eclipse that ftps the program to the robot restarts the program, no more restarting the OS on every deploy. The whole process takes around 30sec.
hm. Faster, not by much
How long does it take for the whole thing to turn on, including the radio?
based on his timings, the bootup time is about the same
Is it still WPIlib for Java?
yes
What's the radio look like? Are we still using the d-links?
i believe so
How good is the support for standard Linux programs, do you think it might be able to run ROS (http://ros.org)?
theawesome1730
25-03-2014, 21:18
I realize the roboRIO has a shorter profile but a larger foot print and now must have external modules for solenoid breakouts and additional analog and digital inputs. Does weight with all the extra components end up similar to the cRIO or is it lighter weight (as we would hope it to be)?
xXhunter47Xx
25-03-2014, 21:35
i believe so
I thought the roboRIO was the radio as well? That's what I saw at the display model at San Diego or at least what I thought I saw.
Do any of you know what the Solenoid Module will be? I've been told it's a CANipede RCM but it looks a bit old to be used in conjuncture with the new hardware.
Tom Line
25-03-2014, 22:09
Here is an overview of the new 2015 control system:
http://www.fightingpi.org/Resources/Controls/Alpha/Alpha.shtml
Arohowk, please don't guess at answers. We are currently not using dLinks. We are using USB radios whose drivers reside on the RoboRIO and who don't require a boot-up like the current radio systems do.
The system will be on display on our 2013 Ultimate Ascent robot this weekend Waterford, and again at the State Championship. In addition, National Instruments reps are planning on coming up to do a LabVIEW seminar and an hour long seminar on the new control system at the State Championships Thursday morning as a part of our '1718 Presents' seminar series. We'll be releasing more info as States get closer.
Once the competition season ends we'll restart our Alpha testing and begin updating the web page with more information.
Please keep in mind the software is still VERY much in the development stage. When we met late last year, some of the languages still weren't completely functional. Take everything with a very large grain of salt: the same folks developing the Alpha hardware are also supporting the current FRC season. Don't expect much progress for a while.
Jefferson
25-03-2014, 22:13
Whoa. Gunna try to keep up here.
Those times are from my recollection. Please don't quote me on them just yet.
They are trying to get a USB WiFi dongle working and signs are pretty positive right now. That would mean no more DLink.
The Pneumatics Control Module (PCM) is produced by Cross the Road electronics (makers of the CANipede) communicating via CAN with the roboRio.
Even with the PCM and a breakout for the expansion slot (called the MXP) it should still weigh considerably less than the cRIO. I haven't weighed everything, but it's not close to the chunk of metal the cRIO is.
The roboRIO reboots somewhere below 5V (don't remember exactly) but there may be loss of functionality prior to that. I was just watching for a reboot.
alex.lew
25-03-2014, 22:18
In addition, National Instruments reps are planning on coming up to do a LabVIEW seminar and an hour long seminar on the new control system at the State Championships Thursday morning as a part of our '1718 Presents' seminar series.
Will something similar be offered at Worlds?
BitTwiddler
25-03-2014, 22:20
Whoa. Gunna try to keep up here.
They are trying to get a USB WiFi dongle working and signs are pretty positive right now. That would mean no more DLink.
Hmm. That would seem to imply that the video camera/server is going to have to be plugged into the new CRIO Ethernet port to get to the network. On the other hand I won't miss having to find a good place to mount the DLink.
Jon Stratis
25-03-2014, 22:20
Well, for either of you I suppose
How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
Is it easy to upgrade / switch JRE's on the niRIO?
(not familiar with C++ on cRIO but our team is considering C++ for 2015) I've heard most about the upgrade from Java ME to SE but is it also being updated to C++11? (or does it already have C++11)
How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
What are the deploy times?
1. The Java API is, at this point, the same as the old API. Then again, it's not even all fully functional yet - It's a better idea to use what they know to get things working perfectly before looking to refactor just for the sake of refactoring.
2. You'll be using whatever JRE they decide is FRC legal. The RobotRio is running a RTLinux distro, which makes it very easy to play with.
3. I'm not sure about the C++ version
4. Just load up the FRC plugin for Eclipse, and go to town... personally, I like Eclipse a lot better than Netbeans.
5. Deploy seems a lot quicker - we were going from clicking to driving in under 30 seconds.
I have a few questions.
How long does it take for the whole thing to turn on, including the radio?
Is it still WPIlib for Java?
What's the radio look like? Are we still using the d-links?
How low does the voltage have to go to brown out the radio/controller?
1. We didn't time it, but it seems quicker than the current cRIO.
2. Yes, WPI is still heavily involved, and we're using WPIlib.
3. Currently, it's a USB dongle. The final radio hasn't been decided on yet, and last I heard FIRST was looking at a number of options, including the dongle. Nice point for the dongle: No external power, which means no radio resetting due to power issues!
I realize the roboRIO has a shorter profile but a larger foot print and now must have external modules for solenoid breakouts and additional analog and digital inputs. Does weight with all the extra components end up similar to the cRIO or is it lighter weight (as we would hope it to be)?
Overall it weighs less. The modules are all small, simple plastic boxes with nice connectors, very light weight.
I thought the roboRIO was the radio as well? That's what I saw at the display model at San Diego or at least what I thought I saw.
Do any of you know what the Solenoid Module will be? I've been told it's a CANipede RCM but it looks a bit old to be used in conjuncture with the new hardware.
It is not the CANipede. It's a new module developed by CTRE. It connects to the RoboRio through CAN, and provides:
- Solenoid outputs
- a jumper to switch between 12 and 24V (with an internal boost, you only need to power it from 12V)
- A pressure switch input
- A compressor output
Tom Line
25-03-2014, 23:09
Will something similar be offered at Worlds?
No idea: we just arrange the MI State stuff. We tried to have the NI guys come up last year to the Michigan State Champs but they had some last minute things come up. This year we're lucky enough to have them planning on attending.
SpaceOsc
26-03-2014, 00:26
Some Pics from 294s 2015 control system at the LA regional.
https://www.dropbox.com/s/bmwg6yt5rmwxovn/2014-03-21%2009.49.36.jpg
https://www.dropbox.com/s/trsrhugbt8a6okp/2014-03-21%2009.49.41.jpg
https://www.dropbox.com/s/otcs2ocm0kdiuhq/2014-03-21%2009.50.09.jpg
For CAN Jaguars, how easy are they to implement into the new system, or has there been no testing done with that yet?
Peter Johnson
26-03-2014, 01:14
For CAN Jaguars, how easy are they to implement into the new system, or has there been no testing done with that yet?
We have them working natively in LabView on our 2013 test robot, integrated with the rest of the CAN bus (pneumatics module and new PDB). As of this writing we don't have them working with C++ yet but that is planned. If you look carefully at SpaceOsc's pictures you can see the CAN run from the roboRio to our first Jaguar, and from the last Jaguar to the pneumatics module (where it then goes over two twisted wires to connect to the new PDB and terminate there. Took a little finesseing of the 4P4C wires to plug into the new CAN connectors (which are push-in) but works fine.
Peter Johnson
26-03-2014, 01:38
How good is the support for standard Linux programs, do you think it might be able to run ROS (http://ros.org)?
The most recent image I've tested is an older Angstrom distribution. In particular, it uses an older libc6 (2.11), which makes it a little difficult to use the most recent packages (many of which require 2.12), but I have successfully installed gdb, gcc, python and other packages with careful use of opkg install --nodeps. I have not tried installing ROS in particular, but there's no fundamental reason it can't be made to work even if the out-of-the-box packages don't.
For example, here's a tutorial on NI's website that installs PostgreSQL and uses it with LabVIEW on the Linux platform: https://decibel.ni.com/content/docs/DOC-30308
Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?
Tom Line
26-03-2014, 07:46
Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?
We haven't heard any solid cost numbers. They're projecting it to cost well below the current system.
Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?
We haven't heard any solid cost numbers. They're projecting it to cost well below the current system.
Also, every team, rookie and veteran, gets a roboRIO (and I'd assume most of the other control system components) for free in the 2015 KOP.
Here is an overview of the new 2015 control system:
http://www.fightingpi.org/Resources/Controls/Alpha/Alpha.shtml
Arohowk, please don't guess at answers. We are currently not using dLinks. We are using USB radios whose drivers reside on the RoboRIO and who don't require a boot-up like the current radio systems do.
The system will be on display on our 2013 Ultimate Ascent robot this weekend Waterford, and again at the State Championship. In addition, National Instruments reps are planning on coming up to do a LabVIEW seminar and an hour long seminar on the new control system at the State Championships Thursday morning as a part of our '1718 Presents' seminar series. We'll be releasing more info as States get closer.
Once the competition season ends we'll restart our Alpha testing and begin updating the web page with more information.
Please keep in mind the software is still VERY much in the development stage. When we met late last year, some of the languages still weren't completely functional. Take everything with a very large grain of salt: the same folks developing the Alpha hardware are also supporting the current FRC season. Don't expect much progress for a while.
Yeah. I was wondering what happened to those planned ASUS sticks.
So with this new USB stick, how do you get ethernet connections throughout the robot? Before there were 4 ports off the bridge, but now I don't know if there is a single one!
What is the range of the radio? Is it greater or lesser? I am wondering whether the switch to a USB dongle has any big significance other than a smaller footprint.
How robust is the new radio? Most USB sticks aren't very strong against sudden jerks and may end up randomly breaking!
Jon Stratis
26-03-2014, 11:58
Yeah. I was wondering what happened to those planned ASUS sticks.
So with this new USB stick, how do you get ethernet connections throughout the robot? Before there were 4 ports off the bridge, but now I don't know if there is a single one!
What is the range of the radio? Is it greater or lesser? I am wondering whether the switch to a USB dongle has any big significance other than a smaller footprint.
How robust is the new radio? Most USB sticks aren't very strong against sudden jerks and may end up randomly breaking!
There is an ethernet port on the RoboRio. If you need to, you can include an ethernet hub on the robot. The plan is to move towards USB for stuff - for example, it's a lot easier to obtain cheap, good performing USB cameras than it is to get an ethernet one.
The range of the radio seems adequate - we haven't done any specific range testing, but it covers our build space and the entire field FIRST had set up during the Alpha Test weekend.
The radio is a typical USB dongle. We connected it through a USB extension cord, which let us attach the dongle with velcro to the same place we had the dlink. Since it's so lightweight, even with a hard hit to the robot there's really no force on the dongle itself. I don't recommend sticking it straight into the RoboRio and having it buried inside the robot!
There is an ethernet port on the RoboRio. If you need to, you can include an ethernet hub on the robot. The plan is to move towards USB for stuff - for example, it's a lot easier to obtain cheap, good performing USB cameras than it is to get an ethernet one.
The range of the radio seems adequate - we haven't done any specific range testing, but it covers our build space and the entire field FIRST had set up during the Alpha Test weekend.
The radio is a typical USB dongle. We connected it through a USB extension cord, which let us attach the dongle with velcro to the same place we had the dlink. Since it's so lightweight, even with a hard hit to the robot there's really no force on the dongle itself. I don't recommend sticking it straight into the RoboRio and having it buried inside the robot!
Thanks.
I wonder if it would be legal to have an onboard cheap ethernet switch. Next year, I want to have a node based processing system with multiple computers, running a specific portion of the code. One ethernet port will probably not be enough ;). I guess the dongle will be hard to hit my a gamepiece but I'm still kinda skeptical because the ASUS router sitting in front of me has quite a poor build quality and crashes every 15 mins. Is the antenna a single plane or multiple axes? A plane antenna would mean the robot would lose communications when it turns a bit.
I am also wondering about the build quality of the roborio. The GPIO seems to be build into the main package. Have you ever had any problems with debris getting in the case and making it behave very wierd? That was one thing that happened quite often with the Digital Sidecar!
I am just wondering but how accurate are the current sensors in the PDB? Do you ever use them as an effective debug strategy for eradicating nasty shorts?
Thanks.
I think I just spammed you with questions ;)
Jon Stratis
26-03-2014, 15:19
Thanks.
I wonder if it would be legal to have an onboard cheap ethernet switch. Next year, I want to have a node based processing system with multiple computers, running a specific portion of the code. One ethernet port will probably not be enough ;). I guess the dongle will be hard to hit my a gamepiece but I'm still kinda skeptical because the ASUS router sitting in front of me has quite a poor build quality and crashes every 15 mins. Is the antenna a single plane or multiple axes? A plane antenna would mean the robot would lose communications when it turns a bit.
I am also wondering about the build quality of the roborio. The GPIO seems to be build into the main package. Have you ever had any problems with debris getting in the case and making it behave very wierd? That was one thing that happened quite often with the Digital Sidecar!
I am just wondering but how accurate are the current sensors in the PDB? Do you ever use them as an effective debug strategy for eradicating nasty shorts?
Thanks.
I think I just spammed you with questions ;)
Obviously, we don't have a copy of next year's rules available yet, but going on this year's and past year's rules, I don't see anything wrong with having an ethernet switch - it's just a "custom circuit" on the robot.
We've been running the robot quite a bit, including some hard hits (we used it as an opponent robot for driver practice this year), and we haven't had any drop outs. I don't know how the antenna in it is configured.
You're guess is as good as mine when it comes to the RoboRio case and debris - we don't have a case on our test board! They sent us the bare circuit board with some standoffs, and that's what we've been using so far. No problems with it, but then again we haven't been doing any actual work on that robot since we put the board on - no drilling or cutting of anything, and the pan it was mounted to was brand new.
We haven't tested the current sensors on the PDB yet - That wasn't available in the library before kickoff, and I'm not sure if it's available yet (it's been a while since we've had time to look at any updates). Once the season is done with, we'll reconvene our Alpha Test group inside the team and see what new stuff we can play with in the code :)
Obviously, we don't have a copy of next year's rules available yet, but going on this year's and past year's rules, I don't see anything wrong with having an ethernet switch - it's just a "custom circuit" on the robot.
We've been running the robot quite a bit, including some hard hits (we used it as an opponent robot for driver practice this year), and we haven't had any drop outs. I don't know how the antenna in it is configured.
You're guess is as good as mine when it comes to the RoboRio case and debris - we don't have a case on our test board! They sent us the bare circuit board with some standoffs, and that's what we've been using so far. No problems with it, but then again we haven't been doing any actual work on that robot since we put the board on - no drilling or cutting of anything, and the pan it was mounted to was brand new.
We haven't tested the current sensors on the PDB yet - That wasn't available in the library before kickoff, and I'm not sure if it's available yet (it's been a while since we've had time to look at any updates). Once the season is done with, we'll reconvene our Alpha Test group inside the team and see what new stuff we can play with in the code :)
Nice! I can't wait till I can get my hands on one of them next year :D ;). I am pretty sure it won't be in the WPILib, at least as of now, so you may need to write some C or Assembler code, depending on how the low level peripherals are written on the cRIO. Since you don't have that info, don't worry about it. It may be a hassle to get until next year ;)
Jefferson
26-03-2014, 16:47
I am pretty sure it won't be in the WPILib, at least as of now, so you may need to write some C or Assembler code, depending on how the low level peripherals are written on the cRIO. Since you don't have that info, don't worry about it. It may be a hassle to get until next year ;)
I think you mean the current sensors on the PDP by "it", right? We had a version of current readout somewhat working last fall with the CTRE guys, so I'm sure there will be something in WPILib to pole those current values.
I think you mean the current sensors on the PDP by "it", right? We had a version of current readout somewhat working last fall with the CTRE guys, so I'm sure there will be something in WPILib to pole those current values.
That's exactly what I was looking for! Thanks! ;)
NotInControl
26-03-2014, 22:06
Looks like a lot of conversation has already been made with regards to these questions. I will take a stab at answering each. Please read the disclaimer to these answers at the bottom of this post.
Well, for either of you I suppose
How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
There are two parts to this question, the API part, which is your interface, and what is changing on the backend of WPI
Lib. As of right now, as stated by NI the roborio will run the JavaSE Embedded JVM. This is based off of JavaSE7. The WPILibrary is currently written using JavaME as that is what runs on the current cRIO. WPI plans to upgrade the backend WPILibJ to take advantage of new features of the Java7 language such as genereics, auto unboxing, etc. HOWEVER, this is not likely to be implemented for the first year. I believe FIRST wants to have the transisiton as seemless as possible, and part of that is to keep the library the way it is for now.
As for the API, in either event, WPI lib will try it's hardest to keep the interface the same irrespective of weather or not the backend if based on JavaME or JavaSE.
Note, this does not affect your ability to use the features of JavaSE in code that does not depend on WPILib calls. In other words, you will be able to take full advantage of JavaSE in the code you write, even if WPILib is not re-written to support the new JVM.
One thing that might change out of the box is hardware indexing. Right now your hardware pins are 1 based in code (starting from 1)... there were talkins of changing this to be zero based, (1st pin will be (pin 0 in code), however it is not clear yet which way the WPI team will go on this one.
Is it easy to upgrade / switch JRE's on the niRIO?
The RoboRio is an ARM based processor running a custom version of linux made by NI. NI Linux Real time. Obviously we do not have the rules for next year, but I would assume the JRE would be set. But efen if it isn't, as long as the JRE supports the ARM processor in the RoboRio, and its other hardware like memory I don't see why it would not work. As for upgrading, it would be a similar processes as upgrading any package on any other version of linux. NI Realtime has a full linux shell.
(not familiar with C++ on cRIO but our team is considering C++ for 2015) I've heard most about the upgrade from Java ME to SE but is it also being updated to C++11? (or does it already have C++11)
These questions are circumstantial. What we are running now, may not be what is released in 2015. The team is still in Alpha testing and are trying to see what packages are to be used to offer the most stable system overall. Right now my roborio has libc6 on it. As the dev team tries new things software versions can go up or down. In any event, wheather it is c++11 or not, that should not be a reason to no go the C++ route.
How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
Should be very easy with few modifications. The WPI lib team is working to keep the API the same as best as possible. Direct compatibility may not be possible (think about module numbers when we first got the cRIOII vs the old 8-slot), but large portions of code will definetly be able to be reused.
What are the deploy times?
FAST. File transfer the cross-compiled binary from your computer to the roborio and then execute it. No restart required. (The way it should be!)
I have a few questions.
How long does it take for the whole thing to turn on, including the radio?
The current radio we tested uses the USB port for power. I have not done concrete timing tests, but based on my early observations the full system was up in 20-40 seconds. I can do proper timing tests at a later time and provide a more acurate answer later.
Is it still WPIlib for Java?
Yes, WPI is the developer for the Java and C++ libraries as they have been in previous years.
What's the radio look like? Are we still using the d-links?
The radio we have been using thus far are ASUS N-53. Wheather this is what will be rolled out with the final system is unclear at the moment. It is a USB wifi dongle and supports softAP mode (think wifi theter on your mobile device) as well as regular client mode. This hardware is not set in stone.
How low does the voltage have to go to brown out the radio/controller?
The roborio has a specified voltage input from 6.8V to 16V DC with a staged brown out of 4.5V to 6.8VDC I have not done brown out test yet, but will do after this season is over.
How good is the support for standard Linux programs, do you think it might be able to run ROS (http://ros.org)?
I don't know first hand. The roborio is linux based on a dual Arm Cortex 9, if you can compile it for that processor and memory constraints of the roborio, I do not see why it won't run. There is a full linux shell and you can use opkg to get additional packages on the rio.
I realize the roboRIO has a shorter profile but a larger foot print and now must have external modules for solenoid breakouts and additional analog and digital inputs. Does weight with all the extra components end up similar to the cRIO or is it lighter weight (as we would hope it to be)?
I can give you a specific number later. I do not know at the moment, my inclination is that the weight is less. However, even if I measure the weight it will not be accurate. WE were given development hardware, the PD board and rio have no housing, they are just the PCB, the other modules had cases that were 3D printed. I can not say how much each of these items will weight once official casings are added to the mix. I assume what we have are just temporary to support our dev testing.
I thought the roboRIO was the radio as well? That's what I saw at the display model at San Diego or at least what I thought I saw.
Do any of you know what the Solenoid Module will be? I've been told it's a CANipede RCM but it looks a bit old to be used in conjuncture with the new hardware.
The roborio is not the radio as well. IT needs a radio device. Right now we are using a dongle provided as a candiate to provide that function (Asus N-53) not sure if this will be the final deviced used, but a device is needed.
Solenoids are not CANipede, they are a new product line from cross the road electronics, the Pneumatics Control Module (PCM) and Power Distribution Panel (PDP) have a can protocol built in.
If you only have a small number of actuators, nothing stops you from using the 4 relays onboard the cRIO for pneumatics. If you want more, then you must venture out and use the PCM. The PCM also takes in the compressor and DIO switch directly, so they do not need separate power or io from the roborio.
Hmm. That would seem to imply that the video camera/server is going to have to be plugged into the new CRIO Ethernet port to get to the network. On the other hand I won't miss having to find a good place to mount the DLink.
That is not implied at all. You are free to use any periperial device you like as long as there is a linux driver for it. USB camera, or put a ethernet switch for more ports. There are pros and cons to not having a dedicated switch on board. In all likely hood, most teams will probably be adding a switch to their robot just to have more ethernet ports. We always have at least a driverstation and programming laptop pluged in over ethernet.
Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?
We were told not to quote these products. Every team will get one in the 2015 KOP. Expect the system to be significantly less than the cRIO.
Thanks.
I wonder if it would be legal to have an onboard cheap ethernet switch. Next year, I want to have a node based processing system with multiple computers, running a specific portion of the code. One ethernet port will probably not be enough ;). I guess the dongle will be hard to hit my a gamepiece but I'm still kinda skeptical because the ASUS router sitting in front of me has quite a poor build quality and crashes every 15 mins. Is the antenna a single plane or multiple axes? A plane antenna would mean the robot would lose communications when it turns a bit.
I am also wondering about the build quality of the roborio. The GPIO seems to be build into the main package. Have you ever had any problems with debris getting in the case and making it behave very wierd? That was one thing that happened quite often with the Digital Sidecar!
I am just wondering but how accurate are the current sensors in the PDB? Do you ever use them as an effective debug strategy for eradicating nasty shorts?
Thanks.
I think I just spammed you with questions ;)
If the rules stays the same with regards to networking, nothing prevents you from adding a switch to your Robot. The dongle we are using right now is the Asus N-53, you can look up the poles of the antenna, although I assure you it is not single-poled. IF you want we can talk more about EM Waves and antenna theory.
The version of the RIO we have is not conformally coated. I am not sure if the final product will be. I plan to use the current sensors to tell if my motors are stalling or simply not driving the gearbox. That is all I really need them for. I am not sure how you can use them to detect shorts based on the they circuit they are apart of.
DISLAIMER: WE ARE IN ALPHA TEST PHASE. THE INFORMATION PROVIDED IS BASED ON WHAT WE HAVE NOW. THIS MAY VERY WELL CHANGE IN THE NEXT COMING MONTHS AS SOFTWARE AND HARDWARE DEVELOPMENT PROGRESSES. I CAN ASSURE YOU FIRST IS DOING EVERYTHING TO EASE THE TRANSISTION. FOR THOSE THAT MOVED FROM IFI TO CRIO BACK IN 2009, EXPECT A MORE SEEMLESS TRANSITION. ALL OF THE QUESTIONS REGARDING PERIPERIAL HARDWARE, AND SOFTWARE VERSIONS ARE SUBJECT TO CHANGE AS DEVELOPMENT INCREASES. IN ANY EVENT, THE 2015 CONTROL SYSTEM IS AWESOME, AND SHOULD BE A WELCOME CHANGE, DO NOT FEAR IT, OR LET INFORMATION PRESENTED DETER YOU FROM IT. WE DO NOT HAVE ALL OF THE ANSWER, BUT WILL TRY TO ANSWER THEM THE BEST WE CAN.
Hope this helps,
Kevin
Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?
We were told not to quote these products. Every team will get one in the 2015 KOP. Expect the system to be significantly less than the cRIO.
Source: https://decibel.ni.com/content/docs/DOC-30419
When can we purchase a spare roboRIO? How much will it cost?
All FRC Teams will get a roboRIO in the Kit of Parts at Kick Off 2015. Teams can purchase a spare roboRIO starting in fall 2014 for <$450 (pricing not yet finalized).
Looks like a lot of conversation has already been made with regards to these questions. I will take a stab at answering each. Please read the disclaimer to these answers at the bottom of this post.
There are two parts to this question, the API part, which is your interface, and what is changing on the backend of WPI
Lib. As of right now, as stated by NI the roborio will run the JavaSE Embedded JVM. This is based off of JavaSE7. The WPILibrary is currently written using JavaME as that is what runs on the current cRIO. WPI plans to upgrade the backend WPILibJ to take advantage of new features of the Java7 language such as genereics, auto unboxing, etc. HOWEVER, this is not likely to be implemented for the first year. I believe FIRST wants to have the transisiton as seemless as possible, and part of that is to keep the library the way it is for now.
As for the API, in either event, WPI lib will try it's hardest to keep the interface the same irrespective of weather or not the backend if based on JavaME or JavaSE.
Note, this does not affect your ability to use the features of JavaSE in code that does not depend on WPILib calls. In other words, you will be able to take full advantage of JavaSE in the code you write, even if WPILib is not re-written to support the new JVM.
One thing that might change out of the box is hardware indexing. Right now your hardware pins are 1 based in code (starting from 1)... there were talkins of changing this to be zero based, (1st pin will be (pin 0 in code), however it is not clear yet which way the WPI team will go on this one.
The RoboRio is an ARM based processor running a custom version of linux made by NI. NI Linux Real time. Obviously we do not have the rules for next year, but I would assume the JRE would be set. But efen if it isn't, as long as the JRE supports the ARM processor in the RoboRio, and its other hardware like memory I don't see why it would not work. As for upgrading, it would be a similar processes as upgrading any package on any other version of linux. NI Realtime has a full linux shell.
These questions are circumstantial. What we are running now, may not be what is released in 2015. The team is still in Alpha testing and are trying to see what packages are to be used to offer the most stable system overall. Right now my roborio has libc6 on it. As the dev team tries new things software versions can go up or down. In any event, wheather it is c++11 or not, that should not be a reason to no go the C++ route.
Should be very easy with few modifications. The WPI lib team is working to keep the API the same as best as possible. Direct compatibility may not be possible (think about module numbers when we first got the cRIOII vs the old 8-slot), but large portions of code will definetly be able to be reused.
FAST. File transfer the cross-compiled binary from your computer to the roborio and then execute it. No restart required. (The way it should be!)
The current radio we tested uses the USB port for power. I have not done concrete timing tests, but based on my early observations the full system was up in 20-40 seconds. I can do proper timing tests at a later time and provide a more acurate answer later.
Yes, WPI is the developer for the Java and C++ libraries as they have been in previous years.
The radio we have been using thus far are ASUS N-53. Wheather this is what will be rolled out with the final system is unclear at the moment. It is a USB wifi dongle and supports softAP mode (think wifi theter on your mobile device) as well as regular client mode. This hardware is not set in stone.
The roborio has a specified voltage input from 6.8V to 16V DC with a staged brown out of 4.5V to 6.8VDC I have not done brown out test yet, but will do after this season is over.
I don't know first hand. The roborio is linux based on a dual Arm Cortex 9, if you can compile it for that processor and memory constraints of the roborio, I do not see why it won't run. There is a full linux shell and you can use opkg to get additional packages on the rio.
I can give you a specific number later. I do not know at the moment, my inclination is that the weight is less. However, even if I measure the weight it will not be accurate. WE were given development hardware, the PD board and rio have no housing, they are just the PCB, the other modules had cases that were 3D printed. I can not say how much each of these items will weight once official casings are added to the mix. I assume what we have are just temporary to support our dev testing.
The roborio is not the radio as well. IT needs a radio device. Right now we are using a dongle provided as a candiate to provide that function (Asus N-53) not sure if this will be the final deviced used, but a device is needed.
Solenoids are not CANipede, they are a new product line from cross the road electronics, the Pneumatics Control Module (PCM) and Power Distribution Panel (PDP) have a can protocol built in.
If you only have a small number of actuators, nothing stops you from using the 4 relays onboard the cRIO for pneumatics. If you want more, then you must venture out and use the PCM. The PCM also takes in the compressor and DIO switch directly, so they do not need separate power or io from the roborio.
That is not implied at all. You are free to use any periperial device you like as long as there is a linux driver for it. USB camera, or put a ethernet switch for more ports. There are pros and cons to not having a dedicated switch on board. In all likely hood, most teams will probably be adding a switch to their robot just to have more ethernet ports. We always have at least a driverstation and programming laptop pluged in over ethernet.
We were told not to quote these products. Every team will get one in the 2015 KOP. Expect the system to be significantly less than the cRIO.
If the rules stays the same with regards to networking, nothing prevents you from adding a switch to your Robot. The dongle we are using right now is the Asus N-53, you can look up the poles of the antenna, although I assure you it is not single-poled. IF you want we can talk more about EM Waves and antenna theory.
The version of the RIO we have is not conformally coated. I am not sure if the final product will be. I plan to use the current sensors to tell if my motors are stalling or simply not driving the gearbox. That is all I really need them for. I am not sure how you can use them to detect shorts based on the they circuit they are apart of.
DISLAIMER: WE ARE IN ALPHA TEST PHASE. THE INFORMATION PROVIDED IS BASED ON WHAT WE HAVE NOW. THIS MAY VERY WELL CHANGE IN THE NEXT COMING MONTHS AS SOFTWARE AND HARDWARE DEVELOPMENT PROGRESSES. I CAN ASSURE YOU FIRST IS DOING EVERYTHING TO EASE THE TRANSISTION. FOR THOSE THAT MOVED FROM IFI TO CRIO BACK IN 2009, EXPECT A MORE SEEMLESS TRANSITION. ALL OF THE QUESTIONS REGARDING PERIPERIAL HARDWARE, AND SOFTWARE VERSIONS ARE SUBJECT TO CHANGE AS DEVELOPMENT INCREASES. IN ANY EVENT, THE 2015 CONTROL SYSTEM IS AWESOME, AND SHOULD BE A WELCOME CHANGE, DO NOT FEAR IT, OR LET INFORMATION PRESENTED DETER YOU FROM IT. WE DO NOT HAVE ALL OF THE ANSWER, BUT WILL TRY TO ANSWER THEM THE BEST WE CAN.
Hope this helps,
Kevin
Thanks for your help. The router I use is the RT-N53 and I found out the casing caused thermal overload, but that is off topic.
That is a very useful approach to find those pesky shorts. I, myself, thought of using the system resistance and watching the voltage drop on the driver station to calculate current draw of the system!
I wonder what FIRST has in mind for these current sensors. They maybe useful for reporting faults automatically to the FMS so they can be prepared to look for specific problems!
BBray_T1296
26-03-2014, 23:51
Will the new system be finally able to run at higher connection speeds so we are not stuck in early 2000s with 360p 50% compression 5fps video feeds?
I realize that it is more of a FMS problem than the robot side stuff, but will the FMS get a much-needed upgrade as well?
NotInControl
27-03-2014, 01:31
Will the new system be finally able to run at higher connection speeds so we are not stuck in early 2000s with 360p 50% compression 5fps video feeds?
I realize that it is more of a FMS problem than the robot side stuff, but will the FMS get a much-needed upgrade as well?
As you mentioned, your question and 2015 control testing are mutually exclusive. Nothing we have done to date suggests a required upgrade to FMS.
Your question would be better answered by a FIRST rep. I don't think anyone of us can help.
During our next gathering with FIRST, I can relay the question.
Regards,
Kevin
Tom Line
27-03-2014, 13:55
Thanks for your help. The router I use is the RT-N53 and I found out the casing caused thermal overload, but that is off topic.
That is a very useful approach to find those pesky shorts. I, myself, thought of using the system resistance and watching the voltage drop on the driver station to calculate current draw of the system!
I wonder what FIRST has in mind for these current sensors. They maybe useful for reporting faults automatically to the FMS so they can be prepared to look for specific problems!
I'm excited for a number of reasons regarding real time current monitoring. Being able to monitor current draw on each channel should make it fairly trivial to create preprogrammed motor protection. It also will be nice to be able to monitor current when you intentionally stall motors, during ball acquisition, etc.
You can do that now but it isn't nearly as easy as having it all 'built in'.
Will the new system be finally able to run at higher connection speeds so we are not stuck in early 2000s with 360p 50% compression 5fps video feeds?
Being able to use H.264 instead of motion JPEG would help that a lot, but our team has not figured out how to get that working with the Axis camera.
Hopefully it supports some sort of MJPEG because I don't know for sure if OpenCV supports H. 264. Hopefully they can bump up the bandwidth to at least 16Mbps next year because that will reduce lag by a lot. What type of Linux does the new cRIO run? Is it completely based off NI or is it based off an Operating System like Debian?
Another funny question that I have is that I am wondering if it would be possible for the cRIO to compile code on itself? That would be a nice finishing touch. My vision coprocessor checks code differences and compiles the code on bootup
wt200999
27-03-2014, 14:12
I'm excited for a number of reasons regarding real time current monitoring. Being able to monitor current draw on each channel should make it fairly trivial to create preprogrammed motor protection. It also will be nice to be able to monitor current when you intentionally stall motors, during ball acquisition, etc.
You can do that now but it isn't nearly as easy as having it all 'built in'.
I'd love to see some custom diagnostics come out of this, where you can run an automated checklist and see that everything in your system is plugged in and operating as expected before each match. You will either get an all good, or your system will point directly to the problem. No more losing matches because somethings not plugged in right.
NotInControl
27-03-2014, 15:21
Being able to use H.264 instead of motion JPEG would help that a lot, but our team has not figured out how to get that working with the Axis camera.
Depending on the camera you are using there will be an H.264 stream link that can be enabled via the web interface. If you use a USB camera next year, there are a number of h.264 compatible USB cameras that have linux drivers. Ultimately it depends on what processing library you use for H.264 to be useful to you. Lowering your image resolution will also reduce bandwidth over the FMS network.
Hopefully it supports some sort of MJPEG because I don't know for sure if OpenCV supports H. 264. Hopefully they can bump up the bandwidth to at least 16Mbps next year because that will reduce lag by a lot.
Open CV does support H.264, you need to compile ffmpeg with H.264 encoding support. Directions for adding h.264 support to ffmpeg can be found on the ffmpeg website.
What type of Linux does the new cRIO run? Is it completely based off NI or is it based off an Operating System like Debian?
The RoboRio (which is what I assume you mean by cRIO) runs a custom made linux distro. The difference is that the OS on the Robo RIO is a Real-time operating system with hard time slicing for deterministic results. More information of NI Linux Real-time can be found on the NI website. I am not sure it is correct to say that it is based off one type of linux or another. What I can say truthfully is that it is a linux real-time operating system with a full linux shell and provides opkg for package management. NI can elaborate more on the development of the OS.
Another funny question that I have is that I am wondering if it would be possible for the cRIO to compile code on itself? That would be a nice finishing touch. My vision coprocessor checks code differences and compiles the code on bootup
Yes this is possible as long as you choose to shell into the device and have a compiler installed. But it will be extrmely slow when compared to a desktop or laptop. Speed in compliation, and using a full up IDE (not over x window) is usually the reason for cross-compilation which is what the WPILib Plugins do. They allow you to develop, build, and compile code on your windows machine for an Arm based target and transfer the resulting binary over to the RoboRio. Remember the RoboRio is running a dual-core are at 667Hz and limited memory, compared to the gigaHz of your laptop/pc with gigs of ram, really is no comparison.
Thanks.
I wonder if it would be legal to have an onboard cheap ethernet switch. Next year, I want to have a node based processing system with multiple computers, running a specific portion of the code. One ethernet port will probably not be enough ;). I guess the dongle will be hard to hit my a gamepiece but I'm still kinda skeptical because the ASUS router sitting in front of me has quite a poor build quality and crashes every 15 mins. Is the antenna a single plane or multiple axes? A plane antenna would mean the robot would lose communications when it turns a bit.
I am also wondering about the build quality of the roborio. The GPIO seems to be build into the main package. Have you ever had any problems with debris getting in the case and making it behave very wierd? That was one thing that happened quite often with the Digital Sidecar!
I am just wondering but how accurate are the current sensors in the PDB? Do you ever use them as an effective debug strategy for eradicating nasty shorts?
Thanks.
I think I just spammed you with questions ;)
That kind of talk is striking fear in my heart :eek:
But the latter part leads me to a throw-down to the teams that have 3D printers. Design & build modular plugs to cover the connectors that are not in use. Yeah, I know, just stuff inert connectors in. I want something elegant.
NotInControl
28-03-2014, 12:02
Thanks for your help.... I wonder what FIRST has in mind for these current sensors. They maybe useful for reporting faults automatically to the FMS so they can be prepared to look for specific problems!
I'd like to preface that my response is speculative... but I doubt FIRST has any specific plans for the current sensors. They are provided for Teams use how ever they seem fit, it at all. Most teams will do just fine without current sensing (like a majority do now).
Remember, as of right now, the only way to have access to the current readings is to wireup the CAN bus between the Rio and the PDP.
In order for FIRST to pull off what you are proposing, they would have to force every team to wire that bus, and have default code on the RoboRio that reads current off those channels.
I am not an expert on FMS/Driverstation communications, but as far as I know, the Driverstation only talks to a small part of code on the cRIO to control Robot State, and UDP a couple of status parameters back.
While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will. Usually a stalled Motor is not the cause of a Robot loosing comms unless it is pulling the batter voltage down below the brownout point of the CRIO or D-link. The #1 priority of FIRST FTA'a is to make sure your Robot maintains FMS connectivity, not diagnose your build faults: that what other gracious teams help with :).
Frankly, I would rather FIRST limit the amount of reach they have within User code than expand it.
Hope this helps,
Kevin
I'd like to preface that my response is speculative... but I doubt FIRST has any specific plans for the current sensors. They are provided for Teams use how ever they seem fit, it at all. Most teams will do just fine without current sensing (like a majority do now).
Remember, as of right now, the only way to have access to the current readings is to wireup the CAN bus between the Rio and the PDP.
In order for FIRST to pull off what you are proposing, they would have to force every team to wire that bus, and have default code on the RoboRio that reads current off those channels.
I am not an expert on FMS/Driverstation communications, but as far as I know, the Driverstation only talks to a small part of code on the cRIO to control Robot State, and UDP a couple of status parameters back.
While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will. Usually a stalled Motor is not the cause of a Robot loosing comms unless it is pulling the batter voltage down below the brownout point of the CRIO or D-link. The #1 priority of FIRST FTA'a is to make sure your Robot maintains FMS connectivity, not diagnose your build faults: that what other gracious teams help with :).
Frankly, I would rather FIRST limit the amount of reach they have within User code than expand it.
Hope this helps,
Kevin
This could be a feature added into the roboRIO control system before it is deployed, so I think it might be a bit too early to say that it will be very hard for them to do. My point is so they can detect fatal faults to keep the robot safe. What if a motor/controller combo shorts out and pulls 120 amps? The FMS might be able to shut it down instead of allowing the breaker to open, thus crashing the entire bot! I think 75% of a robot is better than 0%. At least the robot will be able to drive around and possibly defend and use it's other mechanisms to score!
NotInControl
28-03-2014, 14:25
This could be a feature added into the roboRIO control system before it is deployed, so I think it might be a bit too early to say that it will be very hard for them to do.
I prefaced my previous post with "my response is speculative" so as to not have people assume it to be fact. I am not a representative of FRC, FIRST, or NI, and the statement I made in that post were purly based on my experiences thus far with FRC (based on 10+ years).... However, without side-tracking this post too much I will entertain your comment and offer this:
First, I never said it was hard for them to do. But I speculate it is additional work they will not likely do, as it requires more changes, with not a lot of benefit. As a FRC member about to experience a control system transistion one would advocate that FIRST should focus on a seamless transition, not adding more complexity to the mix. Please re-read my previous post if it was unclear. I stated "While it is possible for FIRST to pull off something like what you suggest, I think it is very unlikely that they ever will." I never said it was hard. Try not to misquote.
My point is so they can detect fatal faults to keep the robot safe. What if a motor/controller combo shorts out and pulls 120 amps? The FMS might be able to shut it down instead of allowing the breaker to open, thus crashing the entire bot! !
Fault detection is to keep people safe first, robot safe second. Since you are presenting this system as a good idea, you must be able to articulate how it works. If I understand correctly, you wish FMS can "shut it down" in lieu of a breaker being tripped. You would replace a mechanical device (a breaker) with a control system. As a control engineer or System designer, you need to think about reaction time, bounding limits, false detections, etc. Do you believe your control system will react faster then a mechanical breaker in the case you describe? What if the short was on the roborio - such that comms were lost. What is the reason you wish to agument the breakers? I believe the mechanical system wins!
What about instances when you power the robot on and don't have a driverstation connected? What does your system do in that case? The breakers still function but FMS doesn't
I think 75% of a robot is better than 0%. At least the robot will be able to drive around and possibly defend and use it's other mechanisms to score!
However for conversation purposes, Lets say we could augment the system and have FMS current monitoring in the loop. How do you plan to shut down a channel on the PDP, while allowing other channels to operate? This functionaility does not exist. If the breaker is inline, and not tripped, power will still be provided, nothing in software can prevent this currently. The channels are not individually controlled. I believe your statement of "the FMS can shut it down instead of allowing a breaker to open" is backwards. If a breaker opens, the rest of the robot still gets power. If FMS shuts the robot down, the whole robot goes down.
I am not sure what you mean here. Or how the system you describe actually works. Please think about the questions I ask, and try to rearticulate your system and how it behaves in those scenarios provided.
These questions are not to shot your ideas down so please do not take them that way. I ask them so you can be prepared to answer them as you articulate how the system you describe works.
Hope this helps,
Kevin
A typical breaker doesn't open immediately. It takes easily 1-3 seconds. This would have to be more of a watchdog feature, but if the load on a specific port on the PDB is too high for too long, not just a spike, it will open a relay and the fault shall no longer persist. With an FPGA onboard, it should be easy to make this extremely reliable and fast! The delay before trip would also be adjustable, instead of random (within a range)
Jon Stratis
29-03-2014, 21:30
One thing to note: I believe they are planning on using the PDB CAN interface for battery voltage monitoring, similar to the way they do today with the jumper on the analog breakout. That should make it very easy to help teams get some monitoring in place if they need it, since it'll already be wired up!
NotInControl
30-03-2014, 00:18
A typical breaker doesn't open immediately. It takes easily 1-3 seconds.
Not true for the scenario you presented (short drawing 120A). The breakers react to thermal change. A 40A breaker (max allowed in FRC) seeing a 120A draw will react within 0.5 - 1.1s (300% load over rating).
Check the spec...
http://www.snapaction.net/pdf/MX5%20Spec%20Sheet.pdf
This would have to be more of a watchdog feature, but if the load on a specific port on the PDB is too high for too long, not just a spike, it will open a relay and the fault shall no longer persist.
This thread is getting side tracked by this discussion. I admit I do not understand how the system you propose works. And I don't think given the current design of the hardware, it is even possible. It sounds like you want to add built-in relays to the PDP board as well as modify FMS and the driverstation to read current from the PDP. Without understanding how your system works, all I can say is make your request to FIRST, NI, or CTRE to see if they like it. If your system requires modification to the hardware (I assume this because I don't know what relay you speak of, or where it exists), then state that.
With an FPGA onboard, it should be easy to make this extremely reliable and fast! The delay before trip would also be adjustable, instead of random (within a range)
The FPGA only exist on the ROBORio not the power distro panel. It appears that you are proposing a system which relies on the CAN bus to be active, and the ROBORio FPGA to be functioning (powered/not crashed etc), as well as the Driverstation in the loop, and possibly FMS. These are a lot of variables in a system which is to determine what happens to a robot during a fault. Food for thought? How does your system work in the event one of those systems is not in the loop? How does your system work with the current hardware? If you wish to continue this discussion, I suggest you open a separate thread.
One thing to note: I believe they are planning on using the PDB CAN interface for battery voltage monitoring, similar to the way they do today with the jumper on the analog breakout. That should make it very easy to help teams get some monitoring in place if they need it, since it'll already be wired up!
I remember Joe for NI stating that the battery voltage on the Driverstation will be polled directly from the inputs of the RoboRIO. This is possible because there is no longer a boost supply on the power supply to the RoboRio from the PDP board. So I do not believe the CAN bus is a requirement for voltage monitoring. Obviously this can change.
Regards,
Kevin
Greg McKaskle
30-03-2014, 06:56
As mentioned, the cRIO is a 24V device on a 12V robot. It isn't connected directly to the battery. The roboRIO will connect straight to the 12V circuit of the PD. It will monitor voltages directly for battery and for its internal supplies. It will indeed have monitoring and will shutdown systems in brown-out situations. The cRIO does that today, but it can only measure if the analog module is wired.
Greg McKaskle
Since the roboRio is a 12V device, I hope they will keep the 24V on the PD so we can use it for things like 24V solenoids, etc ....
Jefferson
30-03-2014, 09:08
Since the roboRio is a 12V device, I hope they will keep the 24V on the PD so we can use it for things like 24V solenoids, etc ....
The Pnuematics Control Module has a jumper to select either 12 or 24 V outputs to the solenoids.
Bryan Herbst
30-03-2014, 09:31
Will the new system be finally able to run at higher connection speeds so we are not stuck in early 2000s with 360p 50% compression 5fps video feeds?
I realize that it is more of a FMS problem than the robot side stuff, but will the FMS get a much-needed upgrade as well?
Why do you need a higher quality video stream? You should be able to get much better quality than what you described and still be well within the 7 Mbps limit. I have yet to see a team that even noticed a difference in their video quality when they turned it down to get around 3 Mbps.
Most teams' video streams are about 2 square inches on their laptops, and they glance down at the stream every couple of seconds to line up a shot or get their bearings. 1080p (or even 720) would be way overkill, and 60fps is also a waste of bandwidth.
As you pointed out, this also isn't a limitation of the cRIO or roboRIO. It isn't even a limitation of the FMS itself. It is effectively a limit of the WiFi router used on the field. If all six teams on the field are streaming 1080p video at 60fps, someone is going to start dropping control packets.
sparkytwd
30-03-2014, 16:20
Why do you need a higher quality video stream? You should be able to get much better quality than what you described and still be well within the 7 Mbps limit. I have yet to see a team that even noticed a difference in their video quality when they turned it down to get around 3 Mbps.
Most teams' video streams are about 2 square inches on their laptops, and they glance down at the stream every couple of seconds to line up a shot or get their bearings. 1080p (or even 720) would be way overkill, and 60fps is also a waste of bandwidth.
As you pointed out, this also isn't a limitation of the cRIO or roboRIO. It isn't even a limitation of the FMS itself. It is effectively a limit of the WiFi router used on the field. If all six teams on the field are streaming 1080p video at 60fps, someone is going to start dropping control packets.
You guys might be interested in ocupus (https://github.com/hackcasual/ocupus). I'm finishing up a writeup of our competition this weekend with the sample video. With ocupus we stream an 800x448@30fps color and a 320x240@30fps infrared feed to our driverstation using only 2mbps. Reviewing our connection logs on the dashboard, showed only an average of 4 packets per match being dropped to the cRio.
virtuald
30-03-2014, 16:31
With ocupus we stream an 800x448@30fps color and a 320x240@30fps infrared feed to our driverstation using only 2mbps
This sounds pretty cool. It requires having an additional computer on the robot, correct?
MrRoboSteve
30-03-2014, 16:44
For example, here's a tutorial on NI's website that installs PostgreSQL and uses it with LabVIEW on the Linux platform: https://decibel.ni.com/content/docs/DOC-30308
I will have to brush up on my PostgreSQL skills for helping at next year's regionals :)
sparkytwd
30-03-2014, 17:24
This sounds pretty cool. It requires having an additional computer on the robot, correct?
Correct, however one of my test platforms is the $65 Odroid-U3. With a PS3 eye cam, memory card and power converter you're looking at half the price of an Axis camera. #3574 uses the more powerful Odroid XU at $170. Under testing the performance edge it has over the U3 is only about 20%, and maybe even not that much. With 2 feeds, 1 of which is being processed by a hot goal detector, we barely break 50% utilization.
The only downsides I see against the Axis cameras are
Multiple components that need to be connected
No wpilib support
To bring it back to the thread at hand, I will be testing ocupus on RobotRIO in the hopes that it can support at least 1 low resolution USB camera without too much impact on other robotly duties.
Greg McKaskle
30-03-2014, 20:28
Speaking of USB cameras, the roboRIO has several USB host ports and there are UVC drivers installed. My testing has been through IMAQdx, the NI driver for camera buses such as USB. We've done testing with a variety of USB cameras, even some set up for stereo. We've also done a bit of testing with the industrial USB3 cameras running on the USB2 bus. Some of the mfg drivers are OK with this and it allows for higher end sensors, lenses, filters and the like. And of course IP cameras such as Axis also work. WPILib only supports Axis, but IMAQdx supports some others.
Greg McKaskle
sparkytwd
31-03-2014, 13:31
Speaking of USB cameras, the roboRIO has several USB host ports and there are UVC drivers installed. My testing has been through IMAQdx, the NI driver for camera buses such as USB. We've done testing with a variety of USB cameras, even some set up for stereo. We've also done a bit of testing with the industrial USB3 cameras running on the USB2 bus. Some of the mfg drivers are OK with this and it allows for higher end sensors, lenses, filters and the like. And of course IP cameras such as Axis also work. WPILib only supports Axis, but IMAQdx supports some others.
Greg McKaskle
If someone's got gstreamer running on it, it would be cool to see if you can get the h264 stream from a webcam that supports it (like the Logitech C920). Should be a pretty low overhead way of getting high quality video streams directly on the RobotRio.
jbsmithtx
01-04-2014, 18:21
The radio we have been using thus far are ASUS N-53. Wheather this is what will be rolled out with the final system is unclear at the moment. It is a USB wifi dongle and supports softAP mode (think wifi theter on your mobile device) as well as regular client mode. This hardware is not set in stone.
So does this mean we no longer need freshman to chase the robot with an ethernet cord on the practice field?
Sounds great, but this seems odd, because FIRST recently tightened up on all their robot network regulations. But indeed, this would be very cool. Maybe a better solution to the problem at hand?
Joe Ross
01-04-2014, 18:22
So does this mean we no longer need freshman to chase the robot with an ethernet cord on the practice field?
Sounds great, but this seems odd, because FIRST recently tightened up on all their robot network regulations. But indeed, this would be very cool. Maybe a better solution to the problem at hand?
Realize that the current dlink bridge also supports AP mode, but is not allowed to be used in AP mode at competition.
jbsmithtx
01-04-2014, 18:40
Realize that the current dlink bridge also supports AP mode, but is not allowed to be used in AP mode at competition.
So does this mean that we would have to render our camera useless during practice (and still tether at competition)
Or would we have to have a switch on-board still? Makes the dongle seem useless...
:confused:
Really hoping we can do some sort of "secure" wireless tether...
BBray_T1296
01-04-2014, 19:24
Another question. On the current CRIOs, we are able to support more than one digital sidecar (if, say, we happen to need more than 10 PWM ports) by simply slipping another digital breakout into an empty slot. With the DSC integrated into the RoboRIO, what would the procedure be to "add" more ports?
Joe Ross
01-04-2014, 20:10
So does this mean that we would have to render our camera useless during practice (and still tether at competition)
Besides tethering over ethernet, the roboRIO also supports tethering over USB.
Joe Ross
01-04-2014, 20:19
Another question. On the current CRIOs, we are able to support more than one digital sidecar (if, say, we happen to need more than 10 PWM ports) by simply slipping another digital breakout into an empty slot. With the DSC integrated into the RoboRIO, what would the procedure be to "add" more ports?
The MXP supports additional PWM ports, as well as many other additional functions.
NotInControl
01-04-2014, 20:43
So does this mean that we would have to render our camera useless during practice (and still tether at competition)
Or would we have to have a switch on-board still? Makes the dongle seem useless...
:confused:
Really hoping we can do some sort of "secure" wireless tether...
In a nutshell, what you are asking is not implied. There are two USB host ports (plug in keyboards, usb camera's etc) and 1 USB device port (emulates an ethernet port and allows you to flash firmware and program over). There is also an Ethernet Port for network connectivity.
IF FIRST sticks with the USB dongle route, the other usb host port is availble. If you choose to use a USB camera, you can thether over the USB device port or over ethernet. If you choose to use an IP camera, you can thether over the USB device port. IF you have an ethernet switch on board and plug your camera into that (rules notwithstanding) possibilities are endless.
I doub't "secure wireless thether" will be used. Any possible cause of interference to a real match is not a good idea. Just Plug in, keep calm and carry on!
Another question. On the current CRIOs, we are able to support more than one digital sidecar (if, say, we happen to need more than 10 PWM ports) by simply slipping another digital breakout into an empty slot. With the DSC integrated into the RoboRIO, what would the procedure be to "add" more ports?
The expansion slot (Middle of RobRio) has a 32 pin connector, 10 of those pins can be used as additional for PWM (The details of how this interface is control through software I am not sure of yet, so I can not answer questions on it), but the quick answer is there is some room for growth.
Similar case for digital IO, where pins on the expansion port can be used for additional DIO. However, as for analog, I am not sure if there are ports on the expansion slots which can be used as Analog in or out, but you have access to SPI and I2C interfaces, so just use those if you need to expand analog sensors. You can always use an analog channel with tresholding to get a digital reading.
(I typically see a lot more digital channels used then analog IO on robots). You can reduce IO by knowing when not to use quadrature encoders, vs pots, vs other sensors.
But as for your hypotetical, if you start needing more then 10 individual PWM I would be concerned. Remember, all motors in a single gearbox can split the same PWM signal because they are all being commanded to do the same exact thing at the same time.
Even if you have some special swerve/crab drive, I do not see the need for that many PWM signals on a robot.
What I am saying is, with a little re-thinking you should be able to get your bot to live within the 10pwm/10dio/8 analog channels a majority of the time with little need to expand, but the option to expand is built-in.
Hope this helps,
Kevin
BBray_T1296
01-04-2014, 21:37
In a nutshell, what you are asking is not implied. There are two USB host ports (plug in keyboards, usb camera's etc) and 1 USB device port (emulates an ethernet port and allows you to flash firmware and program over). There is also an Ethernet Port for network connectivity.
IF FIRST sticks with the USB dongle route, the other usb host port is availble. If you choose to use a USB camera, you can thether over the USB device port or over ethernet. If you choose to use an IP camera, you can thether over the USB device port. IF you have an ethernet switch on board and plug your camera into that (rules notwithstanding) possibilities are endless.
I doub't "secure wireless thether" will be used. Any possible cause of interference to a real match is not a good idea. Just Plug in, keep calm and carry on!
The expansion slot (Middle of RobRio) has a 32 pin connector, 10 of those pins can be used as additional for PWM (The details of how this interface is control through software I am not sure of yet, so I can not answer questions on it), but the quick answer is there is some room for growth.
Similar case for digital IO, where pins on the expansion port can be used for additional DIO. However, as for analog, I am not sure if there are ports on the expansion slots which can be used as Analog in or out, but you have access to SPI and I2C interfaces, so just use those if you need to expand analog sensors. You can always use an analog channel with tresholding to get a digital reading.
(I typically see a lot more digital channels used then analog IO on robots). You can reduce IO by knowing when not to use quadrature encoders, vs pots, vs other sensors.
But as for your hypotetical, if you start needing more then 10 individual PWM I would be concerned. Remember, all motors in a single gearbox can split the same PWM signal because they are all being commanded to do the same exact thing at the same time.
Even if you have some special swerve/crab drive, I do not see the need for that many PWM signals on a robot.
What I am saying is, with a little re-thinking you should be able to get your bot to live within the 10pwm/10dio/8 analog channels a majority of the time with little need to expand, but the option to expand is built-in.
Hope this helps,
Kevin
Thanks for the reply. Our team has never used more than 10 PWM ports, but I have seen some teams who have. When we had 16 motors on our 2012 robot, we used splitters to reduce the count. Also we diverted some motors to spikes as our intake never needed anything but full speed in or out.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.