NEW 2009 Control System Released

[qnetjoe]

As supected the 2009 FRC Controler is from NI. It is a National Instraments Compact RIO. It is based on the CRIO-9074, it has a 400 Mhz Processor, 128 MB RAM, 8 Slot Chassis, VXWorks :-). More Details can be found here:

http://decibel.ni.com/content/docs/DOC-1662

[Vikesrock]

Leaked a little early, thanks for the update!!!!

802.11 support including wireless debugging
Programmable in C and NI Labview
Real-time vision processing

I can't wait to see the presentations and information that comes out tomorrow to see what this thing can really do.

[SpaceOsc]

Leaked a little early, thanks for the update!!!!

802.11 support including wireless debugging
Programmable in C and NI Labview
Real-time vision processing

I can't wait to see the presentations and information that comes out tomorrow to see what this thing can really do.

USB joysticks and the ability to map track and record its movements, gives a whole new outlook on autonomous :ahh:

http://www.youtube.com/nifirstrobotics

[Jimmy Cao]

Wow... This is awesome! I really can't wait the 3 hours to see it being shown off now =D

802.11 communication sounds great... no more radio problems!

The entirely modularized design is so interesting. I can't wait to play with it next year.

[Gamer930]

Wow. Just getting up for the day here at Sheraton Atlanta Hotel and wanted to check the times for the sneak peek and you guys ALREADY found it :D:D Can't wait!! Looks to be a very nice compact system. Notice the input voltage 19v to 30v?? We going to be running a 24v system??

[eitang]

more info
http://decibel.ni.com/content/docs/DOC-1663
http://www.slideshare.net/nifirstrobotics/ni-first-robotics-controller-training/
second slide is a pic of frc robot with new system

[Pat McCarthy]

The youtube video on this page (http://decibel.ni.com/content/community/first;jsessionid=82a40f1a30d63dfd74a6370d490295488 afd65b7a964.e3mNbNaPb3iNe34TbxaPbhqPbNr0n6jAmljGr0 ) reminds me of the "Powerthirst" video.:D

[wilsonmw04]

I cannot wait to put this in the the hands of my students. This is VERY exciting.

[Billfred]

One thing I found interesting is here (http://www.slideshare.net/nifirstrobotics/ni-first-robotics-controller-training/); the motors in the picture on the second slide are being powered by Victors. Of course, they're also running AndyMark omniwheels in the picture, but it might be a point of data. (I haven't seen anything about how they're driving motors with this system, though I did just wake up.)

I'm not seeing a lot of information about the OI side of things in these documents, other than the mention of a graphical dashboard (and one shot of what looks like a dongle in LabVIEW). I'm kinda hoping for more information here (and for someone else's laptop to go in the alliance station if the laptops are the ones running the show, if this year's hybrid period was any indication).

[MikeDubreuil]

I wonder if we can buy one early? This (http://sine.ni.com/nips/cds/view/p/lang/en/nid/203964) is a close match... $3k?! Without any add on modules and without a development kit. FIRST just got a whole lot more expensive :rolleyes:

[wilsonmw04]

I have a feeling FIRST is getting a break on the price for this new system, Mike.
PS: that's the larger model for "high end" applications. I bet we are going to get the 4 slot model starting at ~$700.
http://sine.ni.com/nips/cds/view/p/lang/en/nid/14156

Or is that just the chassis?

[Renee Becker-Blau]

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

:yikes: Wow, that video is really amusing. Look's like we'll be having mini robotic meetings through out the day talking about it.

Renee

[Roger]

If you combine Pat's video with Mike's prices -- reminds me of Crazy Eddie (http://www.pocketcalculatorshow.com/crazyeddie/) -- "His prices are insane!" (Look at those great computers in the second photo!)

But I agree, we'll be getting a lower priced custom module. Should be fun.

[Mr. Lim]

Ruggedness such that we can reuse the same controller year after year?

I'm curious to know if they are considering not giving us a new controller each year? It's a nice luxury...

[whytheheckme]

http://www.youtube.com/watch?v=Gkft479ARTk

OH MY GOD! THIS IS MY DREAM COME TRUE!!!!!!!1111oneone lim(sin(x)/x) x->0

I can die in peace now!

I AM SO EXCITED!!!!!!!!! :D :D :D :D :D

JACOB!!!!~~!~!!

[BHOP]

WOW

[Adam Y.]

It's running the same operating system that Spirit and Opportunity uses. Heh.. I was right when I guessed that FIRST was trying to unify the three programs.

[basicxman]

just saw the webcast...speechless...amazing!!!

[jwfoss]

looks good from the webcast although they didn't get the tracking to work to shoot at the target. I wonder how much it weighs compared to the whole old system, it looks like it might be bigger also?

[Hiteak]

wow. I wish I could play around with the new system now. You can only image where the games will be going now with the new control system.

[Adam Y.]

One thing I found interesting is here (http://www.slideshare.net/nifirstrobotics/ni-first-robotics-controller-training/); the motors in the picture on the second slide are being powered by Victors. Of course, they're also running AndyMark omniwheels in the picture, but it might be a point of data. (I haven't seen anything about how they're driving motors with this system, though I did just wake up.)


There is an operator interface (http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf) Also, Victors may be used next year according to this. Aparently, there was no animosity between FIRST and IFI.
But I agree, we'll be getting a lower priced custom module. Should be fun.
No. It's the controller that Mike linked to according to the above FAQ.

[Scott L.]

There is an operator interface (http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf)

No. It's the controller that Mike linked to according to the above FAQ.


I so want one of these :D
I can see an arena control system that is almost purely software based, maybe another NI controller in the arena control box. :)

I hope the price is real cheap for FIRST Teams.

[Greg Marra]

I've played around with a cRio as part of my Robotics course this semester, and they are pretty awesome. I think teams are going to have a good time developing complex software based on top of these. LabView takes a few days to get used to, but its very powerful and allows you to think about your code in a very different way than writing C. I think next year we're going to see robots doing things in autonomous no one ever could have imagined with the current control system.

[ebmonon36]

looks good from the webcast although they didn't get the tracking to work to shoot at the target. I wonder how much it weighs compared to the whole old system, it looks like it might be bigger also?

Assuming it is an 8-slot and it wasn't weight optimized for FIRST:

Weight (8-slot, typical w/ modules) : 2.48kg (5.46 lb)
Dimensions (8-slot) 274 by 88.1 by 88.1 mm (10.79 by 3.47 by 3.47 in.)

[Mr. Lim]

Ruggedness such that we can reuse the same controller year after year?

I'm curious to know if they are considering not giving us a new controller each year? It's a nice luxury...

I'll answer my own question:


Q Will I get a new controller in each year’s kit?

A Because of the ruggedness of CompactRIO, teams will be able to reuse their controller in competition years beyond 2009. However FIRST may decide to introduce new cRIO modules to the system specific to a future year game design.


from

http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf

Not that I think it's a huge deal, but it was very nice accumulating more than a few sets of controls over the years at no extra charge. Prototyping and practice robots became much easier to do.

[Freddy Schurr]

Is there video of Dean Kamen introducing it?

[Mike AA]

Supposedly the videos will be up on FIRST's website around noon.

-Mike

[whytheheckme]

Check out the stuff in the lower righthand corner of this page:

http://first.wpi.edu/FRC/cstechnical.html


All of the components with High-res images are there!!!

And regarding weight,

Weighs approx 2 lb (chassis only)


This is the most exciting day of my life.
-Jacob

[Taylor]

That sound you heard was the jaws of my students hitting the floor.

[Richard Wallace]

The WPI demo robot (http://first.wpi.edu/WPIdemobot2.jpg) is very cool.

[Kyle Fenton]

Does anyone know if this is mac and linux compatible. I know that there is a Labview IDE for mac os x, but is there a compiler for the new control board

[Bongle]

Hmmm... If it's using 802.11, I wonder what effect that will have on in-pit wireless networks (I wonder if it is why they weren't allowed in Atlanta)

Cool system though. I hope I'm near a team next year so I can play with it some.

[writchie]

Hmmm... If it's using 802.11, I wonder what effect that will have on in-pit wireless networks (I wonder if it is why they weren't allowed in Atlanta)

Cool system though. I hope I'm near a team next year so I can play with it some.

The docs suggest there will be a different wireless modem for the competition.

I do hope that whoever provided the answers in the FAQ isn't engineering the wireless. 802.11 does NOT have 11 clear channels. There are only 3 non-overlapping channels in 802.11b/g.

Also the estimated date of availability to teams "KICKOFF", suggests that this program has already seriously slipped. That's not an estimate - its a drop dead deadline.

[scirobotics]

man, this is gonna be hge, have any of you guys thought of the posibilities?

too bad that we can't program ahead now, due to the whole system changing. doe sthis mean we only have 6 weeks to really get programming done?

[Jonathan Norris]

They are talking alot about how rugged the controller is... but it looks like every other component is exposed. Like the Power distribution, IO, Digital side car are basically just electrical boards. Hopefully these arn't the final product, the controller looks sweet and all.

[laultima]

One thing I am extremely exited about is the new power distribution block. Last year the PDB was the bane of our teams existence.
They are talking alot about how rugged the controller is... but it looks like every other component is exposed. Like the Power distribution, IO, Digital side car are basically just electrical boards. Hopefully these arn't the final product, the controller looks sweet and all.
Thats something that worries me about the new OI/Driver Station. Theres absolutely no protective housing. Though from the picture here http://first.wpi.edu/FRC/driverstation.html, I don't see any of the bottom buttons or headers labeled, making me think there will eventually be an enclosure for it.

[writchie]

They are talking alot about how rugged the controller is... but it looks like every other component is exposed. Like the Power distribution, IO, Digital side car are basically just electrical boards. Hopefully these arn't the final product, the controller looks sweet and all.

If you dig down to the photos you will see that there are fairly well insulated cases for everything. Electrically, its now a kitbot and FRC will now be a field of LABVIEW demobots.

It remains to be seen whether there will be any viable C/C++ platform possible for 2009. Certainly not if you can't get your hands on anything until kickoff.

[eitang]

here is the pic of a temp case for the driver station
http://first.wpi.edu/driver_station_in_temp_case.jpg

[Mr. Lim]

We can all hope that they did something similar to when we switched controllers in 2004.

Teams received the EDU-RC which was a smaller footprint version of the new RC. It was functionally the same, and would later become the foundation of the VEX controller.

Based on today's FTC announcement, one would wonder if we couldn't do the same with the new FTC controller? I haven't heard much on that front... but if they use the same programming toolchain, it could happen.

[writchie]

We can all hope that they did something similar to when we switched controllers in 2004.

Teams received the EDU-RC which was a smaller footprint version of the new RC. It was functionally the same, and would later become the foundation of the VEX controller.

Based on today's FTC announcement, one would wonder if we couldn't do the same with the new FTC controller? I haven't heard much on that front... but if they use the same programming toolchain, it could happen.

The two architectures are completely different. It appears the only commonality would be through labview.

You can get started with the new FRC control system stuff now. The following are current prices:

cRIO 9074 - $2999
Power Supply & Cables $249
9201, 9403, and 9472 Modules and Cables $1219
Subtotal Total Hardware $4467

Software:

Labview for Windows $4099
Labview Real-Time Module $2499
Labview FPGA Module $2499

Subtotal Software $9097

Total $13,564

The above doesn't include the custom undocumented digital sidecar so the above would only get you started on the tool chain and sensor platforms.

[whytheheckme]

MK, thought out of the blue.

I remember on one of the Control System prediction forms, someone from intelitek said that they couldn't say intelitek's involvement for next years control system, but that they were very excited about it....

Have we heard anything about easyC?

Jacob

[Roboj]

I do hope that whoever provided the answers in the FAQ isn't engineering the wireless. 802.11 does NOT have 11 clear channels. There are only 3 non-overlapping channels in 802.11b/g.


You are correct that 802.11b/g only have 3 clear channels. However, the FAQ did not say b or g were being used. Other 802.11 variants (such as 802.11a) do have 11 non-overlapping clear channels.

[dcbrown]

The two architectures are completely different. It appears the only commonality would be through labview.

You can get started with the new FRC control system stuff now. The following are current prices:

cRIO 9074 - $2999
Power Supply & Cables $249
9201, 9403, and 9472 Modules and Cables $1219
Subtotal Total Hardware $4467

Software:

Labview for Windows $4099
Labview Real-Time Module $2499
Labview FPGA Module $2499

Subtotal Software $9097

Total $13,564

The above doesn't include the custom undocumented digital sidecar so the above would only get you started on the tool chain and sensor platforms.

Also doesn't include the "bumps" for the i/o modules or the cable for the digital side car, or the wireless access point listed as part of the cRIO-FRC kit.

Discounting is steep - to start NI offers 30% discount for 100 or more of same config ordered in a 1 year period. Going to 4 slot chassis from 8 saves $300. The FPGA size is one of the more sensitive pieces. Going from a 1M to 3M FPGA is an increase of $1700.

But anyway you slice it, this is an expensive piece of hardware. If teams want a 2nd one for proto work, its going to put a serious dent in the budget. This could become a factor between have and have-not teams in terms of which have deep pockets and are able to afford a 2nd controller setup unless teams are able to order a cRIO-FRC at discounted price. Of course, if teams can come up with ~$4000 needed now to purchase one they could go that route. But, without the pwm breakout board (digital sidecar), it would be difficult to build a fully functioning robot.

Debug is either via LabVIEW or Wind River IDE. But in order to use Wind River Workbench IDE you need a full license for the WR IDE -- but that isn't listed on the description of what's included in the new controller set.

[Adam Y.]

Of course, if teams can come up with ~$4000 needed now to purchase one they could go that route. But, without the pwm breakout board (digital sidecar), it would be difficult to build a fully functioning robot.


It's actually not $4000. The academic price is significantly cheaper but still would put a dent in the budget.

[lingomaniac88]

I was looking at some stuff on WPI, and I'm wondering about something. Looking at the driver station, I noticed that there are some extra pins for digital input, digital output, and analog. What are these meant for? Are they meant for custom buttons and switches to control our robots?

I want to make sure I know how things are hooked up. If one end of a PWM cable goes into a Victor speed controller, where does the other end go? Does it go into the SideCar? If so, where? If not, does it go right into the analog module? What about for Spike relays? It would be really disappointing to have a well-built robot that can't do a darn thing because it's not hooked up properly.

[ericand]

Does anyone know if this is mac and linux compatible. I know that there is a Labview IDE for mac os x, but is there a compiler for the new control board

WindRiver Workbench is being provided as a development environment. Wind River is the company that produces vxWorks, the realtime OS that is running on the new controller. I know that workbench works on multiple hosts (Unix, Linux, Windows). It remains to be seen exactly what sort of support we get for this from Wind River, but I've asked my contacts there to look into it.

It would be really cool if we get access to Wind River tools beyond the IDE for compilation. With just the compilation support, we would get static code analysis, and incremental build support. Windriver has additional tools for memory leak detection, code profiling, and real time diagnostics.

Check out WindRiver.com for info about what might be possible. In particular the scope tools (Memscope, Profilescope, Stethoscope).

[Mike AA]

I was looking at some stuff on WPI, and I'm wondering about something. Looking at the driver station, I noticed that there are some extra pins for digital input, digital output, and analog. What are these meant for? Are they meant for custom buttons and switches to control our robots?

I want to make sure I know how things are hooked up. If one end of a PWM cable goes into a Victor speed controller, where does the other end go? Does it go into the SideCar? If so, where? If not, does it go right into the analog module? What about for Spike relays? It would be really disappointing to have a well-built robot that can't do a darn thing because it's not hooked up properly.


You do realize that EVERYONE just found out exactly what this thing is today? Wait for time to pass until manuals are printed and sent out or links to the product manuals. You could always visit NI and read about the overall platform.

-Mike AA

[dipmeinaluminum]

the old one aesthetically looked sexier, and i got it tattooed on me, im not getting any new control sysytem tattoos any time soon :p but im glad we are moving in the fast lane.

[Richard Wallace]

the old one aesthetically looked sexier, and i got it tattooed on me, ....Ouch! OK, I surrender. You win the award for most commitment to the IFI control system. :eek:

[wilsonmw04]

But anyway you slice it, this is an expensive piece of hardware. If teams want a 2nd one for proto work, its going to put a serious dent in the budget. This could become a factor between have and have-not teams in terms of which have deep pockets and are able to afford a 2nd controller setup unless teams are able to order a cRIO-FRC at discounted price. Of course, if teams can come up with ~$4000 needed now to purchase one they could go that route. But, without the pwm breakout board (digital sidecar), it would be difficult to build a fully functioning robot.

From the FAQ from http://first.wpi.edu/FRC/csoverview.html :

Q How can I buy an additional controller? How much will it cost?
A Teams will be able to purchase one additional control system each year at a heavily reduced price. The exact details are still being finalized.

[tseres]

the only thing that worries me os that, if new RC's dont get shipped out before kickoff for teams to learn, there's gonna be a lot of powerhouse teams really lagging behind.

[Mr. Lim]

For the life of me, I swore I saw that there will be a 2 hour training session for the new control system at 5pm today down in Atlanta. I can't remember where I saw this. Am I hallucinating, or does anyone else know what I'm talking about?

More importantly, is this going to be webcast? Or available online at a later date?

[lingomaniac88]

You do realize that EVERYONE just found out exactly what this thing is today? Wait for time to pass until manuals are printed and sent out or links to the product manuals. You could always visit NI and read about the overall platform.

Yes, I do realize that. I just wanted to express my questions/concerns, and I wanted to know how everyone else thinks this goes together. I didn't expect a definitive answer from anyone, except if that person has some knowledge of how the cRIO works, say, a person affiliated with NI or someone who worked with the demo robots this morning.

[writchie]

You are correct that 802.11b/g only have 3 clear channels. However, the FAQ did not say b or g were being used. Other 802.11 variants (such as 802.11a) do have 11 non-overlapping clear channels.

While I'd love to see them using 802.11a, I've never seen a reference to 802.11a that involved 11 non-overlapping channels. IIRC it's 8 in North America and 4 in Asia, at least for legal operations. I guess we'll know soon enough.

I do hope they are not intending to operate AP's in the robots and that these boxes will be client side bridges.

[ebmonon36]

Yes, I do realize that. I just wanted to express my questions/concerns, and I wanted to know how everyone else thinks this goes together. I didn't expect a definitive answer from anyone, except if that person has some knowledge of how the cRIO works, say, a person affiliated with NI or someone who worked with the demo robots this morning.


Chasing down the wires in this picuture: http://first.wpi.edu/FRC/cstechnical.html

It would appear that the victors are connected to the Sidecar

[Richard Wallace]

... I do hope they are not intending to operate AP's in the robots and that these boxes will be client side bridges.Yeah, I wondered about that, too. This picture (http://first.wpi.edu/FRC/cstechnical.html) indicates an AP.

Can anyone who is in Atlanta now and has seen the demonstrations confirm that?

[Tom Line]

Initial impressions....

I like the power and the ability to do floating point and wireless downloading. The ability to realtime monitor everything without printf's will make debugging much easier as quicker as well and that will allow for a quicker development cycle. That power and ease is coming at an expense, though.

It comes in at just over 5+ pounds for just the cRio, not including the bumpers and digital sidecar. I think people are going to be surprised when they actually get this thing in their hands and realize they just lost a couple pounds of potential robot compared to the old system.

System placement is likely to be more difficult as well. With the slim form factor of the existing equipment, I've made the comment several times to the mechanical team that they can do anything they need to do and we'll work around it - not so anymore.

Those are all small gripes though - because the system looks pretty awesome. My biggest worry is the software we're going to start out with. If we don't have ready-made function blocks for the wiz-bang "auton recording" and image recognition - along with functions like the gyroscope, quadrature encoders, etc, many teams are going to have a very very difficult time. I'd wager 1/2 the teams couldn't do what they do now without Kevin or other's code to help them. The lack of time with a C IDE is going to hurt a lot of teams.

If you haven't done Labview before, it's a total shift in thinking when you program. I'm not sure I like being semi-locked into the environment. IF that is what ends up happening.

The teams who can afford to pony up the $$'s for the extra system for a practice bot are going to be hugely ahead of the curve next year. The handful that can pony up cash for a system right now are going to be downright scary.

So - I'm excited about the potential, but nervous about potentially being locked into a development environment that I've never been particularly fond of. I wonder - how many school have classes with Labview.....

[writchie]

Chasing down the wires in this picuture: http://first.wpi.edu/FRC/cstechnical.html

It would appear that the victors are connected to the Sidecar

From the tech specs on the sidecar it appears that it provides the pwm drivers and power for the PWM's (when connected to servos). It looks like it may also have 8 relay drivers and 14 TTL GPIO's. In other words, its basically most the present controller except for the $15 PIC.

The SPI which is marked (SPI/I2C) is a mystery. Hopefully this goes to a hardware based SPI and I2C controllers so there can be some hope of $50 instead of $500 sensors.

It's very nice to see friction lock connectors on the PWM. Too bad this didn't extend to the other I/O's. It's for 2009 afterall, hotglue shouldn't be required to keep wires from falling out ;)

[Richard Wallace]

For the life of me, I swore I saw that there will be a 2 hour training session for the new control system at 5pm today down in Atlanta. I can't remember where I saw this. Am I hallucinating, or does anyone else know what I'm talking about?

More importantly, is this going to be webcast? Or available online at a later date?You're not crazy. The two hour training session (for mentors) was announced in an email blast from FIRST, linked in another thread (http://www.chiefdelphi.com/forums/showthread.php?threadid=66998).

[MrForbes]

From the tech specs on the sidecar it appears that it provides the pwm drivers and power for the PWM's (when connected to servos). It looks like it may also have 8 relay drivers and 14 TTL GPIO's.

this should be a plug in module, not an add-on....I wonder if they're working on it? The slideshow seems to indicate that the sidecar is a prototype...we can hope...

[Adam Y.]

.

It comes in at just over 5+ pounds for just the cRio, not including the bumpers and digital sidecar. I think people are going to be surprised when they actually get this thing in their hands and realize they just lost a couple pounds of potential robot compared to the old system.

That's an engineering tradeoff. As much as I loved the old system it was fairly fragile. This thing seems invincible to anything we can do to it.

[writchie]

Initial impressions....

If you haven't done Labview before, it's a total shift in thinking when you program. I'm not sure I like being semi-locked into the environment. IF that is what ends up happening.

The teams who can afford to pony up the $$'s for the extra system for a practice bot are going to be hugely ahead of the curve next year. The handful that can pony up cash for a system right now are going to be downright scary.

So - I'm excited about the potential, but nervous about potentially being locked into a development environment that I've never been particularly fond of. I wonder - how many school have classes with Labview.....

I share nearly all of your sentiments.

I don't consider the proprietary Labview Real-Time environment to be anything even close to mainstream and it appear that all of FIRST is now wedded to the Labview programming paradigm. I see little more than lip service to the C/C++ development possibilities. We'll see what shows up in the next few weeks.

[Mike AA]

Its now well past noon and there still aren't any videos of the revealing. Were the only videos the ones already posted. Did anyone watch the webcast earlier today on curie and record it?

-Mike

[wilsonmw04]

I share nearly all of your sentiments.

I don't consider the proprietary Labview Real-Time environment to be anything even close to mainstream and it appear that all of FIRST is now wedded to the Labview programming paradigm. I see little more than lip service to the C/C++ development possibilities. We'll see what shows up in the next few weeks.

guys, relax :-)

We have a pretty darned cool new system in the works. A lot of my fears have been laid to rest. programing will come in time. They have already said that we will be able to use C/C++ to program. I have no doubt that the FRC community will be get to work and figure out a fantastic library of code for everyone to use within one year of release. I know some of the older, more established teams are worried about losing ground to younger team. Isn't a more even playing field, no matter how short lived it is, a good thing?

[RyanJK]

This new system is gonna be awesome! I really liked the old IFI system, but I really think this new system is gonna be better. I'm really excited for wireless debugging over wi-fi. Also, from a perspective of preparing for our future, National Instruments is a very big company with a lot of presence in the engineering field, and this system will prepare us for the future where we will all probably work with National Instruments products.

All the features sound great, but my one question is, theoretically, if the control system was on and connected to a 802.11 hotspot, could you have your laptop connected to a 802.11 hotspot and use the wi-fi to wirelessly program the control system? And I'm not thinking of across the room programming, I'm thinking of the laptop and robot being in separate hotspots programming, let's just say, the robot is in Detroit and the laptop is in Atlanta! I know that similar things have been done in different fields, but did NI put that capability into the system?

Overall, this will be quite a leap forward with FIRST, I only wish I could have seen the testbed robot in Atlanta (but no, I had to listen to a boring health lecture!) ;)

[writchie]

this should be a plug in module, not an add-on....I wonder if they're working on it? The slideshow seems to indicate that the sidecar is a prototype...we can hope...

From blowing up the pictures the $50 sidecar hooks into a 9203 module ($349 list) using a $149 (List) cable. The module provides 32 i/o's which is what the 10 + 8 + 14 add up to.

[Richard Wallace]

...All the features sound great, but my one question is, theoretically, if the control system was on and connected to a 802.11 hotspot, could you have your laptop connected to a 802.11 hotspot and use the wi-fi to wirelessly program the control system? And I'm not thinking of across the room programming, I'm thinking of the laptop and robot being in separate hotspots programming, let's just say, the robot is in Detroit and the laptop is in Atlanta! ...Hmm, so we could take a mechanical pit crew to the actual competition venue, while the programmers go to Starbucks and fix all the software problems from there?:cool:

[billbo911]

Hmm, so we could take a mechanical pit crew to the actual competition venue, while the programmers go to Starbucks and fix all the software problems from there?:cool:


Finally somebody understands how I roll.:p

[Vikesrock]

That's an engineering tradeoff. As much as I loved the old system it was fairly fragile. This thing seems invincible to anything we can do to it.

The other thing with the weight is who says it is 5 less pounds of robot than can be used? Did anyone think FIRST might have noticed the weight differences. Perhaps the weight limit will be raised 5 lbs. next year to offset the increase.

[tseres]

PREDICTION TIME!!!!!!

my prediction:
in previous years (including this year), elite teams have been defined by mostly previous experience, mechanical design, and some software development. with this new PLC running the robot, for the most part, i'd say the majority of teams will be somewhat in the dark until one is shipped out. next year, i predict that what will make or break all of the veteran teams (therefore leveling the playing field) will be how well they can learn this new system.

for rookie teams, things shouldn't be much different, as they still have to learn the entire system. but, for non-rookie teams, i know for me, the biggest challenge will be learning the new system, essentially putting me in the same position as a rookie team. for this year, at least, i think EVERY team, rookie or not, will have EXACTLY the same chance (or better odds) at success, which, in my opinion, is AWESOME!!

[lingomaniac88]

Regarding the speed controllers being hooked up to the SideCar:
That's fine, but what do we do with the pins on the analog input module? I doubt it's supposed to be a non-functional decoration...
http://first.wpi.edu/analog_bumper_side_in_case.jpg

And I have a feeling that some party will release default code as a starting point for novice teams. Not starting everyone with some code to work with would create a huge imbalance between some teams, and I don't think FIRST wants that. Someone is going to write default code to start people off. Gracious professionalism. Need I say more?

[bcieslak]

Looks like a busy summer for the mentors..Start putting together your programming and electrical curriulums now.

Brian

[MrForbes]

From blowing up the pictures the $50 sidecar hooks into a 9203 module ($349 list) using a $149 (List) cable. The module provides 32 i/o's which is what the 10 + 8 + 14 add up to.

I assume you meant 9403 not 9203?

Anyways...my vague point was that it seems a bit odd to use a controller that requires plug in modules for I/O, and these plug in modules require further custom plug in modules to actually interface with the stuff on the robot.

I guess it simulates the research world pretty well, but not the consumer product world.

Fortunately we're a bright bunch of folks and we'll make it work!

[RyanJK]

About the playing field being leveled is true.

It's kind of a bummer that this came out now for us. Just after we get used to working with the IFI system, a new system comes out. It really doesn't help that our team is so small, and we are going to lose all of our programmers because they graduate this year and are going to colleges out of state. :ahh: I'm gonna work really hard on learning C and how to program this system over the summer, because I think that next season, the teams that perform really well well be the ones who can master this code during the off-season.

Hopefully the summer will be enough to get a grasp on this! :(

[Vikesrock]

Regarding the speed controllers being hooked up to the SideCar:
That's fine, but what do we do with the pins on the analog input module? I doubt it's supposed to be a non-functional decoration...
http://first.wpi.edu/analog_bumper_side_in_case.jpg
=

Input analog things? Potentiometers, gyros, accelerometers, etc.

[billbo911]

Looks like a busy summer for the mentors..Start putting together your programming and electrical curriulums now.

Brian

That has already begun, well tried to begin:) Still waiting on the training videos. In time, they will be up.

My biggest question right now is, what ver. of LABView will we be using and where can we get our hands on a copy soon. If it is the same as was in the 2008 KOP, cool, if not, then we will need it soon.

BTW, did you notice on the sidecar that the PWM connectors are completely different. Time to stock up on new pins and connectors.

[bcieslak]

That has already begun, well tried to begin:) Still waiting on the training videos. In time, they will be up.

My biggest question right now is, what ver. of LABView will we be using and where can we get our hands on a copy soon. If it is the same as was in the 2008 KOP, cool, if not, then we will need it soon.

BTW, did you notice on the sidecar that the PWM connectors are completely different. Time to stock up on new pins and connectors.

Looking forward to comparing notes...I'm not familiar with NI's product but have developed PLC's SLC's and RIO for Allen Bradley. Should be interesting..

[writchie]

I assume you meant 9403 not 9203?

Anyways...my vague point was that it seems a bit odd to use a controller that requires plug in modules for I/O, and these plug in modules require further custom plug in modules to actually interface with the stuff on the robot.

I guess it simulates the research world pretty well, but not the consumer product world.

Fortunately we're a bright bunch of folks and we'll make it work!

Your right - I meant 9403.

The PWM's and servos generally need higher current drivers as well as the power source for the servos. I think their idea is to keep only standard NI components plugged into the chassis with all non-NI parts external.

Yes is this is more like a platform for research/academia but also suited for one-offs and low volume which, after all, is what we are.

There is no question that it's neat hardware. The open issue is how well it can help achieve the mission of first when a hands-on controller is $6K instead of $300.

[lingomaniac88]

Input analog things? Potentiometers, gyros, accelerometers, etc.
Oh, yeah. After all, it's an analog input module, so its purpose would be to receive data. The PWM cables that hook up to speed controllers would be output.

I guess I was worried about how all the data would be transferred. There's only so much you can do with 37 pins. But hey, the tether cable we've been using for the past few years only required 9 pins to transmit all that data. Why am I worrying so much?

[writchie]

guys, relax :-)

We have a pretty darned cool new system in the works. A lot of my fears have been laid to rest. programing will come in time. They have already said that we will be able to use C/C++ to program. I have no doubt that the FRC community will be get to work and figure out a fantastic library of code for everyone to use within one year of release. I know some of the older, more established teams are worried about losing ground to younger team. Isn't a more even playing field, no matter how short lived it is, a good thing?

I don't think the issue is at all about level playing fields. It's about how each teams program can adjust if possible to such a major change. The most scary thing is:

Q When will the new controller be available for teams?
A FIRST is continuing to work out the logistics of the exact availability date, but it will be no later
than kickoff for the 2009 season.


At first glance it looks like we use LABVIEW or skip the 2009 season. Use LABVIEW in FTC or forget about synergies. I hope very much that this isn't the case but it sure looks like it from the available information.

Some teams need to make budgets and other program decision in the next few months. Some teams need to decide how many FTC - how many FRC (if any) or how many in other programs. Hopefully we will see more information soon to allow such decision to be made.

[CyberWolf_22]

I am excited about the new controller I think it will make the FIRST competition better in the long run but next year I feel will have several major headaches.

Namely do we know what company is manufacturing the custom parts for us like the bumper modules, driver station, and the sidecar?
These prototype cases and modules all seem slightly flimsy compared to the 50g shock rated cRIO.

[billbo911]

I guess I was worried about how all the data would be transferred. There's only so much you can do with 37 pins. But hey, the tether cable we've been using for the past few years only required 9 pins to transmit all that data. Why am I worrying so much?

Would you be surprised to find out it only used 3 wires: Tx, Rx and gnd.:yikes:

[Adam Y.]

At first glance it looks like we use LABVIEW or skip the 2009 season.

Why do you honestly think you won't be able to program in C? As far as I can tell there is just as much information about the Labview programing as there is programing in C/C++.

[lingomaniac88]

Would you be surprised to find out it only used 3 wires: Tx, Rx and gnd.:yikes:
Yes. I would be.

Thanks, everyone, for answering most of my questions.

[tseres]

on a side note, it was either on the FIRST website or the NI site, but there will be a special version of LabVIEW available for teams next year to use with this.

[NCollins]

You are correct that 802.11b/g only have 3 clear channels. However, the FAQ did not say b or g were being used. Other 802.11 variants (such as 802.11a) do have 11 non-overlapping clear channels.

No IEEE 802.11 b/g has 11 channels in the U.S. and Canada. The reason you cannot use them all at once is that adjacent channels overlap this gives you 6 channel that can be run on top of each other. Or sequenced overlap of 1,3,5,7,9,11,2,4,6,8,10 in one dimension.
or
____1
__3___5
7___9___11
__4___2
____6
in two dimensions

[Spider-Man]

That has already begun, well tried to begin:) Still waiting on the training videos. In time, they will be up.

My biggest question right now is, what ver. of LABView will we be using and where can we get our hands on a copy soon. If it is the same as was in the 2008 KOP, cool, if not, then we will need it soon.

BTW, did you notice on the sidecar that the PWM connectors are completely different. Time to stock up on new pins and connectors.

The PWM connectors require the exact same cabling as before. They just have the added benefit of friction-based locking. Also, notice that there are lots of vast lengths of space in between the connectors.

[writchie]

No IEEE 802.11 b/g has 11 channels in the U.S. and Canada. The reason you cannot use them all at once is that adjacent channels overlap this gives you 6 channel that can be run on top of each other. Or sequenced overlap of 1,3,5,7,9,11,2,4,6,8,10 in one dimension.
or
____1
__3___5
7___9___11
__4___2
____6
in two dimensions

There are only 3 NON-OVERLAPPING CHANNELS for b/g because the channels are 5 MHz wide and 802.11b/g occupies a little more than 20mhz. The channel number refers to the center frequency. You can use center frequency on channels 1, 6, 11 without mutual interference. Some 802.11n signals are 40 Mhz wide. The channels for 802.11a are 10 mhz wide and every other channel can be used to provide 8 NON-Overlapping channels.

In 802.11b/g in the U.S. you can use any of 11 channels you like as your center frequency but there will be interference with other stations using channels less than 5 from you channel. That is not to say that running say 6 access points on 1, 3, 5, 7, 9, and 11 won't work - they will work but there will be mutual interference, retransmissions, etc.

[Andy L]

There are only 3 NON-OVERLAPPING CHANNELS for b/g because the channels are 5 MHz wide and 802.11b/g occupies a little more than 20mhz. The channel number refers to the center frequency. You can use center frequency on channels 1, 6, 11 without mutual interference. Some 802.11n signals are 40 Mhz wide. The channels for 802.11a are 10 mhz wide and every other channel can be used to provide 8 NON-Overlapping channels.

In 802.11b/g in the U.S. you can use any of 11 channels you like as your center frequency but there will be interference with other stations using channels less than 5 from you channel. That is not to say that running say 6 access points on 1, 3, 5, 7, 9, and 11 won't work - they will work but there will be mutual interference, retransmissions, etc.

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.

[comphappy]

WOW, this is what i wanted, but not at all what I expected. How do they expect me to wait until next year for this. Any one else excited about the FPGA possibilities? I hope we will be able to do the verlog an VHDL with out too much abstraction. I guess its time to roll out the grants and start writing.

Teaching this to the rest of the team and learning it my self is going to be a challenge more so then last year, I just hope I wont have to run build again this year. This could be a year where the programing makes or breaks it for teams.

This system is going to up the cool factor when showing it off the companies, it just looks more cutting edge with the wires and stuff hanging out like they do.

Did i say FPGA?
FPGA

[AustinSchuh]

I'm really excited about the FPGA too. Finally, we will be able to have our encoders produce way too many interrupts per second, and not have to worry about bogging down the controller because the FPGA can handle most anything we can throw at it. Not to mention 400 Mhz with a FPU.

[Nightfall831]

http://www.youtube.com/watch?v=Gkft479ARTk

OH MY GOD! THIS IS MY DREAM COME TRUE!!!!!!!1111oneone lim(sin(x)/x) x->0

I can die in peace now!

I AM SO EXCITED!!!!!!!!! :D :D :D :D :D

JACOB!!!!~~!~!!

so i totally took the time to check that limit...i hope im not the only one...

[sparrowkc]

So I happen to have the sticker in nightfall's sig on my right palm rest, and I was wondering if I will be able to program with my Ubuntu machine. The Windriver website says the software runs on redhat, but Ubuntu is on a different package system than redhat. I don't know if alien would convert it or if there is copy protection on it or what...

[billbo911]

The PWM connectors require the exact same cabling as before. They just have the added benefit of friction-based locking. Also, notice that there are lots of vast lengths of space in between the connectors.

Thanks for clarifying. It looked like an entirely different connector to me.

[coolfilmaker]

I'm just excited to see how they are going to fit a Hummer and an eight story building on the 27' x 54' field.

[tseres]

now we can all start drooling over the game possibilities for next year :p

[comphappy]

So I happen to have the sticker in nightfall's sig on my right palm rest, and I was wondering if I will be able to program with my Ubuntu machine. The Windriver website says the software runs on redhat, but Ubuntu is on a different package system than redhat. I don't know if alien would convert it or if there is copy protection on it or what...

I am 90% sure that it is a bin package, so no problem there long as your libs are up to date.

[Eldarion]

Does anyone know anything more about the vision processing?

Framerate?
Resolution?
Color or black-and-white?
Color based tracking or higher level (geon-based, SIFT, etc)?
Does it use the FPGA?

[Stuart]

. . umm WOW . . just WOW . . crazy.

Love the power of this thing. love the new power distro block . .and it looks to me like the OI will be my new best friend.

but I have a few questions #1 will it be that big come next year( cause it is HUGE compared to what we have now and we already have a hard time placing things where they need to go). #2 do I have to use all those blocks as shown or just what we want to use. #3 I know it can take a 50G shock but is it water proof? and #4 when can I get my hands on one of these?

ohh and 5 gold stars to the first team that uses the 802.11 and implements a web server on their robot . . 10 gold stars if they make it a CVS server and use it to program it with.

[comphappy]

. . umm WOW . . just WOW . . crazy.

Love the power of this thing. love the new power distro block . .and it looks to me like the OI will be my new best friend.

but I have a few questions #1 will it be that big come next year( cause it is HUGE compared to what we have now and we already have a hard time placing things where they need to go). #2 do I have to use all those blocks as shown or just what we want to use. #3 I know it can take a 50G shock but is it water proof? and #4 when can I get my hands on one of these?

ohh and 5 gold stars to the first team that uses the 802.11 and implements a web server on their robot . . 10 gold stars if they make it a CVS server and use it to program it with.

Yeah I was thinking we could just program it to do its own scouting.

[NCollins]

OK, after numerous calculations here is the data for 802.11 channel interference. Although it is true that only 1,6,and 11 have no crosstalk AT ALL does not mean that there are only three channels with low enough interference to work.

Cisco tested a 4 channel system using 1,4,8, and 11. In their test they found an only 1% interference overlap. With such little crossover they only found problems when using a large amount of the bandwidth at one time.

Using similar calculation I extrapolated the crosstalk with the system I described above (1,3,5,7,9,11). I found a crosstalk interference of only 5.47% outside 802.11 guidelines. Also at a distance of only 12.45 inches there is a drop in power enough to lessen the crosstalk below guidelines as well.

We also need to remember that the robots this year are only running at 19.2 Kbps. 802.11 provides up to 11000Kbps.

The guidelines for 802.11 require a 30dB drop for no interference.

[seanl]

Yeah I was thinking we could just program it to do its own scouting.

maybe we could even program the vision system go look around and scout.:cool: now thats what i call an automated robot.

[Andy L]

So far the only thing that I don't like is the fact that the PDBs, and everything is in one piece. Our electronics board was forced to fit into a very thin width and we probably couldn't have done it. Only a minor inconvenience because a few minor changes could've made work. The USB Joysticks will be good for us along with connecting to a laptop easily and my favorite is we can finally trash our programming laptop because we don't need the serial port anymore.

This new system will be amazing even though it will take a little while to learn it evens the field for new teams. I think our team will assign 2-3 people to just learn everything and relay most of it to the rest of the team. Easier said than done though because our entire team is going to jump on that.

[fatjoe3833]

http://www.youtube.com/watch?v=U5BRU1iqGpI

The real time mapping technology shown in this video looks very cool. Imagine a future game in which drivers could not see the field for all or part of each match. Kind of like the DARPA Grand Challenge. Maybe the guy in the video is giving us a hint.

I also like the use of the Wiimote. I can't wait to see what kinds of controllers teams use next year.

[Branden Ghena]

I have 4 comments...

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

I think you forgot Canada and Mexico :D

2)
so i totally took the time to check that limit...i hope im not the only one...

lim x-> 0 (sin(x)/x) = 1

Actually, I just learned this today in AP Calc class! Surprising how things come up.

3) Did you notice that the NI FIRST Community site came up yesterday at 5PM? I actually Googled "2009 FIRST Control System" yesterday at 10 PM and it came up. I basked in my newfound knowledge, but decided not to post and steal FIRST's thunder. I guess it didn't matter, someone else found out in the middle of the night. :rolleyes:

4)Did anyone notice that one of the abilities of the cRio was inter-robot communication. FINALLY! This could make for some VERY interesting challenges the next couple of years.

[Team1590]

Today I contacted NI and the rep told me that the CompactRIO costs $3796.00, but thats buying it strait from them. He didn't know the FIRST price. The chassis cost the most for some reason.

[chuckstudios]

The fact that each robot runs as its own access point is intriguing to me for a simple reason: robot hacking. Yes, security of your robot will now become an issue. When Dean Kamen and company were on Curie field to demonstrate the new control board, my friend happened to be on his laptop. What did he find in the wireless networks? An SSID of "NItro", the name of the NI demo 'bot. He logged into it (unsecured!) but didn't do anything because he didn't know that he was actually logged into the robot. In hindsight, he could have made it actually dance to Soulja Boy. :rolleyes:

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 also hope the router can be changed to whatever kind we like. A La Fonera running DD-WRT would be amazing for size and weight reasons compared to the DLink they had on the demonstration units. Oh well, I guess we'll find out more closer to kickoff... only 8 months to go.

Does anyone know if this is mac and linux compatible. I know that there is a Labview IDE for mac os x, but is there a compiler for the new control board

According to the information session, you can develop on Linux (and Mac presumably) but not load code. I think an open source loader may be necessary...

[JesseK]

Does anyone know anything more about the vision processing?

Framerate?
Resolution?
Color or black-and-white?
Color based tracking or higher level (geon-based, SIFT, etc)?
Does it use the FPGA?

Framerate will be determined by the update rate at which the new Driver's Station communicates with the bot, which will be limited by the wireless bandwidth.

Resolution will be determined by the packet size of said updates.

The camera is color.

It is color-based tracking, however they didn't say you couldn't have two and it looks like it will be easy to do some limited multi-color shape tracking given the speed of the processor.

I'm not sure if it uses the FPGA to process the color tracking.

[KTorak]

My only concern is readiness and ability to meet the deadlines of FIRST. From talking with the NI reps at the pits, they are not very far along and many of their answers were: "it's in the works," "its being prototyped," or "we aren't sure yet.". They said they only got the prototypes they showed today about a month ago. Also they said the controller should have a final weigth of about 2.2 lbs. In terms of IFI, it seems like they will slowly phase them out, whether or not that is FIRST's intention. The rep I spoke to said they are looking into developing their own speed controller to compete with the Victor 884 from IFI. I could see the being a big blow to IFI and their connection to FRC. The only other thing they would have at that point is stuff like sprokets and traction wheels. I guess we will have to wait and see how things go.

[galewind]

The youtube video on this page (http://decibel.ni.com/content/community/first;jsessionid=82a40f1a30d63dfd74a6370d490295488 afd65b7a964.e3mNbNaPb3iNe34TbxaPbhqPbNr0n6jAmljGr0 ) reminds me of the "Powerthirst" video.:D

Yeah I just showed a couple of my students powerthirst and then the FIRST video, and they remarked at how similar they were.

I said to another when sitting on Curie (this new control system is full of MENERGY!)

[Justin]

Hi Everyone,

Knowing the FIRST community as I do I'm afraid this post might ruffle some feathers. However in the whole of this conversation, or in an of the documents, I haven't seen any talk of the security employed on the WiFi network that team's robots will now rely on. Is there any encryption whether it be WPA or proprietary from NI? Please note that I am NOT advocating anything malicious during a match but I can think of ways that the WiFi/ethernet/IP(?) nature of the control system could be exploited. Now I recognize that those in FIRST practice gracious professionalism and I would not presume to suggest that anyone involved with FIRST would attempt an exploit. However as we are all reminded to often not everyone in the world lives by the FIRST creed. I think a little prudence would be the responsible course for FIRST and NI in this case.

Can anyone speak to this?

Thanks,

Justin

P.S. I see the post a few posts up now and that is disturbing. Clearly this will have to be addressed, with respects to my thread any ideas what shape such security might likely take?

[neutrino15]

According to the WPI PDF (http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf), we will be able to develop in Eclipse (C/C++) as well as Labview.

Q What IDE(s) will be available for use with the new controller/programming language?
A Both WindRiver Workbench (Eclipse) for C/C++ and LabVIEW.

Are there any example code snippets yet? I am dying to dive right in! :rolleyes:

[sparrowkc]

I am 90% sure that it is a bin package, so no problem there long as your libs are up to date.

I am so happy right now. No more virtualbox, no more usb to serial convertor...

For Next year, I want to see the controllers themselves running on WindRivers Linux distro;)

[JesseK]

Hi Everyone,

Knowing the FIRST community as I do I'm afraid this post might ruffle some feathers. However in the whole of this conversation, or in an of the documents, I haven't seen any talk of the security employed on the WiFi network that team's robots will now rely on. Is there any encryption whether it be WPA or proprietary from NI? Please note that I am NOT advocating anything malicious during a match but I can think of ways that the WiFi/ethernet/IP(?) nature of the control system could be exploited. Now I recognize that those in FIRST practice gracious professionalism and I would not presume to suggest that anyone involved with FIRST would attempt an exploit. However as we are all reminded to often not everyone in the world lives by the FIRST creed. I think a little prudence would be the responsible course for FIRST and NI in this case.

Can anyone speak to this?

Thanks,

Justin

P.S. I see the post a few posts up now and that is disturbing. Clearly this will have to be addressed, with respects to my thread any ideas what shape such security might likely take?

The FIRST rep that was at the mentor discussion today said that FIRST is outsourcing this issue in order to ensure they get an expert on the matter. They have to ensure security while also ensuring 24 teams (aka Atlanta setup) are able to be on the same network with equal bandwidth. Essentially, if they gave out how they were deciding to ensure security, someone somewhere would be that much closer to hacking into it. He also implied that FIRST would have detection methods and mechanisms in place to figure out the source of any tampering.

[lingomaniac88]

Well, with a webcam, there are many new possibilities, especially with optical character recognition. I don't know what the game is next year, but I can tell you this: 2009 will be one heck of a challenge for us programmers.

I wish our robot had the cRIO this year. If we did, it would've went around the track ABNORMALLY FAST! It would compete against Kenyans! It'd run as fast as Kenyans! It'd run so fast, people would think it's Kenyan! Then there'll be a tie and it'll be deported back to Kenya!!!

[CyberWolf_22]

Are their any example code snippets yet? I am dying to dive right in! :rolleyes:

The most information I have seen about programming in C\C++ for the new controller is on this page (http://decibel.ni.com/content/docs/DOC-1665).

[Madison]

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.

[artdutra04]

The rep I spoke to said they are looking into developing their own speed controller to compete with the Victor 884 from IFI. I could see the being a big blow to IFI and their connection to FRC. The only other thing they would have at that point is stuff like sprokets and traction wheels. I guess we will have to wait and see how things go.That seems weird, as almost everyone I know or have talked to who are involved in other robot competitions (such as Battlebots, etc.) regard the IFI speed controllers as among the best in the business.

Edit; If anything, opening up the allowable speed controllers to several brands that meet certain criteria would be fine. But to purposely just move as far as possible away from a product with a successful track record in various robotics competitions seems like a dumb decision.

[Andy L]

That seems weird, as almost everyone I know or have talked to who are involved in other robot competitions (such as Battlebots, etc.) regard the IFI speed controllers as among the best in the business.

Edit; If anything, opening up the allowable speed controllers to several brands that meet certain criteria would be fine. But to purposely just move as far as possible away from a product with a successful track record in various robotics competitions seems like a dumb decision.

I've been watching various robotics competition shows lately and it really surprises me because the victor does show up a lot more than I'd expect and it's weird to see something on TV and know that I use the same exact parts as them.

[eugenebrooks]

This really isn't a very hard problem to solve.

The RC and the OS can share a secret and use a checksum
for packet authentication.

The field control system can use public key methods, so that
a secret need not be globally shared for packet authentication.

Encryption is not required and it is best that the field control
system can see the traffic in any event.

In my view, it would be a nice if FIRST used sound methods
make sure that the communications for the field control system
is not spoofed. Putting the methods out for public review
is the best way to make sure that the chosen means is sound.

I will add that setting up the C and C++ environment as an
open source development environment is the cat's meow for
the FIRST community. A applaud this loudly!

Eugene

Hi Everyone,

Knowing the FIRST community as I do I'm afraid this post might ruffle some feathers. However in the whole of this conversation, or in an of the documents, I haven't seen any talk of the security employed on the WiFi network that team's robots will now rely on. Is there any encryption whether it be WPA or proprietary from NI? Please note that I am NOT advocating anything malicious during a match but I can think of ways that the WiFi/ethernet/IP(?) nature of the control system could be exploited. Now I recognize that those in FIRST practice gracious professionalism and I would not presume to suggest that anyone involved with FIRST would attempt an exploit. However as we are all reminded to often not everyone in the world lives by the FIRST creed. I think a little prudence would be the responsible course for FIRST and NI in this case.

Can anyone speak to this?

Thanks,

Justin

P.S. I see the post a few posts up now and that is disturbing. Clearly this will have to be addressed, with respects to my thread any ideas what shape such security might likely take?

[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

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

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]

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]

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]

