NEW 2009 Control System Released

[Astronouth7303]

Without having read the entire thread, here's some thoughts:

• No more MCC18! GCC does PowerPC, so any platform should be able to work
• How is WindRiver IDE different from Eclipse? What fancy additions from them do teams need?
• Are things like the downloader going to be open sourced (like the libraries)?
• How much control over the LCD does software have?
• How are modes implemented? How is the software (at the equivelent of the IFIlib level) structured?
• Does the PowerPC bit imply things like multitasking? Could we write some fanciful background thing to do some cool stuff?
• I like their solution for the OI. Still hackable, but no longer needing the chicklet hacks (what kind of restrictions does the USB have?)
• 8 40-amp breakers? 8???
• The Digital Side Car appears to be IFI's toy. I suspect a number of teams will like the addition of SPI
• I guess I'll have to make time to actually mentor a team this year, just to keep current
• If something segfaults, what happens to it?

Addendum:

• C++??? For real? No, NO! Word for the wise: Avoid pointers.

[artdutra04]

If they want security, then why not just use WPA2 encryption [with certificates]?

For example, for general use at driver training, demonstrations, and possibly off-season events, either a public certificate can be used or they can just operate the robots over an unencrypted network. But at every event, a unique and time-sensitive certificate is loaded onto the controllers for WPA2 authentication.

After the competition, the time-sensitive certificate deactivates, and the team can return to using the robot on unencrypted networks.

[eugenebrooks]

Authentication of each and every packet on the wireless network is far more important in this environment than the conventional notion of wireless network security.

Lets assume that the field control system, the robots, and the operator stations are all connected to each other by one ethernet cable and no outside influence is possible. This is the goal of conventional wireless network security.

You still want every packet from the field control system to be authenticated, so that the other nodes on the net can't spoof it. You also want every packet back and forth between your robot and your operator station to be authenticated so that another node on the net can't spoof this communication.

Going further, if robots on your alliance are going to communicate with each other, you what these packets to be authenticated so that spoofing can't happen, and every robot would have to use public key methods to do this so that it can publish the data required to authenticate packets coming from it.

If you are going to spend any effort on network security for the communication on the competition field, the best thing to do is assume that one of the nodes that you have allowed on the net will attempt a spoof. If you prevent that, you don't have to worry so much about what nodes get on the net.

Eugene

Originally Posted by artdutra04

If they want security, then why not just use WPA2 encryption [with certificates]?

For example, for general use at driver training, demonstrations, and possibly off-season events, either a public certificate can be used or they can just operate the robots over an unencrypted network. But at every event, a unique and time-sensitive certificate is loaded onto the controllers for WPA2 authentication.

After the competition, the time-sensitive certificate deactivates, and the team can return to using the robot on unencrypted networks.

[comphappy]

um how about you set MAC authentication on the AP, simple and fairly effective, going to take people a little while to figure out your MAC.
All of those other ones take little time to crack. And people have enough trouble with getting radios to work at home and that is straight forward. Adding certs, now you are asking for it.

Remember this is not a NSA secret project... Or is it, what have you all gotten me into.

[Adam Y.]

Originally Posted by Astronouth7303

Addendum:

• C++??? For real? No, NO! Word for the wise: Avoid pointers.

Why is that such a strange thing? Microchip was the odd man out when it came to implementing a C++ implementation on their microcontrollers.

[seanwitte]

Originally Posted by M. Krass

If we're not getting a new control system each season, I hope that we can expect lower registration fees in 2010 and beyond. I don't know how it's possible to justify charging teams the same fees while giving them fewer resources.

They may be amortizing the expense across several years, then using the remaining revenue as a license fee to support operations and maintenance.

[Tom Line]

Originally Posted by Andy L

They said 11 and 11 usually means 11... They'll release the details with time just wait a little bit.

Also don't just think of the US there are teams in Israel, Puerto Rico, Chile, Brazil, Netherlands, Great Britain, and hopefully more next year.

Guys - reread the documentation before you get too excited. This system will be able to handle multiple robots per channel. That means packetized data identified much like nat packets are identified to be sent to each computer by the router.

Also, I'm feeling slightly better about the possibilities of C - because of this statement:

-Parity between C/C++ and NI LabVIEW libraries

