NI Week Athena Announcement and Q&A Panel

[magnets]

Originally Posted by evanperryg

My team knows, dead certain, that you can run an FRC bot as effectively off Vex as off of the cRio. In fact, we have our entire 2012 bot wired into a cortex and it works perfectly.

While I do agree that the vex cortex is probably closer to an optimal controller than the cRIO was, it is not a replacement for the cRIO/roboRIO.
The vex controller can't do image processing, it can't be programmed in LV or java, and it doesn't have an ethernet port or a CAN port. It also doesn't have an FPGA. While it may be a substitute for 99% of FRC robot controllers, there are definitely teams who do need the extra stuff.

[Racer26]

Originally Posted by evanperryg

My team knows, dead certain, that you can run an FRC bot as effectively off Vex as off of the cRio. In fact, we have our entire 2012 bot wired into a cortex and it works perfectly.

Which, really, is the crux of my point. The cRIO costs roughly double what a Vex Cortex costs. For most teams, that's a crappy value, since the vex cortex could do the job adequately for 99% of teams.

With only 2 cRIOs, dedicated to a current competition bot and a practice bot, you have nothing to run past robots on for demos. Most teams like to keep at least one, and ideally all of their past robots in operational condition.

[cadandcookies]

Originally Posted by Racer26

Most teams like to keep at least one, and ideally all of their past robots in operational condition.

"Would like to" doesn't mean can. My team has been running for 8 years with plenty of resources, but we still don't keep our robots year after year, mostly due to space concerns. I know that there are plenty of teams in our area that have even less space that we do, for whom keeping their old robots isn't even considered.

To be honest, I don't really see the point in complaining about the cost of the controller-- it is what it is, and they've already said they're aiming to reduce the cost as much as possible long-term. I suppose one may feel free to be discontented with the future control system (for a variety of reasons), but it's a rather clear step up from the cRIO in just about every way possible.

In terms of boot times, yes it would be very nice to bring them down in the 10-20s range, but I have a feeling there's more to it than just "FIRST is willing to put up with it." Keeping the price low (even when people are claiming it's already too high) probably factors in, as well as parts that we probably aren't considering.

Personally, I think a faster boot time would be an excellent improvement in terms of how fast match cycles go, and as a relatively well-off team, we'd probably be okay with an increase in the price for that, but there's a far larger picture than just my team or even all the teams on CD, which is what NI and FIRST have to consider.

My overall opinion is that every control system has its quirks that we'll be dealing with for quite a while, and I'm happy that those are getting out now so that we can consider them well before we actually have to use it.

[Chris is me]

Originally Posted by magnets

While I do agree that the vex cortex is probably closer to an optimal controller than the cRIO was, it is not a replacement for the cRIO/roboRIO.
The vex controller can't do image processing, it can't be programmed in LV or java, and it doesn't have an ethernet port or a CAN port. It also doesn't have an FPGA. While it may be a substitute for 99% of FRC robot controllers, there are definitely teams who do need the extra stuff.

If the choice was, hypothetically, between "have image processing offboard" and "take a really long time to boot and connect", I think nearly everyone would be in favor of the former option. I'm not saying the Cortex as is would be the perfect FRC controller, but I think making fast processing an optional feature you add on via an offboard PC (something teams already do) would allow the "base" control system to be simpler / faster / more robust / quicker.

The frustrating thing to me about adapting existing technology to FRC is that FRC has some specific requirements that are unusually important that aren't present in a lot of commercial applications. In the (admittedly very few) conversations with NI people I have had in the past, it seems they consistently underestimate the importance of quick boot time. It just doesn't seem to be a high priority in the controller design or implementation. Perhaps FIRST should have emphasized the importance of speedy boot time and quick field connections when doing their RfP for the control system.

All of the cool software things you can do with a more powerful controller are automatically far less important in my mind than making sure that the robots connect to the field in a reasonable time frame and that they never disconnect. Just my relatively uninformed two cents.

