I suspect a blog post or email blast will be coming before too long. I’ve attached a copy of the flier that was handed out.
2015 Control System Handout.pdf (95.8 KB)
2015 Control System Handout.pdf (95.8 KB)
My favorite features
- Linux: Full linux shell and features are just an ssh away
- Java 8: No explanation needed
- Units and Measures: In java pots will directly return an angle and encoders a distance
- Eclipse: Already my standard IDE gains FRC
- 5 second launch: The java program is saved on the roboRio as a jar. The jar is uploaded and launched without reboot in under 5 seconds.
- PCM: Makes compressor control much easier
(Quick Note: Because of the linux shell you can run whatever java version you want)
I’d be interested to know how much slower it is. Maybe 10x? I don’t have a good sense of how many cycles on an ARM Cortex A9 is equivalent to a cycle on a recent x86. Anybody seen a good comparison?
There is more to it than the throughput of the processor. On the robot there will be less memory (and paged memory may be disabled), less cache and less non-volatile storage though I reckon one could attach a USB drive. I think the core of the i7 is roughly 25X faster (it is hard to make a apples-to-apples comparison) but the effective throughput of the i7 is much higher.
Does the new power board supply 12 V or 24 V power to the RoboRio? I’m just wondering if the minimum voltage went up or down as compared to FRC-cRIO-II, because the spec sheet Joe uploaded lists 6.8V as the minimum voltage.
The NI page has a spec sheet that says there’s a staged brownout from 4.5V-6.8V. Is that new? My understanding is that the current PDB feeds 24V to the cRio, so 4.5V of battery voltage (plus a bit for resistance losses) can meet the 9-30 V power requirement. If that requirement goes up to 6.8 V or down to 3.4 V, that has implications for robot design.
It’s connected directly to the PD board battery supply.
I can’t find the post but I read that they made it to allow for teams to mess up and hook it up to 24 volts without destroying it.
Thanks for the link. It will be interesting to see how far teams are able to push their overpowered drive trains with the new system. Fortunately, having CAN on the power board and in Talons will make it easier to figure out where the limits are.
The PD board will have real-time monitoring capability on the different channels. That means it should be trivial to monitor the current draw of your motor systems and dynamically manage the system to send the power where you want it for the maximum amount of time.
I can already see writing a power management VI where I can prioritize and limit the motor setoutput based on current draw.
If you can point me to a benchmarking application, I’ll try to run it on the RoboRIO. If you want another comparison between the old & the new, please see this (slide 9). I ran the same test on a 2012 i7 and it was getting 200+ FPS at 640x480 so I took it out of the comparison. Also, please note this was only using one of the two RoboRIO cores.
Side note, from what I’ve learned at NI Days, the new RIOs have two task schedulers. One is for RT, one is for non-RT.
I recommend reading over the Introduction to NI Linux Real-Time.
He he, well yes, but have fun with that! Java 8 is the only java that works out of the box with no funny flags.
Also somebody was wondering what kind of linux it is: 3.2 kernel (3.2.35-rt52-2.0.0a4 #1 SMP PREEMPT RT armv7l) and its based on OpenEmbeded/Angstrom (it has opkg (dpkg-like) package management). Uses busybox for most things.
I would also not recommending running gcc on it, but you can use stock gcc for cross compiling. I’ve been using g++ 4.6 armel from the ubuntu 12.04 repositories just fine, though the binutils in the repos don’t support a flag as they were too old, so I had to upgrade if I cared to see that flag be labled (worked perfectly find though).
This is a thing? So excited now
Keep in mind the amount of work you will have to do is the same. You’ll still have to supply a scaling factor to get an accurate angle, because the rRIO doesn’t know if you are using a 1 turn pot, a 10 turn pot, or a 54 inch string pot. The same caveat holds true for the encoders.
I didn’t realize in the past that Java didn’t have a function that just allowed you to supply a scaling factor when you declare the sensor. That’s how LabVIEW has always had it.
Full Java 8 next year! :yikes: I guess we can just use JavaScript (via Longhorn) as our scripting language. Can’t wait until they are ready to order. I think I will save some vacation time to work on some open source. 
OTS Linux has multiple scheduling algorithms - a priority-based pre-emptive scheduler for real-time (non-zero POSIX priority) and fair scheduling algorithm for everything else (POSIX priority is zero). And then there is the scheduling algorithm for interrupt threads in the kernel.
You can pre-order a roboRIO now from AndyMark (but it won’t ship until December). http://www.andymark.com/product-p/am-3000pre.htm
If you don’t want to order yet, you can fill out a form indicating how many you want to buy, so to help gauge interest. https://docs.google.com/forms/d/1eiZiRIDff9WF1PxsZ4Rmzqa9SoGGiIHNexDI4-_t59A/viewform?usp=send_form
Anybody have any idea when the supporting parts (PD board, Pneumatics board and Regulator board) will be available? Same time as the roboRIO?
Also, anyone know when we can hope for CAD files of these? The roboRio is already available at https://decibel.ni.com/content/docs/DOC-30419. Waiting for the rest of them to complete the picture 
Has anyone see timing on when we would find out if we are a beta-testing team? My co-mentor applied for it, but I don’t think we have found out anything. He is starting a Labview Academy next year at our Career Center and I can’t wait for the fun we’ll have!
The application doesn’t close until May 30th so I wouldn’t expect to hear anything before that. Probably 1st or 2nd week of June would be my guess.
Ahh gotcha, sorry I was thinking it was end of April the application was due, not the end of May. Thanks!