If NI truly sticks to that and releases a C/C++ library when they review a labview one with the same basic functionality, it will all be good.

[Gdeaver]

It looks like the power distribution pannel produces 24 volts for the compact rio. So what happens under heavy load and the 12 volt battery is pulled very low? I don't see any back up battery. I didn't see any specs on power consumption for the rio and the moduals and the access point. Did some one forget how first teams love to abuse thier motors and Batteries? Seams to me there needs to be a battery back up.

[Gdeaver]

It looks like the power distribution pannel produces 24 volts for the compact rio. So what happens under heavy load and the 12 volt battery is pulled very low? I don't see any back up battery. I didn't see any specs on power consumption for the rio and the moduals and the access point. Did some one forget how first teams love to abuse thier motors and Batteries? Seams to me there needs to be a battery back up.

[Tetraman]

Originally Posted by Pat McCarthy

The youtube video on this page reminds me of the "Powerthirst" video.

At 1:08 in that movie, they say 'Underwater exploration'

Water Game

[Greg Marra]

Originally Posted by chuckstudios

Something that upset me a bit was that they said we wouldn't be able to modify the VHDL for the FPGAs inside the new controller. That means we have no real idea of what's going on inside it, and can't unload any "special" tasks to it. Then in the same breath, they say the libraries will be hosted on a Sourceforge-alike site. That's not hypocracy, I swear >_>!

I've been using cRio's this semester. Compiling FPGA code takes from 5 minutes for a simple (simple!) program, to around 15 for a still-not-that-complex-but-does-more program. It finally made this xkcd comic make sense.

[synth3tk]

Originally Posted by Gdeaver

It looks like the power distribution pannel produces 24 volts for the compact rio. So what happens under heavy load and the 12 volt battery is pulled very low? I don't see any back up battery. I didn't see any specs on power consumption for the rio and the moduals and the access point. Did some one forget how first teams love to abuse thier motors and Batteries? Seams to me there needs to be a battery back up.

First off, this is still early in it's stage so a lot of that is being worked out. And just like the sidecar isn't covered, maybe they did it just for show. Patience, people. Patience.

Secondly, dude, double post. Plz baleet won, kthnxbai.

Originally Posted by Greg Marra

I've been using cRio's this semester. Compiling FPGA code takes from 5 minutes for a simple (simple!) program, to around 15 for a still-not-that-complex-but-does-more program. It finally made this xkcd comic make sense.

Did they say anything about speeding it up a bit, because I know our programmer will go nuts trying to compile last-minute code. Especially if we're working with complex robot code, I don't want to wait an hour to see if it works.

Also, I love xkcd. That one didn't make sense to me either.

[Adam Y.]

Originally Posted by Greg Marra

Compiling FPGA code takes from 5 minutes for a simple (simple!)

Just like all platforms. What you wrote isn't a strike against National Instruments more than a perfect example as to why HDLs are different from conventional computer languages. I was doing research on FPGAs and found that other people were amazed at the length of time for a simple VHDL example to compile. It makes sense because the compiling process isn't the same for a HDL as opposed to a language like C++.

[Bongle]

Originally Posted by JesseK

Essentially, if they gave out how they were deciding to ensure security, someone somewhere would be that much closer to hacking into it.

Security through obscurity is an awful, awful way to approach security. Once someone figures out your algorithm (and someone will), then it is game over. If we assume that the attackers are going to figure out how you're securing it anyway, why not let people with good intentions know the algorithm as well so they can point out potential flaws?

The strength of a security system should lie in the attacker not knowing an easily-changed key, not in them not knowing the algorithm.

Originally Posted by comphappy

um how about you set MAC authentication on the AP

For reasons that eugenebrooks has covered (post #120), (post #123), namely being able to identify each node and prevent spoofing, simply filtering MAC addresses may not be enough. Both nodes that are supposed to be connected and/or a rouge node (say a malicious fan), could spoof a MAC address.
I agree that MAC filtering would probably suffice for differentiating between each robots traffic. However, I feel that wireless security is an important aspect to consider since, in the eventuality that there was a cracking attempt on the network, nobody would want to have their team and robot suffer. Network security at a FIRST event is once instance where I feel the Regan saying of "Trust but verify" is quite pertinent.
Also, a second on Bongle's post as well; security through obscurity is one of those funny things that I've read about working out poorly more than a few times.