Originally Posted by Arhowk (Post 1363415)

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.

Originally Posted by electrian21 (Post 1363451)

http://www.usfirst.org/roboticsprogr...-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.

Originally Posted by Arhowk (Post 1363878)

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!

Originally Posted by Arhowk (Post 1364772)

Well, for either of you I suppose

1. How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
2. Is it easy to upgrade / switch JRE's on the niRIO?
3. (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)
4. How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
5. What are the deploy times?

Originally Posted by Jefferson (Post 1364823)

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.

Originally Posted by Jared (Post 1364833)

How long does it take for the whole thing to turn on, including the radio?

Originally Posted by Arhowk (Post 1364835)

i believe so

Originally Posted by Jefferson (Post 1364868)

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.

Originally Posted by Arhowk (Post 1364772)

Well, for either of you I suppose

1. How is the new Java API? Is it simply the old one or did they re-do it with all Java 8ness
2. Is it easy to upgrade / switch JRE's on the niRIO?
3. (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)
4. How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?
5. What are the deploy times?

Originally Posted by Jared (Post 1364833)

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?

Originally Posted by theawesome1730 (Post 1364841)

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)?

Originally Posted by xXhunter47Xx (Post 1364852)

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.

Originally Posted by electrian21 (Post 1364871)

Will something similar be offered at Worlds?

Originally Posted by Cecil (Post 1364940)

For CAN Jaguars, how easy are they to implement into the new system, or has there been no testing done with that yet?

Originally Posted by vinnie (Post 1364836)

How good is the support for standard Linux programs, do you think it might be able to run ROS?

Originally Posted by rfolea (Post 1364969)

Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?

Originally Posted by rfolea (Post 1364969)

Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?

Originally Posted by Tom Line (Post 1364974)

We haven't heard any solid cost numbers. They're projecting it to cost well below the current system.

Originally Posted by Tom Line (Post 1364864)

Here is an overview of the new 2015 control system:

http://www.fightingpi.org/Resources/...ha/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.

Originally Posted by yash101 (Post 1365081)

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!

Originally Posted by Jon Stratis (Post 1365090)

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!

Originally Posted by yash101 (Post 1365181)

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 ;)

Originally Posted by Jon Stratis (Post 1365189)

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 :)

Originally Posted by yash101 (Post 1365242)

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 ;)

Originally Posted by Jefferson (Post 1365251)

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.

Originally Posted by Arhowk (Post 1364772)

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

Originally Posted by Arhowk (Post 1364772)

[*] Is it easy to upgrade / switch JRE's on the niRIO?

Originally Posted by Arhowk (Post 1364772)

[*] (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)

Originally Posted by Arhowk (Post 1364772)

[*] How easy is it to write code on standard Java SE / cRIO Java and port it to niRIO?

Originally Posted by Arhowk (Post 1364772)

[*] What are the deploy times?

Originally Posted by Jared (Post 1364833)

I have a few questions.

How long does it take for the whole thing to turn on, including the radio?

Originally Posted by Jared (Post 1364833)

Is it still WPIlib for Java?

Originally Posted by Jared (Post 1364833)

What's the radio look like? Are we still using the d-links?

Originally Posted by Jared (Post 1364833)

How low does the voltage have to go to brown out the radio/controller?

Originally Posted by vinnie (Post 1364836)

How good is the support for standard Linux programs, do you think it might be able to run ROS?

Originally Posted by theawesome1730 (Post 1364841)

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)?

Originally Posted by xXhunter47Xx (Post 1364852)

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.

Originally Posted by BitTwiddler (Post 1364872)

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.

Originally Posted by rfolea (Post 1364969)

Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?

Originally Posted by yash101 (Post 1365181)

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 ;)

Originally Posted by rfolea

Anybody heard any numbers on the cost of the new system or how the rollout will be handled next year?

Originally Posted by NotInControl (Post 1365400)

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.

Originally Posted by NI roboRIO FAQ

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

Originally Posted by NotInControl (Post 1365400)

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

Originally Posted by BBray_T1296 (Post 1365455)

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?

Originally Posted by yash101 (Post 1365449)

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!

Originally Posted by BBray_T1296 (Post 1365455)

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?

Originally Posted by Tom Line (Post 1365662)

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

Originally Posted by fb39ca4 (Post 1365663)

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.

Originally Posted by yash101 (Post 1365666)

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.

Originally Posted by yash101 (Post 1365666)

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?

Originally Posted by yash101 (Post 1365666)

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

Originally Posted by yash101 (Post 1365181)

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 ;)

Originally Posted by yash101 (Post 1365449)

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!

Originally Posted by NotInControl (Post 1365959)

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

Originally Posted by yash101 (Post 1366007)

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.

Originally Posted by yash101 (Post 1366007)

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

Originally Posted by yash101 (Post 1366007)

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!

Originally Posted by yash101 (Post 1366338)

A typical breaker doesn't open immediately. It takes easily 1-3 seconds.

Originally Posted by yash101 (Post 1366338)

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.

Originally Posted by yash101 (Post 1366338)

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)

Originally Posted by Jon Stratis (Post 1366395)

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!

Originally Posted by rfolea (Post 1366528)

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

Originally Posted by BBray_T1296 (Post 1365455)

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?

Originally Posted by Tanis (Post 1366536)

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.

Originally Posted by sparkytwd (Post 1366711)

With ocupus we stream an 800x448@30fps color and a 320x240@30fps infrared feed to our driverstation using only 2mbps

Originally Posted by Peter Johnson (Post 1364951)

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

Originally Posted by virtuald (Post 1366716)

This sounds pretty cool. It requires having an additional computer on the robot, correct?

Originally Posted by Greg McKaskle (Post 1366848)

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

Originally Posted by NotInControl (Post 1365400)

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.

Originally Posted by jbsmithtx (Post 1368089)

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?

Originally Posted by Joe Ross (Post 1368090)

Realize that the current dlink bridge also supports AP mode, but is not allowed to be used in AP mode at competition.

Originally Posted by jbsmithtx (Post 1368097)

So does this mean that we would have to render our camera useless during practice (and still tether at competition)

Originally Posted by BBray_T1296 (Post 1368105)

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?

Originally Posted by jbsmithtx (Post 1368097)

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

Originally Posted by BBray_T1296 (Post 1368105)

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?

Originally Posted by NotInControl (Post 1368144)

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