After 2019, the RoboRio will be likely be discontinued due to the expiration of the contract between FIRST and NI. With that being said, what are you guys looking forward to in a successor?
Personally, I’d want:
Some form of GPU, for the purpose of computation
Internal bridge with an external antenna to be mounted anywhere on the robot
Open source, cross platform driver station software
Enough CPU and RAM to run vision at a high framerate
Official support for using DIO pins for more PWM outputs
If that timeline were the same for 2020 we would have already seed the RFP for the 2020 control system. So they are either running on a different schedule or handling the entire development differently.
Honestly, I would be happy with just this, assuming that the radio would be operational at the same time the RIO boots up. The radios we use in FRC are awful for our use case – too many matches have been decided by the bridge failures/reboots.
Kinda boring to name something we already have, but that it’s Linux-based. Being able to ssh in and check that things are working is great, and since we use config files, even allows for editing robot behavior without redeploying. But please put a c compiler on the next one.
Question: How do I get GCC and other components of the GNU toolchain on my target?
Answer: The following is a compilation of the information within this thread: Re: Building software for NI Linux RT - NI Community
Note: you will need internet access for this process to work correctly, as opkg (the package manager within the Linux install on these targets) downloads the packages from an external site.
Enable SSH access to your target within MAX or WIF.
SSH into the target.
Type the following commands one after each other (allowing the previous command to complete):
[2013 only] opkg flag ok libc6
[2013 only] opkg upgrade libc6
opkg install gcc gcc-symlinks
opkg install cpp cpp-symlinks
opkg install libc6-dev
opkg install binutils-symlinks
opkg install make
These packages and other common tools like Perl are also part of larger “packagegroups” that you can use as a convenient shortcut instead on recent versions of NI Linux RT, for example:
opkg install packagegroup-core-buildessential
A dedicated radio for real time communication. Keep the existing Ethernet/Wifi system in place for video streaming, FMS monitoring and programming but have DS info go through a USB radio transceiver dongle plugged into the DS laptop (nRF24L01+ based system would probably work well) that transmits to their robot on the field. If Wifi communication is lost you’d still have control over the robot besides video streaming.
In the case of an estop the FMS would communicate with the DS laptop via ethernet to send a estop command through the dedicated radio to the robot. The DS would automatically estop if the FMS ethernet connection is lost in tournament mode. Matches would not start until both connections are made.
As someone who has spent the last three years hunting down USB-related issues on FTC robots… I really dislike the idea of having a required and critical part of the system need to be USB. FTC teams are awful to their USB cables, and FRC teams would likely be as bad, if not worse, considering the higher powered collisions and vibrations of FRC robots.
I’ll second the $200 request, and add that I’d like to see the entire system move towards being even more foolproof. Particularly, the radio, which is perennially an issue. So I guess I agree with your principle, Marcus, but not your solution.
All things considered, I think the RIO is technologically ok. I’d be much happier if its cost were more inline with similarly-targeted products (i.e. other embedded robot controllers for the consumer/maker market). Keep most external ports the same (maybe swap out one of the two USB-A for a USB-C port) since it allows for greatest flexibility. Keep an accessible flavor of Linux as the core OS. Don’t put any internal sensors in it except those which pertain to system health.
For its current price point I would expect the next iteration’s vendor to work with VEX to get reliable, noise-resistant radio commands from the driver’s station to the robot and yet still give teams the option to do wifi on top of that so we can have our (quite precious, tbh) video streams.
I’m split on wanting a GPU or not. On the one hand, NN’s would be fun to have embedded into the core code with no interfacing required. On the other hand, we could probably get that using an offboard processor that costs less than what it would take to put a GPU into the RIO (and with upgradeable hardware over the years). In addition, I wouldn’t want a match ruined by power or heat issues related to GPU usage.
NI’s done a great good job with the RIO. Yet in 2018 terms, it’s quite expensive.
You can put quite a few servos on each PDP output.
I think $200 retail is an unrealistic target, and a $200 team price is still pretty tight. By the time you account for all the different ways we have to control things and communicate (PWM, CAN, relay, DIO, USB, SPI, I2C, RS-232) and the speed to track encoders on motor shafts and the power to process video, you’re beyond a $200 price point. Except for RS-232, I’ve noticed robots using each of these, so I wouldn’t want to see very many discontinued.
A high priority should be keeping as much of the existing control hardware as possible (motor controllers, and likely the PCM) to reduce the cost of replacing hardware simply because it is no longer allowed.
As far as moving **forward **with the control system, the biggest item to improve has to be making the control and basic telemetry [dashboard level] radio more robust, while maintaining the ability to stream some live video at a decent frame rate, especially if the GDC keeps designing games with short lines of sight.
Improving processing power for video and such would be next.
At a lower priority, moving robot comms away from wifi frequencies would also greatly simplify teams’ internal communications for scouting and such, because we wouldn’t have to outlaw hotspots.
I was thinking about that, and I actually don’t think it’s too unreasonable for a more powerful device to be $200 for teams. The Nintendo Switch, while obviously not an industrial grade robot controller, retails for $300 in 2017 and contains a decent amount of processing power, including a Nvidia Tegra GPU, the same thing used for vision tracking by any team lucky enough to get a Jetson in FIRST Choice. With that in mind, a device with about the same amount of power in 2020 could feasibly be $200 for teams, and far more for industrial use.
I’m not sure this is the best analogy, to use. A Switch is a retail device, sourced at quantities in multi hundreds of thousands, if not millions, and is further subsidized by the game costs. (Nintendo gets a fee for each game sold.)
It was common knowledge around the launch of the XBox 360 & PS4 that those consoles were selling for at/near/below cost at launch - only after component prices dropped were the consoles making measurable money.
This is true. I was using the Switch as a reference device partially because it has similar processing power to what I would expect in a future control system, as well as assuming that NI (or whoever makes the next control system) also sells the FRC versions of their hardware at a loss and sells the industrial versions at a large profit margin. (Assuming that they are bought for industrial purposes, as we’ve been getting more specialized hardware since the cRIO.)
The CTRE Hero is $60 and does most of the things the RoboRio can besides ethernet and video processing. Add a single board computer/android phone (like FTC) and you basically have a RoboRIO. I don’t think a $200-300 price target is unrealistic. I’d expect FIRST to subsidize some of the development costs.
$200 isn’t completely crazy - even if you want to add an FPGA for additional I/O or keeping a watchdog running - though I think the ARM big.little architecture makes more sense.
I’m with ya here, and will pre-empt the nay-sayers. You have to give this the squinty-eye. If teams can’t keep a barrel connector attached to their current router, how would they ever keep anything attached to this?
i.e. it would still take some development work. IMO, Scrap the wireless & sensors to add some robust connectors.