(None of this post is intended to discredit the hard work NI and its employees have put into this program. It's just some thoughts - I apologize if I step on some toes)

[jhersh]

Originally Posted by Racer26

Which, really, is the crux of my point. The cRIO costs roughly double what a Vex Cortex costs. For most teams, that's a crappy value, since the vex cortex could do the job adequately for 99% of teams

The fact that it's only half the price blows me away. I would expect it to be way less given the capabilities. Talk about a crappy value. Par for the course I guess.

[Greg McKaskle]

I'm not positive who the NI folks were, but my suspicion is that they were volunteering and taking part in the same awesome event as you were. If they could snap their fingers and shave seconds off of boot time, they likely would. But they are probably trained engineers acting in a volunteer role.

On the boot time topic, I just timed it without user code, and it is under 30 seconds -- on a cRIO, over ethernet. If you think about the topology, the cRIO has nothing to do with how the bridge/radio connects to the field. To the cRIO, it is a cable. NI didn't make the radio or write the firmware, and we have little influence over the selection criteria except that it needs to bridge ethernet. I'm not trying to pass the buck here, just pointing out that the cRIO is just one ingredient in the soup.

The RoboRIO has additional options for radio connectivity, and may I point out that the myRIO even includes an integrated radio option. As mentioned in the Q/A, radio selection is still in progress and that is because it has a big impact -- on boot times, throughput, security, price, etc. The control system team cares deeply about team experience and one should not assume that this opportunity to improve things will be wasted. One of the things I look forward to after the system is available is to publish a development blog that details the other possibilities that just weren't meant to happen due to budget, time, space, weight, etc.

On the price and capabilities topic, NI responded to the RFP with what we feel is a very exciting product to use on a robot. I will not knock an IFI controller, or the Sasquatch. Each has its strengths. In the non-Hollywood world, it is not possible for all 2600 team to agree on the ideal controller characteristics. The laws of physics and economics apply here and we don't all want the same experience. And we don't have to agree either.

Alpha testing starts a few billion milliseconds from now and that means Joe and I need to get back to work.

Greg McKaskle

[MrRoboSteve]

Originally Posted by Racer26

4 years of FRC experience with 2.4/5GHz wifi a/g/n has taught me that its an unreliable standard. Delays to matches are common. Sometimes robots refuse to connect, and they often drop connection mid match, PLUS, being such a widely accepted standard, with a large range of compatible devices, it opens the door to attacks such as what happened at Einstein 2012. They also experience issues because we're using consumer-grade electronics that were never designed for the sort of dynamic loading environment an FRC bot creates. We're using routers that were intended to sit under peoples desks at home and never move.

What you're saying was true for previous years, but the work that went into improving things for 2013 really seemed to pay off.

At the two events I CSAed at, there were no issues in qualification or elimination matches with radio root causes. We routinely ran ahead of schedule. And the third regional (week 2) I mentored at also ran ahead of schedule.

[DampRobot]

As a mechanical guy, I hope my comments aren't misplaced. I guess that I'm more of a "user" than most people on this thread, which for a normal product would be considered "developers."

First, I really have to thank the NI team. They've made my job a ton easier. The C-RIO/DSC setup was honestly quite cumbersome and took up a lot of space. Not just electronics board space, but also vertical space. Their CAD models were very complex, and added a ton of time to our CAD model rebuilds. So, replacing the two larger components with a smaller, flatter, simpler controller with logical mounting holes is awesome all around. I always wondered why the DSC and C-Rio needed to be separate, and this is a great answer to that question.

If the radio and it's power adapter could be integrated into the robotRIO, that would be a huge plus too.

Boot times aren't a huge deal for me. A few times when we're racing to get to queuing, and we have to re-deploy code, that extra time makes me sweat. But for most of the time, I hardly notice it. Maybe it's a bigger deal for the programmers, who have to develop with it, but I always assumed that they could just use the time when code was comping or the robot was booting to check CD or something.

I don't love the cost, but see the robotRIO as the same as expensive mechanical components. You can easily drop as much as the robotRIO just on decent drive gearboxes every season, and hardly anyone complains about those costs. It shouldn't be a huge deal to buy a new robotRIO every season, if you want to keep old robots running that is.

The robotRIO is overpowered (in my humble opinion). However, teams will always end up using all of an available resource when they think it could possible benefit them (CPU speed, memory, robot weight, height, motor number, etc.). Lots of teams will continue to see 100% CPU usage with the robotRIO just as they did with the C-RIO. Also, a ton of teams seem to believe that complex image processing is necessary on every robot, when in reality, 95% of teams don't or shouldn't focus on vision processing.

Good job, NI. Lower costs and faster boot times are always welcome, but in my mind, given how good of a product this is for me, I don't really care.

[Peter Johnson]

Originally Posted by DampRobot

Boot times aren't a huge deal for me. A few times when we're racing to get to queuing, and we have to re-deploy code, that extra time makes me sweat. But for most of the time, I hardly notice it. Maybe it's a bigger deal for the programmers, who have to develop with it, but I always assumed that they could just use the time when code was comping or the robot was booting to check CD or something.

I'm not sure of how LabView handles code reloads/deploys on the new OS, but at least for C++ and Java the Linux platform should make these kind of "soft" boots significantly faster (to the point of making boot times nearly moot). On VxWorks it was necessary (in almost all cases) to completely reboot the cRIO to reload user code even for C++ and Java because your user program was running as a kernel module. Assuming that robot programs run as normal user-mode (but root) programs on Linux (and I sure hope that's the case!) a "soft" reboot for C++ and Java should just consist of killing and restarting the user process (milliseconds) rather than a full OS reboot (20+ seconds).

