Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   CRIO-FRCIII (http://www.chiefdelphi.com/forums/showthread.php?t=128157)

Jon Stratis 26-03-2014 15:19

Re: CRIO-FRCIII
 
Quote:

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

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

yash101 26-03-2014 16:25

Re: CRIO-FRCIII
 
Quote:

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

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

Re: CRIO-FRCIII
 
Quote:

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

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.

yash101 26-03-2014 17:05

Re: CRIO-FRCIII
 
Quote:

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.

That's exactly what I was looking for! Thanks! ;)

NotInControl 26-03-2014 22:06

Re: CRIO-FRCIII
 
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.

Quote:

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

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.

Quote:

Originally Posted by Arhowk (Post 1364772)
[*] 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.

Quote:

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)

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.

Quote:

Originally Posted by Arhowk (Post 1364772)
[*] 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.

Quote:

Originally Posted by Arhowk (Post 1364772)
[*] 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!)




Quote:

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?

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.

Quote:

Originally Posted by Jared (Post 1364833)
Is it still WPIlib for Java?

Yes, WPI is the developer for the Java and C++ libraries as they have been in previous years.

Quote:

Originally Posted by Jared (Post 1364833)
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.

Quote:

Originally Posted by Jared (Post 1364833)
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.

Quote:

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?

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.

Quote:

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

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.

Quote:

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.

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.

Quote:

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.

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.

Quote:

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?

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.

Quote:

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

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

Knufire 26-03-2014 22:35

Re: CRIO-FRCIII
 
Quote:

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

Quote:

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.

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

Quote:

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


yash101 26-03-2014 23:32

Re: CRIO-FRCIII
 
Quote:

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

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

Re: CRIO-FRCIII
 
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

Re: CRIO-FRCIII
 
Quote:

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?

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

Re: CRIO-FRCIII
 
Quote:

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!

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

fb39ca4 27-03-2014 14:04

Re: CRIO-FRCIII
 
Quote:

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?

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.

yash101 27-03-2014 14:12

Re: CRIO-FRCIII
 
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

Re: CRIO-FRCIII
 
Quote:

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

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

Re: CRIO-FRCIII
 
Quote:

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.

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.

Quote:

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.

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.


Quote:

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?

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.

Quote:

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


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.

tcjinaz 27-03-2014 23:15

Re: CRIO-FRCIII
 
Quote:

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

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.


All times are GMT -5. The time now is 21:56.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi