NEW 2009 Control System Released

[EricVanWyk]

Originally Posted by writchie

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]

Originally Posted by FRC4ME

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]

Originally Posted by MikeDubreuil

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!

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]

Originally Posted by 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!

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

Originally Posted by writchie

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]

Originally Posted by Gdeaver

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

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]

Originally Posted by 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.

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]

Originally Posted by adman

...

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]

Originally Posted by ABlackburn

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]

Originally Posted by adman

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.

Originally Posted by adman

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

Originally Posted by adman

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.

Originally Posted by adman

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.

Originally Posted by adman

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.

Originally Posted by adman

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

Originally Posted by adman

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.

[sarcasm]
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
[/sarcasm]

Originally Posted by adman

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)

Originally Posted by adman

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)

Originally Posted by adman

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

Sounds like a challange to me.

Originally Posted by adman

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

Originally Posted by adman

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]

Originally Posted by Eldarion

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.