In other words the upload/test cycle should be extremely fast (at least for C++ and Java) on Athena, assuming you don't power cycle the robot.

For the Athena Python port, I plan to take advantage of this fact to instantly reload the user program as soon as a new Python file is saved/uploaded (note: due to Python implementation memory leaks this requires restarting the entire interpreter, preventing this from working on the cRIO port, but will not be a problem on Linux).

[DonRotolo]

Originally Posted by Racer26

An interesting.. <snip> ...with some overhead for control comms.

OK, so which technology are you suggesting be used instead of "unreliable" 802.11?

Originally Posted by Racer26

Which, really, is the crux of my point. The cRIO costs roughly double what a Vex Cortex costs. For most teams, that's a crappy value, since the vex cortex could do the job adequately for 99% of teams.

Team 1676 is very proud to be in the 1%. A Cortex just would not let us run our robot the way we do. Unless you think maybe we should dumb it all down for the lowest common denominator?

Originally Posted by jhersh

The fact that it's only half the price blows me away. I would expect it to be way less given the capabilities. Talk about a crappy value. Par for the course I guess.

Requoted for truth. The IFI 'real price' wasn't cheap, either.

[Clinton Bolinger]

I don't see why the communication has to be one (Wifi) OR the other (900 mHz serial). With the technology available today FIRST should be able to implement multiple communications on the same system.

High Priority Task like the Joystick outputs to the robot, drive commands, Auton/Teleop modes, eStops, etc could communicate over a very fast booting wireless protocol similar to the Old Control Systems. The amount of data is very minimal and wouldn't need a lot of bandwidth. (Synapse or Xbee). I have personally tested a Synapse device, with a simple 2 axis joystick and two PWM outputs, to drive a robot with a boot-up and time to drive less than a second.

Low Priority Task and task that need a lot of Bandwidth could still communicate over Wifi (if teams want this functionality). This information and data would not need to be encrypted because it doesn't necessarily control the robot. If a team's wireless radio fails in a match, teams can still move and drive there robot in a open loop state.

The system could also be setup as follows:

  
     {Robot}
  |         ^  |
  v         |  v
Wifi     Synapse
  |            ^
  |            |
  |        Commands
  |            ^
  v            |
Laptop -> Process Image

For all the computer/programmers, how many bits or bytes of data is really need to send the important data to and from the robot:
-PWM - 20 Channels (160 bits)
-DIO - 26 Channels (26 bits)
-Relays - 4 dual-input channels (8 bits)
-Analog Input - 8 channels (96 bits)
-Analog Output - 2 channels (24 bits)
-Miscellaneous Bits for Auto/Teleop/Enable/Status/ etc (22 bits)

Total = ~336 Bits = 42 Bytes

Seems like Wifi might be a bit overkill for the amount of data need sent from the drivers to the robot.

Personally, I believe that the long boot-up times come from the Wireless bridge/router that we use on the robots.

-Clinton-

[AdamHeard]

I really agree with Clinton on this one.

To give FIRST the benefit of the doubt, we have no idea they aren't currently exploring that option.

It makes a huge amount of sense to have a more robust method for pure control, and use the wifi for camera, etc...

[AllenGregoryIV]

I'm actually really surprised I haven't seen anyone push for a dual radio idea before. That just makes sense.

Dashboard and anything else noncritical can all be over wifi. It also allows us to continue to be able wirelessly program the robot as well, which is a big advantage over having to tether a serial cable like the old controllers.

[techhelpbb]

Originally Posted by AllenGregoryIV

I'm actually really surprised I haven't seen anyone push for a dual radio idea before. That just makes sense.

Dashboard and anything else noncritical can all be over wifi. It also allows us to continue to be able wirelessly program the robot as well, which is a big advantage over having to tether a serial cable like the old controllers.

A dual radio option was offered as part of the RFQ proposal we sent FIRST.

It was proposed basically like what Clinton outlined above.

In fact I even built the radio module (Turtle....slow, steady and hardened).
I even made it bridge in a way that should have worked with the field.
It used COTS radio components offered from a variety of vendors to offer wide selection of frequency and performance.
Had no choice because of the short time between the announcement of the RFQ and the deadlines.

RFQ was not accepted however it was reviewed.

Originally Posted by Greg McKaskle

I will not knock an IFI controller, or the Sasquatch.

I notice that proposed solution we offered seems to be overlooked.

Not to worry I took what I built and dropped the FIRST features.
If anyone is really interested I can post the proposal we made.

I have to say however, NI has the contract, come what may until FIRST sends out another RFQ the ball is in their court.

[AdamHeard]

I think a few people in this thread need to be a bit nicer to the NI people, or they might stop communicating on chief (which is awesome that they do).

I'm not saying I agree or disagree with them in anyway, but let's not totally ruin the fact that they are willing to come on chief and interact directly with the community.