The youtube video on this page (http://decibel.ni.com/content/community/first;jsessionid=82a40f1a30d63dfd74a6370d490295488 afd65b7a964.e3mNbNaPb3iNe34TbxaPbhqPbNr0n6jAmljGr0 ) reminds me of the "Powerthirst" video.:D

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

Water Game

[Greg Marra]

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 (http://xkcd.com/303/) make sense.

[synth3tk]

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.

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 (http://xkcd.com/303/) 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.]

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]

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.

[mgreenley]

um how about you set MAC authentication on the AP

For reasons that eugenebrooks has covered (post #120 (http://www.chiefdelphi.com/forums/showpost.php?p=738655&postcount=120)), (post #123 (http://www.chiefdelphi.com/forums/showpost.php?p=738665&postcount=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.

[lingomaniac88]

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 (http://xkcd.com/303/) make sense.
I assume that the robot code will be within the still-not-that-complex-but-does-more category, if not higher. I hope that I won't have to put together autonomous code between matches like I had to do this year. Fifteen minutes from the compiler to the robot. Wow.

[Greg Marra]

I assume that the robot code will be within the still-not-that-complex-but-does-more category, if not higher. I hope that I won't have to put together autonomous code between matches like I had to do this year. Fifteen minutes from the compiler to the robot. Wow.

Note: cRios let you run code in two places. The FPGA handles low-level device communication and any simple integer maths you would like to do. However, you can pass it all up to the PowerPC (which code compilation doesn't take nearly as long on) and have the PowerPC twiddle with it and send commands back down to the FPGA.

So once you get your low-level stuff working on the FPGA, you may not need to tweak the FPGA code, and can just fiddle with your higher level algorithms on the PowerPC.

[Dave Flowerday]

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.
The first product I worked on at Motorola took 4 hours for a full build, and 20-30 minutes to recompile if you changed one line of code. It's really not uncommon for lengthy build times in the industry. It makes you a much better programmer because you really need to take the time to understand the changes you're making before you recompile.

A lot of people get spoiled on simple projects in college or for hobby purposes and get themselves into a "change code, compile, test, repeat" loop that just isn't possible on more complex software.

It's quite possible the more complex software that will likely accompany this new controller will come with longer build times than you're used to now with the IFI hardware.

[Tom Line]

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 (http://xkcd.com/303/) make sense.

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Is this specific to Labview or are you suggesting that even teams using Eclipse / etc and programming in C will see this kind of compile time?

IF that is the case, and C will take that long to compile for these applications, it may render it completely unusable if you have to do something that requires multiple compiles, like tuning a PID loop, unless you get more fancy and create the ability to adjust the constants with a pot / buttons etc.

[Racer26]

Someone questioned the cRIO's waterproofness... oh dear, let the water game speculation come flying now...

[seanwitte]

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Is this specific to Labview or are you suggesting that even teams using Eclipse / etc and programming in C will see this kind of compile time?

IF that is the case, and C will take that long to compile for these applications, it may render it completely unusable if you have to do something that requires multiple compiles, like tuning a PID loop, unless you get more fancy and create the ability to adjust the constants with a pot / buttons etc.

VHDL is a hardware description language which is compiled differently than a traditional programming language. Instead of compiling down to machine code it compiles down to the logic level to be burned into a Field Programmable Gate Array (FPGA).

[AustinSchuh]

I admit to not being familiar with the acronyms you are using. VHDL? etc.


http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language

Depending on the rules, teams will either rarely touch the FPGA code, or never touch it. So the long compile times for compiling the VDHL code for the FPGA aren't an issue. Most likely FIRST will implement the disable logic in the FPGA. If that is the case, they won't want us to potentially mess up the disable code and therefore won't let us change it.

Most, if not all, development for our robots will be done for the 400 MHz processor. Which should have a quick compile process and a smokin' fast download.

[slavik262]

I am extremely excited about the ability to finally write code in C++. Other than what I've read on the site, does anybody know any specifics about how this will work? Will we be able to simply compile and transfer the file using the wireless into the controller? Will we have to use a specific IDE or will the compiler be useable across multiple IDEs provided we use the libraries given to us for the processor? My dream would be to write the robot code in the Microsoft Visual C++ IDE, which is better than MPLab by leaps and bounds, mostly due to Intellisense.

[RoXmySoX]

that is crazy!!!!

cant wait to test it out!

[Adam Y.]

I admit to not being familiar with the acronyms you are using. VHDL? etc.

Uggg. I think I used the wrong acroynm. A hardware description language is completly seperate from C.
Depending on the rules, teams will either rarely touch the FPGA code, or never touch it. So the long compile times for compiling the VDHL code for the FPGA aren't an issue. Most likely FIRST will implement the disable logic in the FPGA. If that is the case, they won't want us to potentially mess up the disable code and therefore won't let us change it.

That renders the point of having an FPGA moot.

[AustinSchuh]

That renders the point of having an FPGA moot.

Unless FIRST is open to adding in features that teams request, and provides a basic configuration that supports some nice sensors. I would be quite surprised if that FIRST didn't implement some logic to support quadrature encoders and only slightly less surprised if they didn't implement logic for sensors like Sonar also. Otherwise you are right.

It still would be nice if they let us program the FPGA ourselves.

[NetElemental]

That renders the point of having an FPGA moot.

It absolutely does not - depending on what is done inside the FPGA, it could be a great tool - for example, if the WPI libraries were implemented on the FPGA, or the adc/encoder/gyro/competition mode code are on the FPGA, it is considerably faster than a microcontroller AND frees considerable processing room, as well as saves time coding. If the FPGA is designed to automatically do many of the low level functions that we as programmers normally have to wrangle with (like what Kevin Watson's libraries are used for), it would be an incredible help. Imagine never having to write code to interface with the camera, or have the gyro angle automatically calculated for us instead of having to do it ourselves - there are much greater problems that could then be tackled.

[Richard Wallace]

... It still would be nice if they let us program the FPGA ourselves.... If the FPGA is designed to automatically do many of the low level functions that we as programmers normally have to wrangle with (like what Kevin Watson's libraries are used for), it would be an incredible help. Imagine never having to write code to interface with the camera, or have the gyro angle automatically calculated for us instead of having to do it ourselves - there are much greater problems that could then be tackled.Some teams might like to program the FPGA. Other teams might like to design their own custom motors. FIRST wisely limits the degree to which teams can engineer at the component level, for several good reasons. Safety is a big one. Reasonable limits on work during build season are another. Keeping teams focussed on the game challenge, rather than component details, is still another.

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]

I also favor keeping the rule against custom motors. [And I am a motor designer.]

[MikeDubreuil]

I'd favor no team programming of the FPGA. [But of course I'm not a VHDL programmer.]
As an embedded software engineer I wouldn't want to comment on that until we know more about the architecture of the new system. Specifically where the "safety features" reside. There's some good ideas floating around about FPGA based counters for sensors such as encoders.

[dcbrown]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions


. VxWorks is essentially (very!) unix-like operating system.
it uses a BSP (board specific package) as h/w abstraction layer so it can be targetted to multiple platforms. The BSP exists for the cRIO. The normal VxWorks comes with a bunch of different BSPs, we may end up with a stripped down version of the environment with only the cRIO - that would make sense.
there is a configuration process whereby you add in or remove components that you want in the RTOS build - standard stuff. Which means you can add rom-based file system, FTP, and other capability that is already available in the VxWorks kit as needed. There will be a standard config for competition, but for prototyping this opens up lots of stuff like application data logging during testing via WiFi. There are separate Broadcom device drivers available, for example, and other 3rd party driver packages.
The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
Both the Wind River C and GNU C compilers will work.
VxWorks is RTOS, applications are either integrated into the kernel or as application. Multitasking native with 256 priorities and round-robin scheduling within priorities (so essentially unlimited tasking until you run out of main memory).
a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!
(ok weird factoid), interrupt latency is slightly better than RTLinux, at around ~70usec (published number was 100us but that was on a MPC8260 @200Mhz processor vs 400Mhz MCP52xx of cRIO... but should give a ball park figure).
fun stuff like a shell window on the target (cRIO) that you connect to and use from the development host [I guess like a console].
lots and lots of other good stuff if you're an applications programmer.
Someone (WPI?) will provide the pre-canned "driver" software for the common interface devices; gyro, camera, sonar, and the like similar to the WPILIB today. It will be provided in source form. This combined with a default VxWorks project will provide the default/base code for the robot next year. I haven't read far enough into "Wind River General Purpose Platform, VxWorks Edition - Getting Started" to see how much work it will be to change drivers, but if the pre-canned driver software is open-sourced then you could use that to slightly modify things as needed for your robot - but suspect that shouldn't be needed often.

Custom h/w and/or driver software will likely be discouraged the first year. Both would make it difficult to provide the type of deep generic support needed across all the teams. The programming of the FPGA will be canned and shouldn't be touched by individual teams again for the same reasons. Maybe in later years we'll be able to change this.

LabVIEW is built on top of what VxWorks provides, so C/C++ is actually the native method of building apps.

[SL8]

After reading the first post to the last, I went back to the first again.:ahh:

Can someone help explain this stuff to me in peasants terms?:confused:

[dcbrown]

After reading the first post to the last, I went back to the first again.:ahh:

Can someone help explain this stuff to me in peasants terms?:confused:


Its a "PC" running a flavor of unix operating system that you'll need to write an application program for. Hardware drivers for all the common stuff will be written for you so you just have to call them to get the data you're interested in.

Take EasyC or WPILIB x 1000 in terms of the number of library calls that are available.

NAME taskInfo – task information library
ROUTINES
taskName( ) – get the name of a task residing in the current RTP
taskNameGet( ) – get the name of any task
taskInfoGet( ) – get information about a task
taskOptionsGet( ) – examine task options
taskNameToId( ) – look up the task ID associated with a task name
taskIdDefault( ) – set the default task ID
taskIsReady( ) – check if a task is ready to run
taskIsSuspended( ) – check if a task is suspended
taskIsPended( ) – check if a task is pended


and


NAME eventLib – VxWorks user events library
ROUTINES
eventClear( ) – Clear all events for calling task
eventReceive( ) – Receive event(s) for the calling task
eventSend( ) – Send event(s) to a task


and


NAME clockLib – user-side clock library (POSIX)
ROUTINES
clock_getres( ) – get the clock resolution (POSIX)
clock_setres( ) – set the clock resolution
clock_gettime( ) – get the current time of the clock (POSIX)
clock_settime( ) – set the clock to a specified time (POSIX)
clock_nanosleep( ) – high resolution sleep with specifiable clock


and


NAME timerLib – user-level timer library (POSIX)
ROUTINES
timer_cancel( ) – cancel a timer
timer_connect( ) – connect a user routine to the timer signal
timer_create( ) – allocate a timer using the specified clock for a timing base (POSIX)
timer_open( ) – open a timer
timer_close( ) – close a named timer
timer_unlink( ) – unlink a named timer
timer_delete( ) – remove a previously created timer (POSIX)
timer_gettime( ) – get the remaining time before expiration and the reload value (POSIX)
timer_getoverrun( ) – return the timer expiration overrun (POSIX)
timer_settime( ) – set the time until the next expiration and arm timer (POSIX)
nanosleep( ) – suspend the current task until the time interval elapses (POSIX)
sleep( ) – delay for a specified amount of time
alarm( ) – set an alarm clock for delivery of a signal
_timer_open( ) – open a kernel POSIX timer (system call)
timer_ctl( ) – performs a control operation on a kernel timer (system call)


and on and on and on...

[SL8]

So it's actually the same programming accomplished in a different style?

Edit: Had to fix my grammer. :p

[SL8]

And since its in C++, you would still be able to write in C, as long as it tagged as C, and in C++ at the same time ,right? Does this mean we will be writing classes, object, and using the C++ templates, et cetera?

[ericand]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

. VxWorks is essentially (very!) unix-like operating system.
......

you need to be careful. While VxWorks has a posix interface, but it is not Unix or Linux. You can go along way treating it as if it was a unix system and then you get bit by something that does not work as you expect.

You can do things with the vxWorks shell that are just not unix like at all. For example, you can call routines from the shell much like you can call programs from a linux command prompt.

I hope that Wind River will give us access to some of the extra tools that can come with Workbench. For example, Wind River has tools which can monitor memory use as the your program is running, so you can detect memroy leaks. There are also tools for profiling so you can know how much time is spent in various routiens and how often those routines are called.

Hopefully we can get Wind River to spring for some training assistance to allow us to make the best use of their tools.

[dcbrown]

You can do things with the vxWorks shell that are just not unix like at all. For example, you can call routines from the shell much like you can call programs from a linux command prompt.

I do this on the unix I support from a utility called crash all the time. Crash provides an interface into either a live system (/dev/kmem) or a memory dump (crash) and lets you do LOTS of stuff that ain't application programming safe! :yikes: . You can call routines, change data, whatever you want.

But from an application programming standpoint, the API provided in VxWorks is very unix-like.

I guess what I'm trying to say is don't confuse utilities unique to VxWorks with the environment that the typical team will be using (if using C).

Ditto on training. It would be especially nice if the full analysis tool set was available, possibly at extra, but discounted, cost.

[dubious elise]

Wow - this looks pretty rugged. I can't help but wonder how long it would take Ricky to rip a port out of it... ;)

[BigJ]

but we don't have any serial cables to accidentally screw in anymore!

[Boydean]

The system looks, awesome. To me(I missed all the sessions and everything gotta catch up)its a lot more down to making a WHOLE lot better auto. code than the IFI controller was. Also from the pics I saw, it looks way more cooler and professional then IFI.

but we don't have any serial cables to accidentally screw in anymore!

YES! The way our board now is, its a pain in the butt to get to the program/tether port plugged in. So when someone just touches it and it goes in, it can set us back 10 to 15min getting it back out.:ahh:

[writchie]

OK, after numerous calculations here is the data for 802.11 channel interference. Although it is true that only 1,6,and 11 have no crosstalk AT ALL does not mean that there are only three channels with low enough interference to work.

Sorry - not OK. First, the non-overlapping channels 1, 6, 11 are not totally free from adjacent channel interference. They are called non-overlapping because you have three channels with nominal channel widths of 22mhz spaced 25 mhz apart. When transmitting on 6 for example, most of the signal energy will be in 4 - 8. But there will still be signal energy in channels 3 and 9 that can interfere with channels centered on 1 and 11. While the adjacent out of band signals are typically -20db - 35db below the peak signal, this is still sufficient to cause interference. This is because the signal in the adjacent channel, while 20 - 35 db lower than the the peak signal, can still be nearly as strong in absolute level as a signal you are trying to receive that is ten times father away. Adjacent channel interference is a particular problem when the interfering transmitter is very much closer than the transmitter you are trying to listen to. This is exactly the case if you try to operate several robots in close proximity with the robots relatively far from the stations they are talking to.


Cisco tested a 4 channel system using 1,4,8, and 11. In their test they found an only 1% interference overlap. With such little crossover they only found problems when using a large amount of the bandwidth at one time.

Even when operating on the exact same channel, two networks interfere only when they occupy the channel at the same time. Very lightly loaded networks, even on the same channel, have little noticeable interference consequences due to link layer retransmission. You won't see the effects until you have larger amounts of data on one or the other network or you are running an application that is sensitive to packet delay. Teleop control is such an application where you do not want such delays. You won' care about a 400ms delay surfing the web. You will when controlling your robot.

I suspect the Cisco example showed access points spread apart by some tens of meters. This is enough to reduce the interference seen at the access points. However, two laptops close together operating on different networks will experience lots of mutual interference. In the normal office operating environment wireless nodes are normally several meters apart or operating on the same network.

Using similar calculation I extrapolated the crosstalk with the system I described above (1,3,5,7,9,11). I found a crosstalk interference of only 5.47% outside 802.11 guidelines. Also at a distance of only 12.45 inches there is a drop in power enough to lessen the crosstalk below guidelines as well.

We also need to remember that the robots this year are only running at 19.2 Kbps. 802.11 provides up to 11000Kbps.

The guidelines for 802.11 require a 30dB drop for no interference.

I have no idea what 5.47% crosstalk interference means. I would expect that the total combined throughput of the 6 networks you suggest would be well below that of a single network. Operating 6 robots on 1, 3, 5, 7, 9, 11 would probably not be too pretty, especially with synchronous traffic. When the robots are in close proximity, they will overwhelm the signals from the much more distant stations they are communicating with. The traffic would have to be extremely low for this to be workable. Bluetooth would probably a much better solution for multiple independent networks in close proximity. Or 802.11a where there are many more channels. Or a channelized system like we have now (operating on other than 2.4 GHZ).

Operating a single access point per field with 6 robot stations and using wired LAN from the Operator Stations to the field controller is IMHO the way to achieve the best performance. The single access point can employ 802.11e to provide QoS for teleop control packets (and possibly telemetry) and the beacon rate and other network parameters can be tuned for optimum system performance. The Field controller can also shape the traffic to equalize the access for the six teams or even for the two alliances. Adjacent field would operator on non-overlapping channels. All of this off-the-shelf stuff. There would be very few re-transmissions or holdoffs in such a scenario - mostly from outside interferences. If FIRST is planning on 802.11b/g, I do hope this is what they are planning. Personally, I'd like to see 802.11 a/b/g radios in Linux capable boxes all around for maximum flexibility.

[Nikhil Bajaj]

You know, I was just thinking that it would've been fun and rewarding if FIRST had challenged the community to come up with a control system--we're a big huge bunch of engineers and the like with tons of experience between ourselves with embedded programming, board design, experience hardening electronics to survive harsh environments, etc. I think that given the opportunity we could've come up with something absolutely wicked and cheap, too. While NI is an AMAZING company, and they make absolutely sweet products, part of the charm of the IFI system is that it was designed for FIRST. I feel like the community could have done an amazing job of that--then they could be manufactured and sold to teams at cost. Oh well--just...everybody remember this idea for 10 years down the road when we change systems again! :D

[neutrino15]

After reading a lot of the stuff available from FIRST, WPI, NI, and Wind River... and doing some integration/interpretation... and guessing, the following are some random opinions

...


The IDE (Workbench) is Eclipse-based. You have the ability to add REAL breakpoints and other stuff for debugging. You'll need to compile with debug flags, otherwise you only get assembler view. Compiling w/debug goes for any libraries you'd use which is why any FIRST provided added-value such as pre-canned drivers for gyro, et.al. would need to be in a controlled source form.
Both the Wind River C and GNU C compilers will work.



Does this mean I can just use my existing Eclipse install on my Mac? Maybe add some plugins? Or do I have to use Windriver? What features will Windriver give me over Eclipse?


* a ton of documentation is available (I'm looking at 100mb of stuff), everything from getting started, to writing your own BSP (as if we'd ever need or want to do that!). For software mentors, start reading!


I can has link? All I could find was the WPI page and some stuff on NI's site.. Not 100MB, no enough to get started.. If all else fails, be cool and upload a package to FileDropper (http://filedropper.com) or something?;)

[MikeDubreuil]

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 agree, the power distribution board provides the power regulation for the RIO and the Wireless Access Point as seen in these two (http://first.wpi.edu/FIRSTdemobot1.JPG) photos (http://first.wpi.edu/power_distribution.jpg). It would be nice to see a big capacitor there designed to survive brown outs.

[writchie]

I agree, the power distribution board provides the power regulation for the RIO and the Wireless Access Point as seen in these two (http://first.wpi.edu/FIRSTdemobot1.JPG) photos (http://first.wpi.edu/power_distribution.jpg). It would be nice to see a big capacitor there designed to survive brown outs.

These look like high-speed switch mode regulators. Large capacitors are not required, and can even be detrimental. Since the 24V supply is an up-converter, it can probably maintain regulation down to 7V on the main battery, maybe even less.

[FRC4ME]

Does everyone think we can count on Kevin-style ADC processing built-in next year?

[EricVanWyk]

These look like high-speed switch mode regulators. Large capacitors are not required, and can even be detrimental. Since the 24V supply is an up-converter, it can probably maintain regulation down to 7V on the main battery, maybe even less.

100% Correct.

The 24V supply is an LM3478 running at 600kHz. As you said, it is a boost (up) converter.

It can survive well below 7V input.

You are correct in saying that for some controllers, large bulk capacitance is not necessarily a good thing. In fact, in some specific instances, they can hurt performance. For this particular controller, it would be fine to add big bulk capacitance.

However, it wouldn't really help that much. The problem with large capacitors is that they have poor frequency response. A big "can" capacitor is a less effective use of space / money than smaller ceramic caps are for the frequency it is switching at.

[Mike AA]

Does anyone have any of the videos of the thing that happened on curie with the new controller? I have been waiting but still none of the videos are showing up. Did anyone record the feed?

-Mike AA

[Guy Davidson]

Does everyone think we can count on Kevin-style ADC processing built-in next year?

I think so. When I talked to the NI guys, they mentioned (among other things) oversampling, noise cancellation, integration (for a gyro signal) and other such goodies.

[lukevanoort]

For those worrying about security - I was told by an NI rep that FIRST recognized the issue and now has NASA helping them develop a method of securing communication.

[Eldarion]

As an embedded software engineer I wouldn't want to comment on that until we know more about the architecture of the new system. Specifically where the "safety features" reside. There's some good ideas floating around about FPGA based counters for sensors such as encoders.

From what I understand, having attended the "training" session at Nationals and talked with the NI guys separately, the FPGA will most likely be acting like the old IFI Master processor, and therefore will not be user configurable. I cannot be absolutely sure, however, as getting detailed information out of them was like pulling teeth! :rolleyes:

Something interesting with regards to the PowerPC processor they keep mentioning--NI appears to be using a Virtex II Pro FPGA in the CompactRIO. That FPGA actually has two hard-core 450MHz PowerPC processors connected to the FPGA fabric. I wonder if we will be allowed to use both cores, or if they are using the other core for something else (more Master functionality, perhaps).

The biggest thing that is bugging me at this point is the sheer size of the applications that are downloaded to the controller. 75Mb+ for a simple two-wheel drive control program??? That screams bloatware to me! I wonder how easy it is going to be to chew through the 128Mb of FLASH storage?

I also talked at length with the NI guys about the "Real time vision system". All of the vision algorithms actually run on the PowerPC processor, and if you do unbounded OCR or any vision processing at a higher level than basic color thresholding or simple shape detection, the system will not be real time. They were able to get the "reading" demo to work in real time because the words were surrounded by either an oval or a rectangle. I am not sure if they were using the OCR after that first processing stage or not, but they were definitely keying in on the shape. I just wanted to clear up some misunderstandings and confusing / conflicting information on that particular subsystem. ;)

All that said, if they can work out some of the bugs, this looks like a very powerful system and it will be interesting to see what teams can do with it!

[adman]

You know, I was just thinking that it would've been fun and rewarding if FIRST had challenged the community to come up with a control system--we're a big huge bunch of engineers and the like with tons of experience between ourselves with embedded programming, board design, experience hardening electronics to survive harsh environments, etc. I think that given the opportunity we could've come up with something absolutely wicked and cheap, too. While NI is an AMAZING company, and they make absolutely sweet products, part of the charm of the IFI system is that it was designed for FIRST. I feel like the community could have done an amazing job of that--then they could be manufactured and sold to teams at cost. Oh well--just...everybody remember this idea for 10 years down the road when we change systems again! :D

Well guys here goes...

I agree we as the FIRST community of students/mentors/teachers should
be consulted on such a critical change in the fundamental nature of
our robots operation.

I have experience using NI hardware in many of our systems at work and
its really good stuff ( and really expensive!) The problem here is that
NI is not an embedded house. There support is really good but they tend
to expect to talk to engineering types because that is the high caliber of
support people they have on the other end of the line. (Support agreements
do cost money in certain cases, if it is something they did wrong its no
charge.)

The compact rio is definitely rugged serious stuff. Its all over the world but
heres where I have a problem.

I weighed the unit on the Archmedes inspections scales 3.5 pounds!:ahh:
You have to add at least 2 "handoff" boards which break out the 32I/O
module so you can use them. Oh then there is the "power board". In general
we are taking a unit that is supposed to have D connectors on it and trying
to remanufacture little modules that make it all look like standard 3 pin
pwm cable connectors. The analog module has an adaptor (FIRST DESIGNED)
to add the 5 volt bus back on so we keep the exisitng pwm analog plug.

The super power 400 mhz power pc is an asset to be assured and I was
getting pretty excited on the first day when they said we had the ability
to program the on board FPGA. The next day however we were told no that
isn't going to happen. The reason for probably taking it away was simple
no PWM control modules so they are using the FPGA to generate the pwm
signals. These are routed out through the 32 Digital I/O board to the
breakout board and finally to the Victors. ( yea they are still using them)

Bottom line guys is we have a ton of hardware being shoved into a
configuration that allows standard First parts to be plugged in. As you
have already seen we haven't even gotten to the radio link stuff.

I am not a fan of upconvertors for power if you can avoid them. The word
convertor means power loss. Its also means electrical noise.

The other HUGE PROBLEM here is we are taking NI's preferred path to
nirvana Labview. Its a language ( or picture grams ) designed to make it
easy for nonprogrammers to run instrumentation without knowing much.
This takes away from our students learning about embedded code and
sequential programming. Thats where the extra companies come in to
write a compiler so the students have the option to use C C++. There
is still the matter of converting Labview stuff to be callable by the new
compiled code. Are you seeing a pattern here? We are taking NI and trying
to convert it back into what we already have.

I thought well at least we will have access to NI's incredible Vision packge
VBAI which would finally allow our kids a great vision tool that is easy to
use but no we don't get that either. They are going to write something that
allows us access to some vision tools ( dont' know which ones).

I really like NI. They are a great company and make great hardware that
is almost always callable by langauges like VB ( still the most popular
programming language that's in use), also callable from C++ but they only
support hardware support APIs. This is how we use it, not LABVIEW.
With no zoom feature on Labview ( they have promised this for years, its
there number one complaint from users on their list) Its hard to isolate
sections of the code to allows students to focus on a small part at a time.
Very hard to document since its all just pictures. I am very familiar with
labview and write an array of clusters with properties any day but this
is not what we should expose our students to at this time. Its great for
what its intended. Doing some instrumentation with graphing without much
knowledge.

One of the workaround options is to compile LabView to Dll see http://zone.ni.com/devzone/cda/tut/p/id/3517

Another thing, why write a new compiler when you have NI CVI
http://www.ni.com/lwcvi/ this allows NI calls C code to be writen in Visual C++.


With all the serious new embdedded hardware out there today there are
other options. Dean charges us with making the minds of tommorow
with the ability to solve the worlds problems. Its a lot easier to do that
when our students know they can buy the processor we use in an IFI
controller for less than 10 bucks and make the astounding machines they
make now. If we go this route they need to buy a 2000 dollar Compact
RIO to make a new IPOD?

And by the way where is the 3.5+ pounds coming from in our weight
budget? The wheels?

Sorry for the size of this post and but I want us to make some noise here so we as a community make this decision. I only hope the reason we are doing this isn't money based that NI is a large sponsor.(notice how small the
microchip sponsorship logo was on the banners at Einstein?)

If a moderator from FIRST is reading this please contact me. We need to
talk. You guys are trying to do the right thing. So are we.

[Uberbots]

The two architectures are completely different. It appears the only commonality would be through labview.

You can get started with the new FRC control system stuff now. The following are current prices:

cRIO 9074 - $2999
Power Supply & Cables $249
9201, 9403, and 9472 Modules and Cables $1219
Subtotal Total Hardware $4467

Software:

Labview for Windows $4099
Labview Real-Time Module $2499
Labview FPGA Module $2499

Subtotal Software $9097

Total $13,564

The above doesn't include the custom undocumented digital sidecar so the above would only get you started on the tool chain and sensor platforms.

Not if you ask nicely, it isn't.
So far, most teams already have the software. I know our team has at least the base program and the RTM because of our participation in the DAQ project, and i also have a subscription to the NI developer stuff through some of our mentors.

so the subtotal could come out to $0 to $2500 if you ask properly.

[ABlackburn]

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.

I was worried about this too. I asked NI about this exact question, and they say it has a boost converter. For those that don't know what it is (I'm not all too clear on it myself) it is a device whic can take a supplied voltage and increase it to the desired voltage, but will possibly drain a battery faster.
http://en.wikipedia.org/wiki/Boost_converter

now I'm thinking the same thing most other teams are also thinking. Faster battery drain? Those batteries can just make it through these matches as it is, so this may just be too much.

My prediction for next year:

Different Batteries

[wilsonmw04]

From the FAQ:
http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf

Q What batteries will we use? Will we be able to use our batteries from past robots with the system?

A FIRST will continue to use the standard 12V SLA type batteries. Past year’s batteries would be compatible.

[ABlackburn]

From the FAQ:
http://first.wpi.edu/2009_FRC_Controller_FAQ_FINAL.pdf

Q What batteries will we use? Will we be able to use our batteries from past robots with the system?

A FIRST will continue to use the standard 12V SLA type batteries. Past year’s batteries would be compatible.

good call, missed that. I've been really out of it since the competition, and haven't got a good rest yet. Took a plane back to Jersey early Sunday morning

[Eldarion]

...

The other HUGE PROBLEM here is we are taking NI's preferred path to
nirvana Labview. Its a language ( or picture grams ) designed to make it
easy for nonprogrammers to run instrumentation without knowing much.
This takes away from our students learning about embedded code and
sequential programming. Thats where the extra companies come in to
write a compiler so the students have the option to use C C++. There
is still the matter of converting Labview stuff to be callable by the new
compiled code. Are you seeing a pattern here? We are taking NI and trying
to convert it back into what we already have.

...

With no zoom feature on Labview ( they have promised this for years, its
there number one complaint from users on their list) Its hard to isolate
sections of the code to allows students to focus on a small part at a time.
Very hard to document since its all just pictures. I am very familiar with
labview and write an array of clusters with properties any day but this
is not what we should expose our students to at this time. Its great for
what its intended. Doing some instrumentation with graphing without much
knowledge.

...

With all the serious new embdedded hardware out there today there are
other options. Dean charges us with making the minds of tommorow
with the ability to solve the worlds problems. Its a lot easier to do that
when our students know they can buy the processor we use in an IFI
controller for less than 10 bucks and make the astounding machines they
make now. If we go this route they need to buy a 2000 dollar Compact
RIO to make a new IPOD?

...

Yes! 100% correct on all counts--being an embedded developer myself, these were the exact complaints I had, but didn't know if I should mention them here or not.

If you want someone else to help "make noise", I'll be glad to join in...

[writchie]

now I'm thinking the same thing most other teams are also thinking. Faster battery drain? Those batteries can just make it through these matches as it is, so this may just be too much.

My prediction for next year:

Different Batteries

According to the specs the cRIO draws only 20 watts. The recommended power supply is 48 watts, or 2 amps at 24 volts. The upconverter should have an efficiency of about 80% so the input current with 10 volts on the battery should be about 2.5 amps. If your stalled motors drop the battery down to 5 volts the input power to the upconverter may rise to 5 amps but this is nothing compared to 100 amps pulling down the battery.

The primary concern is maintaining glitch free power so that the robot controller doesn't reset during the low voltages that result from motors operating near stall conditions. The design of the new PDU looks pretty good at covering this issue.

[Ty Tremblay]

http://first.wpi.edu/FRC/index.html

A new category has just been put up about the new FRC control system.

[Daniel_LaFleur]

Well guys here goes...

I agree we as the FIRST community of students/mentors/teachers should
be consulted on such a critical change in the fundamental nature of
our robots operation.

I have experience using NI hardware in many of our systems at work and
its really good stuff ( and really expensive!) The problem here is that
NI is not an embedded house. There support is really good but they tend
to expect to talk to engineering types because that is the high caliber of
support people they have on the other end of the line. (Support agreements
do cost money in certain cases, if it is something they did wrong its no
charge.)


I, too, have experiance with NI equipment. Believe me, their staff is well equipped to handle any level of technical difficulty. And with the amount of equipment that FIRST will be purchacing, a support agreement should be supplied. I trust FIRST to make sure on the support aspect of this deal.


The compact rio is definitely rugged serious stuff. Its all over the world but
heres where I have a problem.

I weighed the unit on the Archmedes inspections scales 3.5 pounds!:ahh:
You have to add at least 2 "handoff" boards which break out the 32I/O
module so you can use them. Oh then there is the "power board". In general
we are taking a unit that is supposed to have D connectors on it and trying
to remanufacture little modules that make it all look like standard 3 pin
pwm cable connectors. The analog module has an adaptor (FIRST DESIGNED)
to add the 5 volt bus back on so we keep the exisitng pwm analog plug.


The weight is nothing but another engineering challange. And the adaptor boards are nothing but breakout boards, a standard in manufacturing automation.


The super power 400 mhz power pc is an asset to be assured and I was
getting pretty excited on the first day when they said we had the ability
to program the on board FPGA. The next day however we were told no that
isn't going to happen. The reason for probably taking it away was simple
no PWM control modules so they are using the FPGA to generate the pwm
signals. These are routed out through the 32 Digital I/O board to the
breakout board and finally to the Victors. ( yea they are still using them)


More than likely FIRST is going to use the FPGA to have the DIO mimic PWM outputs. They also talked about on-board image recognicion (sp?) and OCR capabilities. Most likely these will be on the FPGA. FIRST may also include the data transmission encryption keys on the FPGA so that they will be much harder to be spoofed, and can be changed by pit admin with just a download.


Bottom line guys is we have a ton of hardware being shoved into a
configuration that allows standard First parts to be plugged in. As you
have already seen we haven't even gotten to the radio link stuff.

I am not a fan of upconvertors for power if you can avoid them. The word
convertor means power loss. Its also means electrical noise.


From what I've seen, the upconverter they use is high frequency and thus little noise generated.

I too am a bit concerned about the power loss and power consumption of the controller (as we haven't seen any data on that yet), but I will hold judgement on those until I see the datasheet for the unit.


The other HUGE PROBLEM here is we are taking NI's preferred path to
nirvana Labview. Its a language ( or picture grams ) designed to make it
easy for nonprogrammers to run instrumentation without knowing much.
This takes away from our students learning about embedded code and
sequential programming. Thats where the extra companies come in to
write a compiler so the students have the option to use C C++. There
is still the matter of converting Labview stuff to be callable by the new
compiled code. Are you seeing a pattern here? We are taking NI and trying
to convert it back into what we already have.


Labview is as powerful as any other object orientated language. The fact that it's objects are depicted by pictographs instead of words does not change that. Labview can also import into it any API (created from C/C++/Pascal/VB/C# etc,etc,etc) ... the only issue is the base processor it is compiled for and the hardware specific calls.


I thought well at least we will have access to NI's incredible Vision packge
VBAI which would finally allow our kids a great vision tool that is easy to
use but no we don't get that either. They are going to write something that
allows us access to some vision tools ( dont' know which ones).


More than likely it'll be a stripped down version of NI Vision and will be imbedded into the FPGA


I really like NI. They are a great company and make great hardware that
is almost always callable by langauges like VB ( still the most popular
programming language that's in use), also callable from C++ but they only
support hardware support APIs. This is how we use it, not LABVIEW.
With no zoom feature on Labview ( they have promised this for years, its
there number one complaint from users on their list) Its hard to isolate
sections of the code to allows students to focus on a small part at a time.
Very hard to document since its all just pictures. I am very familiar with
labview and write an array of clusters with properties any day but this
is not what we should expose our students to at this time. Its great for
what its intended. Doing some instrumentation with graphing without much
knowledge.



Oh my gosh,I've been doing it wrong all this time. I've been using LabView to control motion control systems for a manufacturing enviroment for the last 5 years. How could I have been so wrong :D



One of the workaround options is to compile LabView to Dll see http://zone.ni.com/devzone/cda/tut/p/id/3517

Another thing, why write a new compiler when you have NI CVI
http://www.ni.com/lwcvi/ this allows NI calls C code to be writen in Visual C++.


My assumption (yeah, I know what happends when you assume) is that we will be getting a stripped down version of this compiler, and that it will allow calls from C/C++ (but possibly not VB or Pascal)


With all the serious new embdedded hardware out there today there are
other options. Dean charges us with making the minds of tommorow
with the ability to solve the worlds problems. Its a lot easier to do that
when our students know they can buy the processor we use in an IFI
controller for less than 10 bucks and make the astounding machines they
make now. If we go this route they need to buy a 2000 dollar Compact
RIO to make a new IPOD?


The IFI controller was $400.
We do not yet know the price of a second cRio, so for now I cannot comment on the value (or not)


And by the way where is the 3.5+ pounds coming from in our weight
budget? The wheels?


Sounds like a challange to me.


Sorry for the size of this post and but I want us to make some noise here so we as a community make this decision. I only hope the reason we are doing this isn't money based that NI is a large sponsor.(notice how small the
microchip sponsorship logo was on the banners at Einstein?)


No problem about the size of your post. You have concerns (and valid ones at that ... I just disagree, but thats my opinion). CD is a place for these discussions.

NIs and FIRSTs motivations should be questioned. As teachers/advisors/mentors we are charged with questioning things. However, in this case, I believe (my opinion) that you are reading too much into logo sizes and corporate shenanigains (although I'll be the first to say I can be wrong).


If a moderator from FIRST is reading this please contact me. We need to
talk. You guys are trying to do the right thing. So are we.

The above is JM(NS)HO

[adman]

Yes! 100% correct on all counts--being an embedded developer myself, these were the exact complaints I had, but didn't know if I should mention them here or not.

If you want someone else to help "make noise", I'll be glad to join in...

thanks for the vote of confidence on the post I was a little scared to
put it all down but like you I have a lot of years, and about 250000 controls
out in the world doing the job with little bitty micros.

At the weigh in area many engineers and mentors voiced their concerns
about the way the system seemed to be "not quite the right fit yet".

You know how cool it is when a student cranks up their first micro!
We need to keep the dream alive. If we can use NI and do that then great.

[adman]

I, too, have experiance with NI equipment. Believe me, their staff is well equipped to handle any level of technical difficulty. And with the amount of equipment that FIRST will be purchacing, a support agreement should be supplied. I trust FIRST to make sure on the support aspect of this deal.



The weight is nothing but another engineering challange. And the adaptor boards are nothing but breakout boards, a standard in manufacturing automation.



More than likely FIRST is going to use the FPGA to have the DIO mimic PWM outputs. They also talked about on-board image recognicion (sp?) and OCR capabilities. Most likely these will be on the FPGA. FIRST may also include the data transmission encryption keys on the FPGA so that they will be much harder to be spoofed, and can be changed by pit admin with just a download.



From what I've seen, the upconverter they use is high frequency and thus little noise generated.

I too am a bit concerned about the power loss and power consumption of the controller (as we haven't seen any data on that yet), but I will hold judgement on those until I see the datasheet for the unit.



Labview is as powerful as any other object orientated language. The fact that it's objects are depicted by pictographs instead of words does not change that. Labview can also import into it any API (created from C/C++/Pascal/VB/C# etc,etc,etc) ... the only issue is the base processor it is compiled for and the hardware specific calls.



More than likely it'll be a stripped down version of NI Vision and will be imbedded into the FPGA




Oh my gosh,I've been doing it wrong all this time. I've been using LabView to control motion control systems for a manufacturing enviroment for the last 5 years. How could I have been so wrong :D




My assumption (yeah, I know what happends when you assume) is that we will be getting a stripped down version of this compiler, and that it will allow calls from C/C++ (but possibly not VB or Pascal)



The IFI controller was $400.
We do not yet know the price of a second cRio, so for now I cannot comment on the value (or not)



Sounds like a challange to me.



No problem about the size of your post. You have concerns (and valid ones at that ... I just disagree, but thats my opinion). CD is a place for these discussions.

NIs and FIRSTs motivations should be questioned. As teachers/advisors/mentors we are charged with questioning things. However, in this case, I believe (my opinion) that you are reading too much into logo sizes and corporate shenanigains (although I'll be the first to say I can be wrong).



The above is JM(NS)HO

Sorry about I don't know what the JM(NS)HO is but thanks for the
review. The reason I want FIRST to contact me is that I was prepared
to run all 1500 controls on my production line for at my cost to help first teams have less money to pay out instead of
more for the new system. I dont want my company name on the banner.

Open forums do good. I took a chance and spoke many of the concerns
that occured at Nationals. I didn't mean to offend anyone. As I said
I really like NI and I am a LabView programmer but also teach HIgh School
Engineering Classes when I am not designing at my Company.

[Doug Leppard]

It is always nice to have a new controller to play with. When I got started as a mentor with FIRST in 2003 it was the first year of autonomous. The processor was a pig (no pun intended) and it couldn't do encoders, we had to build our own pre-processor to process the encoders and pass data to the FIRST processor. 2004 changed all that.

I am glad FIRST is staying up with the times. But I have concerns mostly along the price range. The Best thing about 2008 is that you could use a vex to practice things and they were close enough and cheap.

No way as a mentor can I afford to go out and buy the new system. Big question how are we going to get these systems into the kid’s hands?

How much will the FLL and FTC kits cost?

As far as power, most teams can not even take advantage of the 2008 processor. Even at Atlanta there were many teams that could not do any autonomous and most teams only doing 1-2 lines. We helped many teams to do a basic autonomous mode.

I am sure this new processor will have software that will make it easier for inexperienced teams to do more. But also it has so much power that the power teams can do so much more and thus will leave the weaker teams even further behind.

Bottom line my main concern is the cost of the new system, with something cheaper FIRST could get more of them into the hands of more people to learn from one another.

Just some thoughts.

But I am excited, once we get it you know we will work hard to maximize it.

[Daniel_LaFleur]

Sorry about I don't know what the JM(NS)HO is but thanks for the
review. The reason I want FIRST to contact me is that I was prepared
to run all 1500 controls on my production line for at my cost to help first teams have less money to pay out instead of
more for the new system. I dont want my company name on the banner.

Open forums do good. I took a chance and spoke many of the concerns
that occured at Nationals. I didn't mean to offend anyone. As I said
I really like NI and I am a LabView programmer but also teach HIgh School
Engineering Classes when I am not designing at my Company.

I apologize if I came off kinda heavy handed (wasn't my intention). My intention was to show my background with NI equipment (mostly LabView programming with NI or MCC DAQ modules), which seemed counterpoint to your discussions and concerns.

oh and JM(NS)HO = Just my (not so) Humble opinion :P

I, too, have my concerns about the new controller. I'm concerned about the level of abstraction that LabView and VxWorks gives, and that the students may be missing out on protocol and hardware control stuff. Curently, with the IFI stuff, setting a PWM doesn't require the kids to learn about the timing of the 'on' pulse, about hardware delays, or any of that protocol ... and I'm concerned that we may be getting farther away from that understanding and utilizing systems and controls that students have no idea how they work.

My other concern is that teams will be getting 1 of these units and if it gets damaged, some teams may not be able to pay for a replacement. Depending on the cost of a replacement, teams might be required to skip a year or 2 if their controller becomes damaged. It's my hope that FIRST gets a decent enough discount for a single replacement (or spare) unit so that teams don't have to worry about this (I know they are working on it ... but it is a serious concern).

[qnetjoe]

Doug has a great point there are alot of teams even at nationals that can only do a few lines of code. Before everyone here just complains, just remember that there is a growing divide between FRC teams.

For example, I have had PAY to mentor FRC teams for the last 5 years. Some of these school can't even afford wire. Plus there are teachers that just run a team for the stipend. Compare that to one team that I know that get 1.3 MILLION dollars a year, over 50 mentors and have there own 100,000 sq foot workshop, equipped with 30+ CNC machines (They also do a lot more than FIRST). This divide is not just in the financial realm, but also in # and quality of mentors/teachers, and access to resources. We need to realize this and work hard at creating a community so all teams can fulfill the vision of FIRST.

The new controller helps is a lot of areas. I have seen some of the best FLL programmers just get intimidated my the nature of C and decide not to pursue programming at the FRC level. One of the biggest benefits of the new controller is a similar and familiar interface across all levels of FIRST.

FRC hardware was becoming rather clickish. the ifi stuff does not scale to handle a lot of the sensors and buses that are out there (CAN anyone?). The new controller give us so much more and above all it gives us the ability to freely and easily adapt this to other challenges outside of FIRST. We need to give NI and FIRST a break and let them develop the new controller. IFI had years to perfect the controller and it was still far from perfect.

[NCollins]

I suspect the Cisco example showed access points spread apart by some tens of meters. This is enough to reduce the interference seen at the access points.

Cisco had their access points only ten feet from each other and sent all of the data from a single point.


I have no idea what 5.47% crosstalk interference means.

It means that through extrapolation of the power curves of a wireless network the percentage above -30dB is 5.47% of the area with respect to a full power range.

I would expect that the total combined throughput of the 6 networks you suggest would be well below that of a single network. Operating 6 robots on 1, 3, 5, 7, 9, 11 would probably not be too pretty, especially with synchronous traffic. When the robots are in close proximity, they will overwhelm the signals from the much more distant stations they are communicating with. The traffic would have to be extremely low for this to be workable.

Yes there is a drop in throughput but the robots only need 19.2 Kbps. Wireless can run up to 11Mbps. This means there can be almost a 99% drop and the robots would still work fine.

[yoyodyne]

Adman,

The points you make are appropriate and well measured. You can always pound a square peg into a round hole if you use a big enough hammer. The benefits this system brings are outweighed, by its cost, and size, weight, and power (SWaP). I see this abstraction as a step in the wrong direction in terms of teaching embedded system concepts and showing students that they have the technical capability and financial resources to build a micro-controller based subsystem. As an example, we had team members build an ATtiny2313 based project in the pre-season and as a result we were able to modify those to make a custom programmable Robocoach transmitter and multi-channel receiver. One of the good things about the IFI RC in my opinion was that teams were encouraged to build sensor co-processors and at least for larger teams, that was an excellent way to allow more students to be involved in both the HW and SW aspects of the control system. Somewhere in this thread the comment was made that a CAN bus interface was not possible with the old RC but I think they failed to see that a CAN to RC (maybe serial, or analog) converter board project would be a great learning opportunity.

I think that a team really needs three control systems; one for the competition bot, one for some type of test/integration platform/mobility base, and a third for control system development. The VeX controllers were a very good low cost option as extra development platforms for our software developers. The one extra cRIO is going to severely limit the time each developer has to unit test their code. Maybe the new system will be so abstracted and easy to use that little or no unit testing will be required (humor) but in all seriousness hard lessons learned about data types, protected sections, what the volatile keyword means etc. are likely to be lost.

From a teaching perspective what was really valuable about the FRC programming experience was that it was the first time most students worked with something besides FLL block diagram code or the school CS classes in JAVA, visual C/C++/C#.

I think that we will put even more emphasis on the use of micro-controller based co-processors as a way for students to learn how to develop powerful low cost, low power affordable solutions.

[dlavery]

For those worrying about security - I was told by an NI rep that FIRST recognized the issue and now has NASA helping them develop a method of securing communication.

I am not sure who from NI would have said that, but it is incorrect information.

[JesseK]

I am not sure who from NI would have said that, but it is incorrect information.

During the mentor Q&A, the FIRST rep said that the security issues would be outsourced to a private firm. He didn't mention the name of that firm.

[adman]

I think we are starting to get a consensus here.

* We all want our students to learn how things really work.
* We all see students become somewhat intimidated sometimes by C at first.
* We all have seen students overcome their fear of C
* We know LabView is a great way to teach control system basics but
can mask the background info that leads to true product design
in the embedded world if that is our cause
* We are all very nervous about how much these systems will cost
* We see the split in minimally backed teams and the teams that
may have these already on order from NI.
*Also considering we are adding more parts to the system, the analog
adaptor plugin and the expansion board and the power inverter the
robot now has potentially more things to trouble shoot to keep the
robot running.

Let's all make solid proposals of how we can solve these problems of
implementation.

[Chaos204]

Am I the only one who has yet to see any video demos or anything on the site? not that i am antsy or anything!?

[Adam Y.]

I see this abstraction as a step in the wrong direction in terms of teaching embedded system concepts and showing students that they have the technical capability and financial resources to build a micro-controller based subsystem.
That's not what FIRST is about. It may be how your car works in real life but it isn't the ideal way to introduce kids to programming because embedded systems needs a hefty understanding of electrical engineering.
We see the split in minimally backed teams and the teams that
may have these already on order from NI.
As yoyodyne clearly shows the split was exasperbated by the old system as well.

[yoyodyne]

That's not what FIRST is about. It may be how your car works in real life but it isn't the ideal way to introduce kids to programming because embedded systems needs a hefty understanding of electrical engineering.


As yoyodyne clearly shows the split was exasperbated by the old system as well.

We have a wide spectrum of programming abilities and experience as I would assume is the case for most teams. In some cases previous experience came from FLL and FTC and in others it has been from their own development activities including of all things Gamemaker which is a pretty good introduction to OO methodology. There has always been the option to program graphically but our experience was that the students that were interested in Kevin’s code were able to take that knowledge and develop their own microcontroller projects some for the robot and some for themselves. I don’t think the teams are going to get the VxWorks source and probably not the BSP source so the opportunity to learn at this level through the FRC RC has been taken away. You don’t need to understand anything about electrical engineering to read a micro-controller data sheet and learn from example how to service interrupts and use integer math so you don’t need a 32 bit processor to run PID loops for instance.


Is what you are saying that the split with the old system was mostly in capability while the split for the new system will be financial? From my perspective there will always be a capability split due to the difference in engineer/mentor availability. The teams that were relatively strong with the old system will also be relatively strong with the new system but now, only the well financed teams will be able to buy more than two? control systems.

[dcbrown]

I can has link? All I could find was the WPI page and some stuff on NI's site.. Not 100MB, no enough to get started.. If all else fails, be cool and upload a package to FileDropper (http://filedropper.com) or something?;)

I can't upload the the documentation because it is copyrighted and is not publically available - at least in any way I could find. You can download your own documentation from Wind River by agreeing to the licensing terms via the 3.6 30-Day Evaluation kit (http://www.windriver.com/evaluations/). This is the top link in the list.

The above evaulation kit has the full doc set for VxWorks. Just remember, VxWorks is multiplatform targetted so this is the generic doc set. Some components such as full MMU support may not exist in the cRIO environment. But all in all, the documentation is a place for the software mentors to start.

I'd start with the following

Wind River General Purpose Platform, VxWorks Edition - Getting Started - general overview


And then move on to:


VxWorks Kernel Programmers Guide
VxWorks Application Programmers Guide
VxWorks Device Driver Developer's Guide
VxWorks Kernel API Reference

Wind River Workbench User's Guide
VxWorks Command-Line Tool User's Guide
Wind River Workbench Host Shell User's Guide
Wind River Host Shell API Reference

Wind River Host Utilities API Reference
Wind River System Viewer User's Guide


And a whole lot more...

[Jay Lundy]

You can download your own documentation from Wind River by agreeing to the licensing terms via the 3.6 30-Day Evaluation kit (http://www.windriver.com/evaluations/). This is the top link in the list.

I downloaded that too and it should be a great introduction to vxworks and the Wind River Workbench, especially with the simulator.

I'm not sure if Wind River is creating a custom workbench for FIRST, but it would be great if they could get a full version of the workbench to teams before kickoff so we can familiarize ourselves with it. The Eclipse plugin for the workbench seems to be pretty extensive, so even though the code we write with the WPI libraries may be different, just being able to explore the IDE before kickoff would help a lot.

Like dcbrown said the evaluation comes with a lot of docs. There's also some info freely available at their site:
The main product page for the workbench is at http://www.windriver.com/products/workbench/
Here's a good introduction: http://www.windriver.com/products/product-notes/Workbench-Tech-Note.pdf

[Los Frijoles]

Although I will not have a chance to work on the system (I am graduating and moving about 1000 miles away from my team), I feel that this system will be a boon to FIRST and that it opens many doors. Here is what I see from my perspective:

Pros:
-Labview is easy to work with...easier for teams with no programming experienced people to operate
-Much higher processing capabilities
-Possibility for better, faster, and more advanced programs

Cons:
-Big
-Heavy
-May be a bit of a change for people who are already experienced with Microchip microcontrollers

[comphappy]

I feel like people keep missing this:

What is the cost of cRIO? Will this change raise the entry cost for teams?
A No. Due to the investment being made by NI ($10M over 5 years) and NI’s suppliers, FIRST will
provide teams with a more powerful control system without raising the cost to compete. Because
there are many factors that determine the final price of the kit of parts, the exact entry price has
not been determined yet.

While it may be expensive hardware, they are making it available with out raising the costs of entry.

I just unwrapped labview and installed it from this years KOP, looks interesting. As a lead programmer, founder of our team, and soon to be senior, I must look out for the future of the team. While i am an ardent supporter and advocate of ASM and C, LabView has a lot of potential for sustainability, while holding the real world experience that EasyC and what ever that other thing was lack.

As for the all around control system it has a lot of potential, I am peeved that the FPGA will be very limited if not completely lock away from us, I think that would have left us all where we wanted to be with the full spectrum of options.

I am just waiting for the day when our robots have full server racks crunching numbers so hard we dont have to worry about who is going to drive the robot, unfortunately i don't think I will be a team programmer that day, but I sure hope I will be the mentor watching this realized.

[Vikesrock]

I feel like people keep missing this:

What is the cost of cRIO? Will this change raise the entry cost for teams?
A No. Due to the investment being made by NI ($10M over 5 years) and NI’s suppliers, FIRST will
provide teams with a more powerful control system without raising the cost to compete. Because
there are many factors that determine the final price of the kit of parts, the exact entry price has
not been determined yet.

While it may be expensive hardware, they are making it available with out raising the costs of entry.

Yes, they are giving us one without raising the cost of entry. However, to keep previous robots functioning a veteran team will have to purchase a new control system every year as FIRST will only give us the first one.

[comphappy]

I would not consider that to be a major concern, and based on how they bolded the word HEAVILY my guess is it wont run more then 1k, and how many of them do you need at once. I would figure one for the current robot and one for prototyping with the old one would be enough, the modules are easy to swap. I will reserve my final call to Fall/Early Winter when all this is finalized.

[comphappy]

FYI the announcement video is now up so my guess is the others are soon to follow:
http://media.wpi.edu/News/Events/Robotics/First/FRCCS/videos/2009FRC_CS_Announcement.wmv

[Madison]

I would not consider that to be a major concern, and based on how they bolded the word HEAVILY my guess is it wont run more then 1k, and how many of them do you need at once. I would figure one for the current robot and one for prototyping with the old one would be enough, the modules are easy to swap. I will reserve my final call to Fall/Early Winter when all this is finalized.

We usually have four or five robots running at any given time. Keeping that up with the new control system -- even if it's heavily discounted to $1000 -- represents a significant increase in cost to our team. We may gain more processing power, but it will significantly affect how teams are able to reach out to their community to generate interest in FIRST, or to help new teams get their feet wet in the preseason.

Registration fees were raised $1000 to cover costs associated with providing each team a new control system each season. If continuing to provide a new system to teams each is no longer possible, the registration fee should be reasonably lowered again.

[Drwurm]

Our team practically depends on old robots for all of our PR. We try to get at least one to every demonstration. Not getting a new RC every year is going to hinder that.

I can understand that the new system may be too expensive to provide a new one every year; but I cannot understand why FIRST would have gone with such a pricey system to begin with. Sure, the OI/RC setup needed a little dust-off, but this is overkill. I don't think any FIRST team is near the level that requires this much power.

So far I am not enthusiastic about this new system, however, I will hold final judgment until I can get my hands on the final version.

[JesseK]

I'm enthusiastic about the possibilities of this system. There are huge ramifications of being allowed a laptop at the driver's station. Even if much of the communication between the laptop and driver's station is limited, we'll still have the flexibility for more driver control. This could be anything from advanced GUIs to GAs to sensor matrix analysis via Matlab standalone scripts.

For demonstrations, let's consider a couple of things:
1.) You'll still have your IFI bots to take to demonstrations
2.) It is the cRIO that we get one of. We should get a new PDB & sidecar every year. Since the cRIO itself is modular and takes less than a second to reprogram, it's possible to move the cRIO from bot to bot and reprogram it during a demonstration. Sure, we can't show cRIO-based bot-to-bot interactions, but we will still have IFI-based demo bots for the next couple of years.
3.) Our team only has 1 demo each year in which we take more than 1 bot. Every other time more than 1 would be too much. Is this not the case with most teams?

[thefro526]

I saw a little bit of the new control system when I was in ATL. It looks like the possibilities are endless for those who wish to push the envelope, but for teams like mine we won't really have a need for all of this extra power and features. Some of the more basic ones, like USB interfaces on the OI, are nice and easy for all of us to use, but then there are other more advanced features that are going to be useless to a lot of teams.

In my opinion the new system is going to be a nice change if introduced into FRC right. I personally think that next year's game should be one similar in game play to the last 4. I.E. simple-ish auto mode, tele-op goals that do not require amazing control and programing skills, and a way for teams to score with little to no effort. This game would be a good way for teams to learn the new control system and good way for FIRST and NI to work all of the bugs out.

Then in '10 you begin to push teams into using the actual power of the new system. Make it more advantageous for them to use some of the more advanced features now that they have learned the basics. Even still make it so that teams who don't have the resources to use the new system to it's full potential have a way to remain competitive.

My prior statements may be totally off base though, they are coming from the guy who designs robots and thinks three limit switches is a lot. j/k ;)

[Mark McLeod]

I like the technical capabilities of the new system and I'm sure we'll be able to work around the limitations it places on us all, but it will take some adjusting to. The cRIO will open up more possibilities for inspiration. We love new challenges. I'm not worried that we'll see magic next season, but do like trying to foresee potential issues that we can prepare for now. The more information we can gather now, the easier it will be to advise teams.

I'm concerned about how turnkey the system will be for teams with few or no technical mentors. The multitude of cross wiring that all looks alike in this new system (multiple 5v, 12v, 24v power connections) worries me. We've all seen lots of examples of cross-wiring and loose connections by team's with little electronics experience that threaten to ruin an inexperienced team's experience.

Electronics layouts will take on a 3 dimensional design. While the cRIO is resistant to abuse, the connections to it are not. It makes me nervious to see those delicate convertors sticking up into the air off the cRIO brick. The brick will survive, but we'll need spares of the exposed connectors and analog and solenoid circuit boards. I imagine bricks will often be mounted on their side to provide some protection.

I am concerned about the development software licensing issues. I really liked the team-wide mcc18 license that allowed multiple students to learn to program at once, in the lab and at home. gcc will still allow this, however, Labview will not. I had similar issues with the limitations on the single team EasyC license.
I can't count how many problems I had with installing software on school provided laptops without an administrator. I'd meet the students at night and be leaving fix-it notes for the IT department in the morning. For example, EasyC stuck on Vex, because it had to write to a protected folder and then be restarted (not to pick on EasyC or school required IT protective measures).


3.) Our team only has 1 demo each year in which we take more than 1 bot. Every other time more than 1 would be too much. Is this not the case with most teams?

We, like Madison, also have five or more older robots that are used quite a bit. We typically loan robots out to pre-rookie teams for competing in pre-season events, to demo at their school, or just to gain experienced in taking them apart and putting them back together.
On a given day we've had one robot driving in the Homecoming parade, another couple competing at a local off-season event with pre-rookies, a robot off being presented to a school board that lacks an FRC team.
During build season development the older robots are used for prototyping concepts, driving against the new robot, etc.

If we (I really) can afford to purchase an extra cRIO, then we need it as a portable workshop to take on the road to teams and to drive prototyping platforms. Our future retired cRIO robots will likely have to be retrofitted with older controllers much as we do with our old pBasic controllers. Advanced capability will be lost unless we devise our own replacement system. I am concerned about any necessary upgrades in later years that may render an expensive investment in a spare cRIO worthless.

The expected exorbitant cost of the cRIO for subsequent years is not justifyable as an expense for any of the teams I work with, on a post-season robot. Many teams I deal with are on a very thin shoestring and must recycle parts off older robots in order to compete anyway, so this won't really be an issue for those really low-end teams.

[yoyodyne]

I am concerned about the development software licensing issues. I really liked the team-wide mcc18 license that allowed multiple students to learn to program at once, in the lab and at home. gcc will still allow this, however, Labview will not. I had similar issues with the limitations on the single team EasyC license.

Wow! I kind of figured that along with the new WPILib being open source there also would not be per-seat licensing for the new control system development environment. I guess it was naive of me but I figured that is why we would be getting a "custom" NI build. If there is, it is really going to negatively impact the way our team develops and unit tests software. Do you think that there will be license costs from both Wind River and NI? If that is the case, then there will be an impact to the teams that take the C route as well.

[Joe Ross]

I am concerned about the development software licensing issues. I really liked the team-wide mcc18 license that allowed multiple students to learn to program at once, in the lab and at home. gcc will still allow this, however, Labview will not. I had similar issues with the limitations on the single team EasyC license.
I can't count how many problems I had with installing software on school provided laptops without an administrator. I'd meet the students at night and be leaving fix-it notes for the IT department in the morning. For example, EasyC stuck on Vex, because it had to write to a protected folder and then be restarted (not to pick on EasyC or school required IT protective measures).

The Labview that is provided in the kit the past few years has been an unlimited license for FIRST use. See the following post: http://www.chiefdelphi.com/forums/showthread.php?t=51405

[Eldarion]

Wow! I kind of figured that along with the new WPILib being open source there also would not be per-seat licensing for the new control system development environment. I guess it was naive of me but I figured that is why we would be getting a "custom" NI build. If there is, it is really going to negatively impact the way our team develops and unit tests software. Do you think that there will be license costs from both Wind River and NI? If that is the case, then there will be an impact to the teams that take the C route as well.

I agree 100% with the above.

One other issue that I haven't seen brought up here is platform lock-in. With the old system, teams could use Windows, Linux, or Mac to program the robot with, and the robot code itself was fairly portable between microcontrollers. In addition, low-level C programming is pretty much standard in the embedded systems world, so students are gaining real-world experience with direct application to industry.

With the new control system, you are locked to Windows, regardless of the method you use to program. LabView will run on Linux; the software that it uses internally to generate the VxWorks image will not (BTW I don't think Wine will solve this problem unless you can get an entire LabView install into Wine along with the other tools.)

If you decide to use LabView to program, the problem is even worse. LabView programs cannot be used on anything that is not directly supported by LabView, or converted to another, more standard programming language! Also, I question the applicability of LabView programming knowledge in industry--sure, some large companies and colleges have access to LabView, but most do not due to the extremely high cost involved.

The OS lock-in problem will only get worse when Vista takes over--I have spoken with many developers who cannot stand Vista and have switched to Linux, finding it better suits their needs.

Just some futher thoughts, feel free to comment on them...

[ND4SPD]

The new cRIO system looks like the cRIO-9012 model (specs wise) with the integrated controller and chassis. The price range looks like it will come to ~$2000-$3000 dollars for the whole system.

When at one of the presentations, one of the NI reps said that the 802.11a standard would be used. This would make sense because of the 11 channel system that it has.

The fact they are letting us compile with C++ opens up lots of oppurtunities. You could actually code in a different languages (provided that you could convert the C++ libraries to a different language) and then convert to C++ to use with the cRIO system.

I think that this new system is way better than the old. The IFI system always seemed very limited to me. You had limited memory. The system couldn't support higher level language and as a result class files/namespaces/polymorphism and other higher level language features could not be used. I'm really excited to get my hands on this new system. I heard that this system will be available for us in November, can anyone confirm this? Meanwhile, I'll practice LabView with mindstorms :rolleyes:

[Adam Y.]

With the old system, teams could use Windows, Linux, or Mac to program the robot with, and the robot code itself was fairly portable between microcontrollers. In addition, low-level C programming is pretty much standard in the embedded systems world, so students are gaining real-world experience with direct application to industry.
We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

[Doug Leppard]

Help me with this. As presented I thought this was a FLL-FTC-FRC solution. How does new system work with FLL and FTC? Do they have smaller cheaper systems that can migrate from FLL to FRC and beyond?

Or did I get this wrong and this is only for FRC.

[yoyodyne]

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.


Keep in mind that the cRIO is an embedded system. VA Tech did use Lab View on their DARPA urban challenge robot but the image processing, navigation, obstacle avoidance, etc. was performed on a pair of quad core servers. The cRIO was relegated to the break, throttle, and steering control functions that are pretty much what we have been doing with the current control system for years. I’m not saying that you can’t do a lot more with 64MB of RAM and a 32 bit processor but you still might actually have to worry about the efficiency of the implementation. You will always find yourself in a resource constrained situation if you are in a competitive real-world situation. I'm sure that the game designers will make sure of that soon enough.

[pogenwurst]

Help me with this. As presented I thought this was a FLL-FTC-FRC solution. How does new system work with FLL and FTC? Do they have smaller cheaper systems that can migrate from FLL to FRC and beyond?

Or did I get this wrong and this is only for FRC.

I believe the point is that the controllers for the FLL (NXT), FTC (an NXT-ish device), and FRC competitions are all programmable with LabVIEW or a LabVIEW-derivative, so that students can more easily build upon prior experience as they "graduate" from program to program.

[Danny Diaz]

I kind of figured ... there ... would not be per-seat licensing for the new control system development environment.

The Labview that is provided in the kit the past few years has been an unlimited license for FIRST use. See the following post: http://www.chiefdelphi.com/forums/showthread.php?t=51405

Thanks Joe - there will NOT be a per-seat licensing for any software from National Instruments. Plus, to my knowledge, NI has even made sure that per-seat licensing restrictions for WindRiver tools have been removed as well. If only one person on your team can program, what good is that? I will refer back to the link Joe provided above, and state that everything in that thread still remains true.

-Danny

[Kevin Sevcik]

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.
*chokes* Erm. A bold statement there. But I'd venture to guess that procedural programming makes up a majority of the actual robotics work out in the Real World. (ie. not NASA, academic research, or the military) See this post (http://www.chiefdelphi.com/forums/showpost.php?p=740069&postcount=16) for an idea of things. OO is fine and dandy, and useful for doing highly complicated and difficult tasks like machine vision and such.... But there's a distinct difference between complication and utility.

[Jay Lundy]

I think we are starting to get a consensus here.

I agree these seem to be common concerns, so I'll put in my 2c.

* We all want our students to learn how things really work.Two points:

1. The old system and the new system teach different skillsets. Which one is more important is a matter of opinion.

2. If you want to teach both skillsets, just buy a PIC on your own and interface it with the cRIO. That's a lot easier than building a custom board with a PowerPC running VxWorks and interfacing it with a PIC.

So if your goal is to build a robot, the cRIO is clearly better (there's a reason they send 32-bit processors running VxWorks to mars and not PICs). If your goal is to teach, the cRIO gives you more opportunities to do that.

* We all see students become somewhat intimidated sometimes by C at first.
* We all have seen students overcome their fear of C
* We know LabView is a great way to teach control system basics but
can mask the background info that leads to true product design
in the embedded world if that is our causeThese are all related to the fear that NI's ultimate goal is that someday we will all be programming our robots in LabView because the C/C++ interface is crippled. The NI reps have stated many times that is not the goal and the C/C++ and LabView libraries will be of similar quality. If you want to program in C, nothing is stopping you.

* We are all very nervous about how much these systems will costI agree that the overall cost will increase for teams that may want a second controller and that's something FIRST should consider. However I don't think the wild speculation in this thread about what the actual cost will be and then coming to conclusions based on that is helping anything. What is clear is that the cRIO's will be sold for around how much each unit costs to manufacture, which is significantly less than the normal price.

* We see the split in minimally backed teams and the teams that
may have these already on order from NI.Back in 2003 WildStang used a custom board to program a positioning system for their amazing autonomous when everyone else was programming in PBasic with like 100 bytes of RAM. Now veteran and rookie teams both have access to incredibly powerful hardware. The libraries and the increased emphasis on code sharing will help the rookies take full advantage of the cRIO. I predict the split will always exist, but next year it will be smaller.

*Also considering we are adding more parts to the system, the analog
adaptor plugin and the expansion board and the power inverter the
robot now has potentially more things to trouble shoot to keep the
robot running.I agree, but I don't see that as a significant challenge. Plus with the wireless programming interface and the increased debug capabilities, programming problems will be a lot easier to find so it kind of balances out.

IMHO I think everything except for the cost is a non-issue.

[Doug Leppard]

Jay,

My big concern is that with current system we could have many kids on a vex system in preparing for FRC. You could proto-type what you wanted to do on vex.

But the new system you don't have that link to the two systems other than a labview similiarity.

I am sure it will all work out.

Plus most of us will not get the crio system until Jan 2009 because of cost and there is a lot to prepare for in understanding crio.

Should be an interesting year.

[Arefin Bari]

This was sent out tonight...

Greetings Teams:

We have some important information from National Instruments (NI) to share with you:

-------------

Firstly, we would like to extend our congratulations to all FRC Regional and Championship teams for a very successful 2008 FRC season.

As we know you’ll soon begin preparing for the 2009 competition season, we wanted to answer the two questions we’ve heard most frequently asked about the new control system. We are excited by the energy and enthusiasm you’ve shown for this technology change, and will continue to share information as it becomes available.

When will we receive the new control system? Is there any benefit to purchasing an NI CompactRIO controller now?

FIRST is continuing to work out the logistics of the exact availability date for the new control system, but it will be no later than Kickoff of the 2009 season. We are working extremely hard to make the new system available as early as possible.

We know some teams want to begin using the new control system. However, we advise against purchasing a current NI CompactRIO system from National Instruments. The prices listed on www.ni.com do not reflect the discounted price FIRST teams will pay for purchasing additional controllers, and more importantly, the software experience for the 2009 FRC controller in the 2009 Kit of Parts will differ significantly from an off-the-shelf NI CompactRIO system. Additionally, you will not be able to work with the other components of the control system. Instead of purchasing a NI CompactRIO controller now, we recommend that teams begin learning programming skills in C/C++ or LabVIEW.

What can we do now to learn more?

You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System
* Slideshare: Training sessions from the 2008 Championship
* Tutorial: Program the New Controller with NI LabVIEW
* Tutorial: C / C++ Programming for the 2009 FRC Control System


FIRST, National Instruments, and WPI will continue to develop and distribute training materials to support the set-up and use of the control system in preparation for the 2009 season. This training will be distributed through the web and live workshops, and there will be training available for the summer months. We will always post the latest training information on www.usfirst.org/community/frc and on www.ni.com/community/first.

Please send us your questions, comments and feedback via the National Instruments Community blog found at www.ni.com/community/first. We wish you the best of luck in the off-season, and thank you for helping support the FIRST mission and vision.

Go Teams!

[dcbrown]

Previously with the PIC, "system programmers" had the advantage and "application programmers" who wanted all that h/w stuff hidden were at a disadvantage. The advent of WPILIB and EasyC closed some of that gap, but still the plaform was more systems programmer friendly.

The platform was kinda backwards, often requiring a lot of systems knowledge before you could become an applications programmer. This typically meant new programmers were at a disadvantage.

The new platform is more the norm/inverse of that. The entry level for all is as applications programmers using the API of the RT/OS either within kernel tasks or RTPs (real time process). If you want to be a systems programmer, the entry costs in terms of time, effort, and knowledge just increased. But that is usually how it is. The new platform should align better with both sets of folks.

The WPILIB will be just another library/plugin option on top of the RT/OS that provides an API to access the pins, PWMs, etc. that we're familiar with on the PIC. Having the source may or may not help much unless the NI drivers for the modules have the source included in the cRIO kit also. But this library will be *the* method of accessing DIO, ADC, PWM, and relays for almost all but a few teams.

For example, lets say the device special file for the digital io module was /tyDIO and pins 0-15 were /tyDIO/0 .. /tyDIO/15. Then WPILIB would need to do something like the following to read an input pin.


fd = open( "/tyDIO/0", O_RW, 0 ); // open DIO driver for NI module, pin 0
bytes_read = read( fd, &byte, 1 ); // read value of pin 0
close(fd); // close device

** this is pure swag -- there are several ways of doing this, but this is the
most direct but again depends on the device naming scheme for the
modules and its subparts.


This assumes the VxWorks io driver model is used and not bypassed in some bizarre fashion. Or instead of using the provided NI module driver, WPILIB may decide to directly implement their own replacement NI module driver to collapse some of the details but that sounds like way too much effort and then they'd need to support that flavor of NI module driver... Anyway in the PIC, systems programmers knew how to directly access the h/w. In the new model it isn't that simple, its easier to just access the NI drivers. It will be nice to get at least some documentation on the NI module driver APIs -- it would go a long way to understand how some of the system pieces fit together.

The biggest problem I'm having wrapping my head around is the sheer size of the API and doc set for VxWorks along with a lack of information on what the NI driver/library interfaces look like. But all in good time...

[Greg McKaskle]

The NI I/O model depends on the HW target, but in this case the FPGA and the PPC use a memory mapped register set. Instead of the driver kit seen above, you'd see something equivalent to an

NI_RIO_PEEK(FPGARef, address, &result);

The FPGARef is the result of an early Open that loads and/or connects to an FPGA image.

Then because some of the access would be difficult, there is a layer that supports critical section exclusion and provides cleaner C datatypes. This layer of C++ objects is generated with the FPGA image, and that is what WPI will link against.

Greg McKaskle

[steveg]

We are building robots not a microwave. In this case you need to change the requirments from a procedural to an object orientated language if you want to do anything useful. I've bought a few different books on robotics research and it always ended up having it skip out of procedural designs within two or three chapters.

This is not really true at all. You can do anything that you'd like to do in an object oriented language in a procedural language. Having worked on EKF and SLAM algorithms on both a PIC and a Blackfin (just to clarify, the EKFs were on both the PIC and Blackfin. SLAM was only on the Blackfin. I imagine with all of the multiply-accumulates SLAM needs, it's not really feasible to implement on a PIC.), I can tell you that if you're doing something where you need an object oriented language, you're doing it wrong.

Having said that, an OO language does make it much nicer, especially if it supports STL classes.

[yoyodyne]

Previously with the PIC, "system programmers" had the advantage and "application programmers" who wanted all that h/w stuff hidden were at a disadvantage. The advent of WPILIB and EasyC closed some of that gap, but still the plaform was more systems programmer friendly.

The platform was kinda backwards, often requiring a lot of systems knowledge before you could become an applications programmer. This typically meant new programmers were at a disadvantage.

Working with software at the device level is what made the FRC embedded software development experience different and in my opinion more valuable then just more applications level programming experience. After all, application programming experience is widely supported and easily accessible whether it be using the free microsoft C++ express or win/mac/linux JAVA, Python, etc. As a small example, it is clearly important that the students have the opportunity to understand that a gyro outputs a voltage proportional to rate and you can integrate that to get direction, likewise for an accelerometer. If the programming experience is totally abstracted we may as well just compete in a totally simulated first fantasy competition. Why get your hands dirty fabricating metal and hooking up wires with CAD, animation, and applications level software? Because the FIRST experience gets you beyond the computer screen. The cRIO system experience could be fantastic as long as the teams are allowed to and rewarded by writing their own VHDL or developing custom sensors and sensor interfaces. On the software side it might actually be a wonderful eye opening experience to realize that there are other data types besides long and double because in the real world of robotics and other real-time number crunching applications you might have to actually use fixed point math. It is never too early to get a taste of the real world.

[dcbrown]

You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System
* Slideshare: Training sessions from the 2008 Championship
* Tutorial: Program the New Controller with NI LabVIEW
* Tutorial: C / C++ Programming for the 2009 FRC Control SystemThis was sent out tonight...


My guesses on what the links should be based upon the above descriptions...


You can begin reviewing the training material already available online at:

* Tutorial: Getting Started with the New Control System (http://decibel.ni.com/content/docs/DOC-1663)
* Slideshare: Training sessions from the 2008 Championship (http://www.slideshare.net/nifirstrobotics/ni-first-robotics-controller-training/)
* Tutorial: Program the New Controller with NI LabVIEW (http://decibel.ni.com/content/docs/DOC-1661)
* Tutorial: C / C++ Programming for the 2009 FRC Control System (http://decibel.ni.com/content/docs/DOC-1665)

[Al Skierkiewicz]

There has been a lot of discussion about the new controller in this thread, especially on the software/programming side. (I will leave software to the experts ) I however, have an opinion similar to Mark McLeod's above. What the new controller and interface represent is a nightmare for rookie teams and those with little or no electrical mentorship. In comparing with the present controller where single point failures are reduced to an absolute minimum, the future contoller has multiple power supplies (I count five min.), negative power on the case, multiple interfaces and multiple connections between the RC and the outboard hardware. Diagnosing a failure in the controller will be next to impossible for anyone that is not skilled in in this black art. Rookie teams will be especially vulnerable to failure and damage of the control system.
We need to put ourselves in the shoes of a rookie team to see what they go through. As an inspector and mentor who regularly visits rookie teams, I can tell you that many rookies can't get a motor connected properly without guidance. To add this level of complexity will doom many rookies from participating once registered or from enjoying their first year's experience. Although, a lot of thought has gone into the interface boards and connector design, there is just too many places for something to go wrong. As Mark has pointed out, the power supply wiring is just one place that things can go horribly wrong.
Power distro is another area of concern. As I have pointed out in lectures for many years, the battery is capable of supplying 600+ amps and the power distro needs to be able to withstand that current. In addition, the design must take into account the voltage drop across the distro panel as far as power supply droop and noise is concerned. At what voltage does the DC-DC power supply drop out? I can tell you that the battery terminal voltage regularly drops to 4 volts (for short pulses) under load. Add a game that requires pushing and you will find teams with six motor drives drawing the battery down below 8 volts a regular occurence. These same teams will (and have in the past) depleted a battery in less than two minutes.
Although weight is not an issue for most rookies, it is more than considerable for experienced teams that weigh in at 120 lbs. Added together with the multiple modules teams are likely to want, the control system, DC-DC power supply and interface boards will likely produce a system that weighs in excess of 5 lbs. A considerable mass that will need secure mounting.
Finally, a delivery date of kickoff is too late (see above). When asked, I stated I need it next week. FIRST, if you are listening, please consider giving some teams prototype systems now so we can break them. Give us the chance to work out problems and solve them before the 2009 season starts.

[dcbrown]

The NI I/O model depends on the HW target, but in this case the FPGA and the PPC use a memory mapped register set. Instead of the driver kit seen above, you'd see something equivalent to an

NI_RIO_PEEK(FPGARef, address, &result);

The FPGARef is the result of an early Open that loads and/or connects to an FPGA image.

Then because some of the access would be difficult, there is a layer that supports critical section exclusion and provides cleaner C datatypes. This layer of C++ objects is generated with the FPGA image, and that is what WPI will link against.

Greg McKaskle


So NI_RIO_PEEK and NI_RIO_POKE (assumption) would work within kernel applications/tasks, but what about RTPs? Since opens are not traditionally shared across the RTP/kernel interface could RTPs do their own open on the FPGA image or will this type of macro call only work inside the kernel?

Is there a technical architecture overview document for the FPGA and NI I/O modules - essentially similar to VxWorks component API manuals? Trying to find any real tech information on this platform has been particularly frustrating. Especially since this is NOT a new platform. I don't need to know the particulars of how the FPGA/IO interface will be set up for FRC, but it would help immensely to know what a typical engineer recieves in terms of documentation, software templates, and information when they buy an cRIO IO module.

[Doug Leppard]

Excellent comments Al.

Our team has consistently helped hurting teams, and they are not all rookies, many are below 1000 in team number. It takes a deep rich team to have the skills for the mechanical, pneumatics, electrical, programming and sensors. Much less PR and fund raising skills.

Even at championships 1/3 of the teams couldn't drive forward to get the 4 points. Many teams we helped had electrical shorts or bad connected cables. Robotics, especially one that takes such abuse game after game is a complex challenge.

To me the biggest programming problem of teams is that the hardware is usually not done until shipping day, thus the programmers usually don't get the machine until that day or at competition.

I do hope they will allow a few teams (like 1902) to have the processor ahead of time if they have the commitment to help others. Our fear is that with a new system in competition there will be many problems and even the experienced teams will be scrambling to make it happen and will not be able to help others.

FIRST is committed to the kids and their future. I have high confidence they will do what is right and in the end this will work better for the kids. As a much older kid I am excited about a new toy and to be able to learn more myself.

[Kevin Sevcik]

These are all related to the fear that NI's ultimate goal is that someday we will all be programming our robots in LabView because the C/C++ interface is crippled. The NI reps have stated many times that is not the goal and the C/C++ and LabView libraries will be of similar quality. If you want to program in C, nothing is stopping you.I think our primary concern is that Labview often times makes things seem perfectly transparent, easy, and efficient when they're anything but. It's not terribly straightforward or apparent what it's actually doing with the code you've given it and unless you're paying very close attention to what you're doing, it can easily come back and bite you. I was working with a Real Time VI developed by a fellow MechE student that was being used for data-logging for an experiment. I was having difficultly getting the loop rate as fast as I thought I should be able to when I finally noticed the problem. Each data point was simply added to an array using the Insert into Array function block. The VI was blithely allocating a new chunk of memory, copying over the entire old array, and adding a single new data point to it. Lacking a minor in CompSci and thus previously acquired knowledge of how arrays actually work, I would have just assumed that that was how fast things were supposed to run. More to the point, after discovering this, I attempted to ascertain just how intelligent Labview was about resizing the array it was inserting this element into. Did it increase the allocated memory by 1 element? 10? Some constant somewhere? Did it double the size? I can get at this info for a rather lot of other programming languages, but I haven't a clue what labview is doing for me behind the scenes.

Also, to those hoping to use the FPGA like myself, you won't be subjected to VHDL unless you really want to be or are boycotting Labview. The Labview FPGA module lets you do everything in function blocks just like everything else and it then works our your VHDL code for you. Of course this is, again, just so much voodoo. I have also coded up a rather gate-hungry FPGA program to do some forward kinematics at ludicrous speed. I knew I was cutting things close on the size of my FPGA, but I didn't know how close until I changed the values of some constants I had rounded slightly out of laziness. Imagine my surprise when my design suddenly no longer fit on the FPGA. Of course changing back to my old, slightly rounded values made everything fit just fine again.....

[lynca]

Finally, a delivery date of kickoff is too late (see above). When asked, I stated I need it next week. FIRST, if you are listening, please consider giving some teams prototype systems now so we can break them. Give us the chance to work out problems and solve them before the 2009 season starts.

As a mentor of two different rookie teams, I completely agree with Al's statements, rookies will have a lot of trouble debugging the new control system when things are not working. Also, I hope FIRST distributes KITS to teams that agree to throughly test the new control system and publish their results online before kickoff.

I can understand that giving KITS to all teams will be a major hurdle, and some will feel wronged if their team does not get a KIT. However I will not feel bad if my team does not get a KIT early, but I will be quite worried if ZERO teams receive a KIT early.

[ayeckley]

Working with software at the device level is what made the FRC embedded software development experience different and in my opinion more valuable then just more applications level programming experience.

I'll second that! I've never been in love with NI hardware or software products (though I'm grateful for their sponsorship).

I wonder how many teams will sit 2009 out because of the steep learning curves? For teams that have four-year students and tight budgets it might make sense, which is unfortunate. Unless the system comes pre-configured with a very, very, strong set of reference VI's and some unbelieveably great documentation, I can envision a large backlash against FIRST by frustrated and upset teams in March 2009. The IFI reference code was pretty good - NI needs to top that.

I'd have loved to have a year or two to make the transisition. I can't see any technical reason that the two field control systems couldn't have operated in parallel in 2009 (cost issues aside). Better yet, it would have been great to let the market decide which system the customers (e.g. the teams) prefer. One entry fee gets you an IFI system, and a higher entry fee gets you an NI system. That would have made a great introduction to the economic realities of the engineering profession for students!

I also wonder if Kevin Watson will stay involved.

[Billfred]

To me the biggest programming problem of teams is that the hardware is usually not done until shipping day, thus the programmers usually don't get the machine until that day or at competition.

I do hope they will allow a few teams (like 1902) to have the processor ahead of time if they have the commitment to help others. Our fear is that with a new system in competition there will be many problems and even the experienced teams will be scrambling to make it happen and will not be able to help others.I remember NI making available some DAQ hardware to teams that proposed what they'd do with them. What if some combination of FIRST and NI accepted proposals from teams to devise methods of getting the new hardware exposed to as many as possible before the season? With some bias towards geographic diversity (lest all the Mid-Atlantic teams that host off-seasons would have pretty epic odds), you could probably get a lot of teams up to speed pretty quickly, more with the benefit of YouTube/Vimeo/TBA.

[Kevin Sevcik]

I'll second that! I've never been in love with NI hardware or software products (though I'm grateful for their sponsorship).

I wonder how many teams will sit 2009 out because of the steep learning curves? For teams that have four-year students and tight budgets it might make sense, which is unfortunate. Unless the system comes pre-configured with a very, very, strong set of reference VI's and some unbelieveably great documentation, I can envision a large backlash against FIRST by frustrated and upset teams in March 2009. The IFI reference code was pretty good - NI needs to top that.

I'd have loved to have a year or two to make the transisition. I can't see any technical reason that the two field control systems couldn't have operated in parallel in 2009 (cost issues aside). Better yet, it would have been great to let the market decide which system the customers (e.g. the teams) prefer. One entry fee gets you an IFI system, and a higher entry fee gets you an NI system. That would have made a great introduction to the economic realities of the engineering profession for students!

I also wonder if Kevin Watson will stay involved.I'm afraid the financial and technical difficulties inherent in running the two systems in parallel are effectively insurmountable. Given that FIRST is still working out logistics, hardware designs, software support, and communications, I don't think you'd be able to add IFI compatibility on top of it and still have a product by kickoff 2009.....
That said, I wouldn't mind if we didn't have a product by kickoff 2009 and we had to fall back on the IFI system for one more year. To my mind, FIRST should have had a LOT of this stuff worked out already. The demonstrations at Champs should have been of prototype hardware for the initial production run, and we should have been looking at V1.0 of the software environment. Given that they announced a new control system in May 2007, and were certainly working on it before then, many of these issues should have been worked out. At the very least, they should have a solid price estimate for the system. One year into the project, apparently fully committed to the transition and they still don't know what it's going to cost? That's pretty astounding.
I'd be (moderately) happy if the control system was available around registration time this year AND FIRST shipped control systems to teams early along with the software etc. that they ship out months before the competition. We all saw the lovely results of beta testing ~15 fields with brand new scoring software and hardware AT the regionals in 2005. I really don't want to see the results of beta testing 1500 robot controllers AND field controllers during the 2009 build and competition season.

[JesseK]

I'd be (moderately) happy if the control system was available around registration time this year AND FIRST shipped control systems to teams early along with the software etc. that they ship out months before the competition. We all saw the lovely results of beta testing ~15 fields with brand new scoring software and hardware AT the regionals in 2005. I really don't want to see the results of beta testing 1500 robot controllers AND field controllers during the 2009 build and competition season.

My single hope out of all of this is that teams will get the control system as soon as they register. That's about all we can practically ask for.

The good news is, if they fix any beta bugs during a competition it will take mere minutes to implement and mere seconds to upload over the wireless to our bots :rolleyes: Hopefully FIRST is thinking about this framework and will keep a special upload port ready for such bug fixes.

[Alan Anderson]

...if they fix any beta bugs during a competition it will take mere minutes to implement and mere seconds to upload...

It's possible that such bugs would be in the FPGA portion of the system. Fixing them could take a whole lot longer than you expect. The equivalent of the code/compile/load/test cycle for VHDL is often measured in hours.

[Kevin Sevcik]

The good news is, if they fix any beta bugs during a competition it will take mere minutes to implement and mere seconds to upload over the wireless to our bots :rolleyes: Hopefully FIRST is thinking about this framework and will keep a special upload port ready for such bug fixes.
Minutes is probably a little optimistic. For a team with a laptop that just meets LabVIEW requirements, I'd guess 10-15 minutes, since a fix to some base level code is going to invalidate a fair number of things. And the field controller... That's going to be complicated enough that any fixes would probably be done over lunch.It's possible that such bugs would be in the FPGA portion of the system. Fixing them could take a whole lot longer than you expect. The equivalent of the code/compile/load/test cycle for VHDL is often measured in hours.I'll note that on a 1M gate NI FPGA, I managed to implement the forward kinematics for a 3-DoF rotational joint device, X-Y-Z PD loops, and the transverse Jacobian to take those XYZ forces back into joint space, with lookup tables for all the trig functions. It only took 30 minutes to compile on my 2.0 GHz dual-core laptop. And if I changed some of my built in constants for joint lengths, it wouldn't fit on the FPGA anymore. So while I don't think it'll take hours to recompile the safety, PWM, and (hopefully) encoder logic on the FPGAs, it's definitely not going to be mere minutes.

[dcbrown]

If I understand correctly, to eliminate software from having to deal with hardware latency issues, the majority of the software that was implemented as an ISR within the PIC is implemented within the FPGA.

So for example, a quad encoder ISR on the PIC that had phase A/B input and tracked a count would be implemented within the FPGA and could have the added value of dealing with all four phase transitions on multiple encoders. Each encoder would have its own dedicated FGPA hardware to process it. The resulting exported data would be a h/w register with the current count.

Or the GTS sensor which had major latency issues a couple years ago due to the small time differential between forward and reverse pulse widths (<50us)? Implement the servicing in hardware and the software latency issue is no longer a problem, a good count can be maintained.

By committing the time critical processing to hardware, this eliminates the need for interrupts to service the hardware events and makes time sliced multitasksing that polls & processes the data viable.

You can then create independent tasks that poll, combine, and process the data for each of the various devices you want to use. With fast task switching time and task priorities of the RT/OS, the different data flow processing within the different task trees appears to be simultaneous. So, you could have one set of independent tasks integrating sensor information in an inertial navigation system to determine position and a different set of tasks "simultaneously" working on motor control, and a third set of tasks operating on operator input for control of a manipulator.

???

Not sure I like it, but I can see how you'd shift your design viewpoint to program such a system. For example, take the polling of each device out of the main interrupt routine of the PIC and create a separate polling task tree for each, then schedule them to run every so often as needed to initiate processing of the data...

The biggest plus is also the biggest minus:

+ the hardware servicing is committed to the FPGA - once the bugs are worked out it will work for all teams the same way.

- the hardware servicing is committed to the FPGA - if you want to tweak the servicing of the hardware or integrate data differently or add some weird/unusual sensor that isn't already allowed for, you're pretty much stuck as the FGPA is off-limits to teams. The whole lower level hardware layer has been abstracted and put off limits as a result.

Not a big minus. (I could whine about this, but it is what it is - learn, adapt, overcome.) I'll miss it, but can still teach how it works at the lowest levels.

Ok, so I'm babbling... Traditionally, interrupts are used for servicing hardware events, for time-based integration of data, and initiating event processing due to some hardware or software event (IR sensor detects wall in front of robot, stop!?!) The first two are very time critical, the last is mostly a convience of the interrupt structure and is less time critical.

The FPGA seems to address the first, and the 2nd *IF* that integration is implemented in the FPGA too, and event processing can be simulated by running independent polling tasks on a fixed schedule. The result is not exactly the same, but is probably close enough to work ok. I'm beginning to wonder if the new processor is fast enough ;)

[Kevin Sevcik]

So for example, a quad encoder ISR on the PIC that had phase A/B input and tracked a count would be implemented within the FPGA and could have the added value of dealing with all four phase transitions on multiple encoders. Each encoder would have its own dedicated FGPA hardware to process it. The resulting exported data would be a h/w register with the current count.This is assuming, of course, that all this functionality is actually implemented on the FPGA for us. I'm not entirely certain that's a given. Of course, if it's not on the FPGA and we aren't allowed to implement it ourselves, I'm going to feel pretty darned silly still doing quadrature encoder counting using interrupts. Actually I'm going to feel pretty annoyed even if they implement the encoder logic on the FPGA for us, since it's pretty unlikely ever team is going to need the exact same number of encoders. Seeing as how a mechanum system with two feedback controlled joints would potentially need 3 times the interfaces as a two wheeled kit bot.

[Dave Flowerday]

By committing the time critical processing to hardware, this eliminates the need for interrupts to service the hardware events and makes time sliced multitasksing that polls & processes the data viable.
...except only the things that FIRST and/or NI has thought of are committed to hardware. Since the FPGA is not user-programmable, any novel ideas or sensors which would need interrupt support are not possible - I think this is what Alan was getting at above. In my opinion this is a HUGE step backwards from the current control system and a very disappointing revelation.

A perfect example occurred this year - the FIRST-supplied IR receiver sucked, so Kevin whipped up some code that allowed you to do it on the RC with a simple receiver plugged into an interrupt port. I don't see how that would be possible in a new system that does not support interrupts. Sure, IR happens to be slow enough that you might be able to poll for it (remember, your polling frequency is going to be limited by your OS tick rate and if multitasking it may not be constant), but it doesn't take much imagination to think up other instances where something like this is not possible. And, if you start polling for enough things, all that nice extra MHz provided by the new processor will be chewed up doing menial tasks which are handled in hardware for free basically by a $5 PIC.

A few years ago myself and a few other mentors from Wildstang along with a few from the Technokats investigated using an optical mouse for tracking position. We did this by bit-banging the non-standard synchronous serial protocol used by the chip inside the mouse on the RC hardware. This is another example of something that might be difficult or impossible under the new system without interrupts.

[Kevin Sevcik]

Dave,

The RTOS-FPGA combo running on the cRIO does support interrupts, but you have to program them into the FPGA for them to work. They also appear to be a shared resource, so there's no precise guarantee when a particular one will be serviced. Basically, the FPGA would probably need to fire an interrupt whenever there was an edge transition on a digital input, and we'd have to use code like Kevin's Encoder 3-6 code supporting the PIC's interrupt on change port. But I'm really hoping we're not forced to go this direction. Given the availability of an SPI port and an extra 10/100 port, I think I'd be tempted to grab a semi-cheap FPGA demo board and have our students implement an encoder counter on it.

[Al Skierkiewicz]

I failed to point out in my early post a positive answer to one of my questions...Yes, there will most definetly be a default program that ships with the control system just like the IFI default software.

Also,
It might make more sense to split hardware and software discussions into two threads at some point in time.

[Doug Leppard]

I can't believe FIRST would release this without interrupt (encoder) support.

My recommendation for FIRST is give us the processor upon a paid registration to allow people to train on it and help find bugs that may be in it.

[Greg McKaskle]

So NI_RIO_PEEK and NI_RIO_POKE (assumption) would work within kernel applications/tasks, but what about RTPs? Since opens are not traditionally shared across the RTP/kernel interface could RTPs do their own open on the FPGA image or will this type of macro call only work inside the kernel?

Is there a technical architecture overview document for the FPGA and NI I/O modules - essentially similar to VxWorks component API manuals? Trying to find any real tech information on this platform has been particularly frustrating. Especially since this is NOT a new platform. I don't need to know the particulars of how the FPGA/IO interface will be set up for FRC, but it would help immensely to know what a typical engineer recieves in terms of documentation, software templates, and information when they buy an cRIO IO module.

Realtime OSes don't necessarily have the same division of kernel and user modes. Specifically, the RIO peek and poke are allowed to be called from user code. As for documents that would be received if an actual engineering customer. To this point, the C/C++ for the cRIO has been for internal consumption. To this point, all cRIO customers have used LabVIEW.

The best source of technical overview info that I know of is http://zone.ni.com/dzhp/app/main.
Search for cRIO. The first five articles or so seem like they may be useful.

Greg McKaskle

[Greg McKaskle]

... Did it increase the allocated memory by 1 element? 10? Some constant somewhere? Did it double the size? I can get at this info for a rather lot of other programming languages, but I haven't a clue what labview is doing for me behind the scenes.

... Of course this is, again, just so much voodoo. I have also coded up a rather gate-hungry FPGA program.....

The forums for LV often cover these sorts of implementation details, but they of course change over time. Both the system memory manager and the internal array allocator round up to some degree before allocation. The insert into array doesn't do anything beyond this, but the loop boundaries use a bounded doubling scheme. And all memory management does indeed slow loops down, just as in any language. It is also quite easy to preallocate the array and replace elements if you want to remove the memory management and increase the speed.

In other words, LV will not prevent you from writing code that operates inefficiently. The compiler will do what it can to improve things, and as in any language recognizing and measuring what code is doing takes consistency and practice. One benefit to rapid development languages like LV is that while the array insertion code your fellow student wrote wasn't optimal, it sounds like it did work. If a non-CS user is able to get valid results from their computer, that is a huge improvement over what they could often achieve with a language that gives them super low level control. Hopefully when the time comes for optimizing, they are then able to keep the correct results as they experimentally modify their implementation.

If you have further questions about how LV implements its voodoo, both the NI LV forum, and now this forum are a great place for it to take place.

Greg McKaskle

[qnetjoe]

I keep seeing a lot people of keeping talking about how the FPGA is off limits. I really don't think that FIRST would go that far, because without access to the FPGA what is the real benefit of the new controller?

I would take a guess to say that there will be a custom VI that allows us to tailor the use of the FPGA while allowing FIRST to maintain their required supervisory control. I have done things very similar to this with my cRIO's and PXI chassis with RT controllers.

For years with FIRST safety has only been skin deep. Change a few registars from any of the 2004-2007 controllers and your robot can be really dangerous.

Besides you have 20 engineers at FIRST/NI vs a FRC community of 20k with a passion for this stuff. We WILL find a way to program that FGPA.

[Pavan Dave]

I keep seeing a lot people of keeping talking about how the FPGA is off limits. I really don't think that FIRST would go that far, because without access to the FPGA what is the real benefit of the new controller?

I would take a guess to say that there will be a custom VI that allows us to tailor the use of the FPGA while allowing FIRST to maintain their required supervisory control. I have done things very similar to this with my cRIO's and PXI chassis with RT controllers.

For years with FIRST safety has only been skin deep. Change a few registars from any of the 2004-2007 controllers and your robot can be really dangerous.

Besides you have 20 engineers at FIRST/NI vs a FRC community of 20k with a passion for this stuff. We WILL find a way to program that FGPA.


They said for the first year it would be off limits. After that its fair game, unless I heard wrong.

[MWagon]

.... I managed to implement the forward kinematics for a 3-DoF rotational joint device, X-Y-Z PD loops, and the transverse Jacobian to take those XYZ forces back into joint space, with lookup tables for all the trig functions. :ahh:


Didn't I warn you not to talk like this in public Kevin? :D

[Kevin Sevcik]

I keep seeing a lot people of keeping talking about how the FPGA is off limits. I really don't think that FIRST would go that far, because without access to the FPGA what is the real benefit of the new controller?

I would take a guess to say that there will be a custom VI that allows us to tailor the use of the FPGA while allowing FIRST to maintain their required supervisory control. I have done things very similar to this with my cRIO's and PXI chassis with RT controllers.

For years with FIRST safety has only been skin deep. Change a few registars from any of the 2004-2007 controllers and your robot can be really dangerous.

Besides you have 20 engineers at FIRST/NI vs a FRC community of 20k with a passion for this stuff. We WILL find a way to program that FGPA.
Actually, I think it's well nigh impossible for you to programmatically override the supervisory control of the master processor in the IFI controller. All the outputs controlling real world devices sent through buffers controlled by the master processor, so it has the final say if a motor's turning or not. And it takes very little data back from the User Processor in a very controlled manner, so I don't think you could even reliably override it with packet overruns or something.

[dcbrown]

...except only the things that FIRST and/or NI has thought of are committed to hardware. Since the FPGA is not user-programmable, any novel ideas or sensors which would need interrupt support are not possible - I think this is what Alan was getting at above. In my opinion this is a HUGE step backwards from the current control system and a very disappointing revelation.


Dave you quoted my post, but I also wrote the following in the same post:

if you want to tweak the servicing of the hardware or integrate data differently or add some weird/unusual sensor that isn't already allowed for, you're pretty much stuck as the FGPA is off-limits to teams.

I guess I wasn't clear. Anyway, I think we're in violent agreement. By logical extension, as Kevin mentioned, this also means that the FGPA may have limits in the number of same type supported devices. For example, the FPGA may only be programmed with support for 4 quad encoders plus 2 GTS plus 2 sonar. (I suspect sonar is a bad example and could see a design decision not to support the sonar sensors in FPGA but rather on I2C ala NXT w/the built-in PIC controller within the sensor box doing all the work and then using the possible I2C bus off the digital sidecar to retrieve data as needed - again polling). So if you wanted to use n+1 sensors of a specific type on your robot, where 'n' is the number implemented in the FPGA, then your kinda out of luck. Although the sensor processing with the FPGA has not yet been completed, I would find it difficult that at least design intent isn't known at this point and its too bad that type of information isn't shared.

One brain blip I had in regards to above was that there wouldn't necessarily be just ONE FPGA programmed image to choose from - after all this is field programmable. In that case, much like configuring a work truck you'd choose from one of a number of standard FPGA setups provided. There are only so many digital input lines to choose from after all, so how you dedicate them to what sensor suite may be selectable. That is, one image supports 6 encoders plus other stuff and another supports only 2 encoders plus other things. With multiple FPGA images provided the likelyhood of finding one close enough to match the robot you want to design becomes greater.

Realtime OSes don't necessarily have the same division of kernel and user modes. Specifically, the RIO peek and poke are allowed to be called from user code.

The early open of the FPGA must not be as a device then or I severely misunderstood the VxWorks documentation that indicated open device descriptors were not shared across the RTP/kernel interface. Of course there is always the possibility that PEEK/POKE are implemented as custom system calls for the cRIO from the RTP into the kernel or the open of the FPGA isn't as a normal device. It probably doesn't ultimately matter to programmers, but as an engineer I kinda like to know how my request is being routed as it effects how I design the processing flow of the code as the route "distance" in software can effect performance.

To this point, the C/C++ for the cRIO has been for internal consumption. To this point, all cRIO customers have used LabVIEW.

Don't take this the wrong way -- just after 30 years of systems engineering at the s/w-f/w-h/w boundary this statement quietly screams "WATCH OUT!" One way of interpreting this comment is that FIRST will be the beta test customer for using C/C++ to program the cRIO. From a product roll-out risk perspective, things just got a whole lot more interesting.

[qnetjoe]

overwrite your tether and automous registers and IFI controller will function without any supervisory control. You can use the live debug feature inside of MPLAB to find these

[Danny Diaz]

The early open of the FPGA must not be as a device then or I severely misunderstood the VxWorks documentation that indicated open device descriptors were not shared across the RTP/kernel interface.

No, you read the VxWorks documentation correctly. However, what the VxWorks documentation fails to mention (not that it could if it wanted to) is that NI has not implemented the use of RTP's in the variant of VxWorks that we're using for our cRIO product line. So, all calls you make are kernel calls since there is no concept of "user mode" in what you're using.

Of course, this is something that is subject to change in future versions of the VxWorks port for cRIO, but it's most likely not going to happen in even the next major release.

-Danny

[Dave Flowerday]

overwrite your tether and automous registers and IFI controller will function without any supervisory control. You can use the live debug feature inside of MPLAB to find these
This is getting off-topic, but...

Have you actually tried this? I'm guessing not, because that won't work. Please, if you disagree, I dare you to prove me wrong. Post a video or something.

IFI designed a superb system from a safety standpoint - it's basically impossible to override the safety features through anything you can do on the User processor. After many years of studying the details of the IFI design, it is very, very obvious that safety was a top priority in their system. Field reset crews, referees, and match announcers can step on the field with confidence knowing that if the control system has the robots disabled, they will really be disabled. I certainly hope as much care is being put into the safety features of the new system as IFI put into theirs - it's not a good thing when a 130lb machine moves when you think it's turned off.

[Alan Anderson]

Off-topic for the thread, but still worth mentioning...
IFI designed a superb system from a safety standpoint - it's basically impossible to override the safety features through anything you can do on the User processor.

Yes, they did good keeping programming errors (or evil-intentioned hacks) from causing unsafe operation. On the other hand, it is still possible to have a robot do dangerous things if you violate the wiring rules. One team was surprised recently to find that their pneumatics worked when the robot was disabled, because they had wired the Spike control signals to RC digital outputs instead of the required relay outputs. A Victor could run a motor without regard to the disable input if it were wired to something other than a PWM output (I've used servos in disabled mode, and I think you have too).

While I'm sure the new system is going to be just as safe as the old one, it's going to be just as possible to bypass the safety features with illegal wiring. Fortunately, that sort of thing is not hard to catch with a visual inspection.