NEW 2009 Control System Released

[Dave Flowerday]

On the other hand, it is still possible to have a robot do dangerous things if you violate the wiring rules.
True enough. If we have a battery, some wire, a motor, and have no regard for the rules (or sloppy application of those rules), we can make any robot move, no matter what the control system is ;)

Luckily, it is (in my opinion) still much easier to catch wiring errors than coding errors... and that will be more true of the new system (basic rule of software engineering: as system complexity increases, so do the odds of having bugs).

[Jay Lundy]

I too would love full access to the FPGA, but that may be impossible. Here are some ideas that may give us more freedom even with a locked down FPGA.

Since the FPGA is not user-programmable, any novel ideas or sensors which would need interrupt support are not possibleIt's definitely possible to send interrupts from the FPGA to the RTOS (http://zone.ni.com/devzone/cda/tut/p/id/3249#toc4), at least in Labview. Presumably the FPGA could be hard-programmed to send every digital input to a different IRQ and if the signal processing on the FPGA doesn't work for you, you can do it in the RTOS. The help file on interrupts makes me worried about the interrupt latency using this method: "The Interrupt VI is a shared resource, so multiple uses of it induce additional delay and jitter due to arbitration," but it may be a possible solution. If you want to handle the interrupt in C and write something like Kevin's utilities, my guess is you could register your ISR with some sort of Labview run time library that processes and dispatches the interrupts (I don't think these are real interrupts so you can't just register ISRs with VxWorks (http://www.rt.db.erau.edu/oldrtlab/experiments/vx/interrupts/Experiment-9.html)). The WPI libraries could make this simple for us.

By logical extension, as Kevin mentioned, this also means that the FGPA may have limits in the number of same type supported devices.Just because we can't change the physical logic on the FPGA, doesn't mean we can't change the way it behaves. We can still modify the registers that control the logic (right?).

For example, assume you have a black box that performs the signal processing on one encoder input. Now, stick a mux in front of it and feed every digital input into the mux. Then, use the RTOS to fill an array of registers with the inputs you want processed and one final register with the number of entries in the array. Then just start a counter to iterate through the array and feed that into the select pin on the mux to process each input one-by-one. Oh and you'll probably want a demux on the other side so the encoder count sum goes to the right place.

I'm sure there's a more efficient way of doing it than the way I've described, but I was trying to keep it conceptually simple.

: Come to think of it... this won't work too well, but I think the idea may be feasible. Can anyone fix it?
: Each pin that can be configured as an encoder will need to have its own state (count sum). The only thing they might be able to share is the combinational logic, but it takes basically no CL to count an encoder, so there's really no point.

[Kevin Sevcik]

It's definitely possible to send interrupts from the FPGA to the RTOS (http://zone.ni.com/devzone/cda/tut/p/id/3249#toc4), at least in Labview. Presumably the FPGA could be hard-programmed to send every digital input to a different IRQ and if the signal processing on the FPGA doesn't work for you, you can do it in the RTOS. The help file on interrupts makes me worried about the interrupt latency using this method: "The Interrupt VI is a shared resource, so multiple uses of it induce additional delay and jitter due to arbitration," but it may be a possible solution.This is more or less what I was thinking, except I have some refinements. First, it's not at all clear in the FPGA documentation (there I go again) if the arbitration issues arise for every call of the Interrupt VI, or only for calls of the Interrupt VI addressing the same IRQ number. Ex: Flagging IRQ16 someplace and IRQ28 somewhere else might not have arbitration issues complicating the latency. Of course, issues of interrupt priority and concurrent interrupts might still affect things. Which also isn't well documented. If you can have multiple interrupts with different flags with no issues, they your idea would work. Else, I think it'd be smartest to just implement an interrupt-on-change feature across the entire range of digital inputs so a single interrupt tripped when any digital input changed state. You could run the inputs or the edge detection outputs through a simple and relatively cheap bitmask to enable and disable interrupts on a particular IO pin, even. It'd still be a little complicated, as you'd probably need to latch the edge detector and digital IO states when you flagged an interrupt, but I think this would be a workable solution for giving us access to interrupts. I still don't want to have to interface with quadrature encoders using interrupts but I imagine our only other option for general purpose high speed IO of digital inputs would be to set up a DAQmx task to constantly sample the inputs at some acceptably high rate, and then process this backlog of data either in our main loop or a parallel loop running at a rate between the sampling rate and the loop rate. The accuracy and dependability of this would of course depend on our digital IO sampling rate, but a higher sampling rate would give us that much more data to process, when the majority of it is largely useless.Just because we can't change the physical logic on the FPGA, doesn't mean we can't change the way it behaves. We can still modify the registers that control the logic (right?).

For example, assume you have a black box that performs the signal processing on one encoder input. Now, stick a mux in front of it and feed every digital input into the mux. Then, use the RTOS to fill an array of registers with the inputs you want processed and one final register with the number of entries in the array. Then just start a counter to iterate through the array and feed that into the select pin on the mux to process each input one-by-one. Oh and you'll probably want a demux on the other side so the encoder count sum goes to the right place.

: Come to think of it... this won't work too well, but I think the idea may be feasible. Can anyone fix it?

Anyway, you can do this with every type of sensor. Just have one black box that you share between the inputs. Obviously it takes longer this way, but at 40 MHz the FPGA should have plenty of time to spare. If time is a problem then add more black boxes in parallel.

Does anyone see any problems with this?I was also pondering something like this, but the problem with your second idea is that function blocks on the FPGA represent actual physical silicon. Counting through all the different inputs/etc. in a single cycle loop on the FPGA isn't going to be possible. You could get away with it in a less strictly timed loop, but then you have to worry about jitter and problems if your loop runs over schedule, and FPGA code outside a single cycle loop takes up a good bit more space on the FPGA. If you just said the 2N first inputs on the IO represent N encoders, then I think you could loop through the set of inputs, old states, and count registers for N encoders, processing one encoder per FPGA cycle. This obviously slows down your overall capture rate, but if they get the FPGA running at 20-40MHz as it should, then it shouldn't matter. Then you let the programmer define N to pick how many encoders she wants.

The other solution is to hard code in X encoder counters, and Y GTS counters and Q other devices, spread across the digital input lines as widely as possible, but each dedicated to a particular port, much like the different peripherals on the PIC. Then have various enable/disable lines to select which ones you want to use as GPIO and which to use as peripherals. Maybe you could even have various bits to twiddle on and off to select slightly different functions for the various modules or otherwise modify their operation. You could even have a few registers here and there to further tweak the function of the various peripheral modules. I bet if the NI/WPI guys work hard enough they could come up with the equivalent of, ooohh, three PIC18F2431 chips (only $3.07 per!).

Which is to say that if we wanted a large amount of flexible hardware based IO that we could simply turn on and off with the flick of a switch, a controller based on a local net of microprocessors might have been a better move. The whole point of an FPGA is that you only have to implement what you need and it can be whatever the heck it is you want. So I hope the various people involved in the control system understand our frustration with paying more for a new controller that we don't have yet and will quite likely lock us out of the single most useful feature it has.

[Greg McKaskle]

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

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

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.

There have been many postings looking into the crystal ball of the FPGA, and I'll try to give a bit more technical info on what is possible. But policy decisions as to what is allowed are of course FIRST's call, and independent of what is technically possible.

The FPGA on the cRIO is an open LV target. This means that LV code can be designated to run on the host PC, the PPC, or the FPGA. Of course LV targets the FPGA via VHDL, and therefore the cRIO is ultimately targetable with C-based .out PPC files and bitfile produced from VHDL. To promote a migration path, promote working, stable robots, and ensure safety, the decision was to keep the FPGA closed for at least the first year. After that, depending on how things go, it could be opened to the extent that there are vanilla, chocolate, and rocky road flavors. It could be opened further by providing 09 source and allowing teams to go nuts. Technically, these are all possibilities, and it is a policy decision as to what makes the most sense for the organization and competition. At this point, I'm sure FIRST is listening, but any opinions you may have honestly aren't well founded. After a season, the feedback will carry much more weight.

As for the SW stack required to peek and poke. I'm not entirely sure, as this isn't something I've used much directly. The success of the product is hinging on the performance of said calls, so I'd say that it is probably pretty performant and more importantly, deterministic. Moving forward, I will be happy to get the gory details for those who are curious about how it works. But for now, I think you can trust that the FPGA is not using dev/IO, and is instead a low-level custom driver.

Greg McKaskle

[Kevin Sevcik]

Technically, these are all possibilities, and it is a policy decision as to what makes the most sense for the organization and competition. At this point, I'm sure FIRST is listening, but any opinions you may have honestly aren't well founded. After a season, the feedback will carry much more weight.Greg,

Respectfully, I honestly don't think your opinions are well founded either. There are at least a few people in this thread that have experience with the cRIO platform. I personally have experience a PXI-RT/FPGA platform. The project I was discussing earlier was a graduate level project. I managed to use 32-bit Q-Math to cram the entire forward kinematics of a 3-DoF PHaNTOM haptic device on to a 1M gate FPGA, including the interface logic for my quad encoders, logic for virtual walls and the transverse Jacobian to translate my Cartesian forces back into joint space. If you're not familiar with robotics, that's, basically, one-half to one college ruled page of trig dependent non-linear equations. I've also been working with the C-based IFI controller since its inception. So I hope you believe that I might have some clue about this.

So, I think it was a valid opinion that it would be highly annoying to be forced to interface with custom sensors or encoders using fixed rate sampling or interrupts on the cRIO processor. My annoyance is based strictly on my personal dislike of compensating for hardware deficiencies in software AND NI's own literature lauding the flexibility and utility of this wonderful hardware that we're not going to actually be able to use, so I feel it's valid under the circumstances. I'll note that at the last control system change-over, we were given free reign over all the hardware on the PIC. The annoyance there was simply that so much of it was blocked off by buffers and other things necessary for safety.

I will agree that any opinion on how things will turn out in the 2009 season is entirely premature. However I think this is primarily because of the distinct lack of information available to us right now. The fact that the nature and utility of the FPGA code is still undetermined frankly makes me nervous. The fact that the development environments are still under development highly worries me. I do appreciate your willingness to discuss the nitty gritty of the RTOS and such with us, but since we don't know what sort of high speed or interrupt based processing we'll be needing on the RTOS nor what the structure of the code will be, I don't think I can ask any intelligent questions.

I think a lot of this angst and annoyance could have been taken care of if this system was closer to a prototype of the system going out to teams and farther from a demo piece put together by NI to sell us on the system. I know I would have been fine with more man hours spent on these TBD features and less man-hours spent on a pretty holonomic robot with a sponge canon and flashy interface that still on bears a resemblance to the environment and hardware we'll be working with.

[artdutra04]

I think a lot of this angst and annoyance could have been taken care of if this system was closer to a prototype of the system going out to teams and farther from a demo piece put together by NI to sell us on the system. I know I would have been fine with more man hours spent on these TBD features and less man-hours spent on a pretty holonomic robot with a sponge canon and flashy interface that still on bears a resemblance to the environment and hardware we'll be working with.As one of the people who helped design and build the "pretty holonomic robot", all I can say is that the new control system is still very much a work in progress. Those of us who built the "pretty holonomic robot" were mechanical and robotics engineering college students, who were tasked to design and build a robot to showcase some of the new features of the new control system.

Could was have hacked some prototype demo robot together a lot quicker? Yes. But the group of us who designed, machined, and built that robot take pride in our work, and were in no way taking time away from those who are actually developing the new control system.

I'm sorry you think that the extra ten percent of effort we went through to make our demonstration robot look nice was in some way hampering the control system development cycle.

[BrianBSL]

]
I think a lot of this angst and annoyance could have been taken care of if this system was closer to a prototype of the system going out to teams and farther from a demo piece put together by NI to sell us on the system. I know I would have been fine with more man hours spent on these TBD features and less man-hours spent on a pretty holonomic robot with a sponge canon and flashy interface that still on bears a resemblance to the environment and hardware we'll be working with.

FWIW, to reiterate what Art said, the holonomic robot was worked on almost entirely by people with very limited software background. The only software effort/resources put into it was the holonmic class for WPILib - which also meant that work was going into the other classes that it uses - Drive, Motor, Gyro, Joystick, etc, which are all valid effort for the final product.

I'm pretty sure some of these 'TBD' features are in a far more developed state than you are giving them credit for - but if you saw them now and then a feature was removed from the final product, everyone would be complaining.

Also - 4 years ago when we switched to the PIC system, weren't we not given any information about it until September or October when the EDU controller was announced? Who knows what state it was in in April.

I by no means think that the community should just sit quite and wait until they have all the information - I'm sure some very valid points will be brought up between now and whenever 'then' is - but just keep in mind that 'TBD' doesn't mean no one has thought about it and it isn't 90% done, it just means they don't want to announce it to the public yet.

[Mike Mahar]

It seems to me that this is a three step process:
1. Guess how the new system is going to work based on limited information.
2. Find a flaw in the system based on the guess.
3. Complain about the flaw.

Of course, I'm worried too that the interface logic in the FPGA isn't going to work the way that I'd like it to and I won't be able to do some of the things that I'd like to do. However, if the system FIRST provides is truely inadequate than no one will be able to build a robot for next year's challenge. I seriously doubt that that will happen.

There may be updates to the FPGA as bugs are found. Updating the FPGA probably won't be as slow as some fear since the update will probably come in the form of a pre-compiled net list.

I'd love to have the system as early as possible so that I can get my team started. My team wants to stay with C/C++ but I suspect that we'll have to know LabView as well. We'll have plenty of things to learn to get this new system working and I'd like to get started as soon as possible but I'm not going to worry about things until I know what they really are.

[Kevin Sevcik]

I'm pretty sure some of these 'TBD' features are in a far more developed state than you are giving them credit for - but if you saw them now and then a feature was removed from the final product, everyone would be complaining.

Also - 4 years ago when we switched to the PIC system, weren't we not given any information about it until September or October when the EDU controller was announced? Who knows what state it was in in April.

I by no means think that the community should just sit quite and wait until they have all the information - I'm sure some very valid points will be brought up between now and whenever 'then' is - but just keep in mind that 'TBD' doesn't mean no one has thought about it and it isn't 90% done, it just means they don't want to announce it to the public yet.But we did have a valid and useful practice system by registration time with the PIC system. Given all the announced dates of "Well we'll definitely be done by kickoff" and less official statements of it could be ready by fall, and all the apparently undetermined logistical issues.... I'm somewhat doubtful that these TBD issues are 90% done. If they are and it's just going to take the next 8 months to work out these things... Well I think someone's trying a little too hard to stick to the 80-20 rule.

[Greg McKaskle]

Respectfully, I honestly don't think your opinions are well founded either. There are at least a few people in this thread that have experience with the cRIO platform. I personally have experience... So I hope you believe that I might have some clue about this.

...it would be highly annoying to be forced to interface with custom sensors or encoders using fixed rate sampling...

I will agree that any opinion on how things will turn out in the 2009 season is entirely premature. ... The fact that the nature and utility of the FPGA code is still undetermined frankly makes me nervous. The fact that the development environments are still under development highly worries me. I do appreciate your willingness to discuss the nitty gritty of the RTOS and such with us, but since we don't know what sort of high speed or interrupt based processing we'll be needing on the RTOS nor what the structure of the code will be, I don't think I can ask any intelligent questions.

I think a lot of this angst and annoyance could have been taken care of if this system was closer to a prototype of the system going out to teams and farther from a demo piece put together by NI to sell us on the system. I know I would have been fine with more man hours spent on these TBD features and less man-hours spent on a pretty holonomic robot with a sponge canon and flashy interface that still on bears a resemblance to the environment and hardware we'll be working with.

Kudos for your FPGA-robotics experience at the graduate level. I'm not intending to question your technical abilities. The people defining the content of the FPGA are also familiar with robotics, but they are also focussing on what FIRST wants in their robotics competition, which may not be at the graduate research level. The different goals from the thousands of mentors and students will certainly keep this interesting, that is for sure.

If it helps at all, the FPGA image used by the four of the five robots shown in Atlanta was the alpha revision of the image slated to be given to teams. It has changed little in the last few months. It can't really be complete until all HW control and sensor choices for the KOP are determined, and as the SW wrappers for exposing the functionality to teams are being completed, they may also influence the FPGA slightly. By the way, I think four of the robots were also using the current WPI libraries. They are not quite complete, but I feel they are progressing nicely. Alpha typically means in use by internal customers, so if not alpha, they are close to that level of completeness.

The development tools, by the way, are off the shelf. They are being modified by adding libraries, and providing optional simplified UI settings in Eclipse and LV to waste less of the six weeks with rarely used advanced features. The tools have been used extensively getting ready for Atlanta.

The fifth robot, NItro, was indeed a bit of a show-off, but fundamentally was experimenting with alternate motor controllers, advanced motion options utilizing the FPGA, more applied vision processing, etc. It is unlikely to be an 09 FPGA, but is the eyes-to-the-future experimentation that will have the effect on the FPGA that you are looking for. So, while it may have seemed more flashy than needed, it served a purpose for the technical development as well.

I'll be the first to admit that my opinions aren't that well founded. That is why I'm following this list and talking to mentors in Atlanta -- looking for insight. I'm getting quite a bit, some from yourself and other vocal mentors, some from less experienced students. I'm also seeing lots of hand-wringing, and guessing as to the solution.

Personally, I'd find it much more useful if some of this energy were directed into a technical wish-list. Then both FIRST and the staff working on the project could measure the current 09 project against various expectations.

I'm sure you understand that details about the project can't and shouldn't be shared until FIRST is ready to divulge them. So, unanswered questions don't necessarily mean bad things. My personal expectations for the 09 season is that you will indeed feel limited by the elements in the kit. It is, after all, intended to meet the needs of many individuals who do not have the technical knowledge that you do. I also believe that it will hold many nice surprises for you, both in 09 and especially in future years as this very flexible system is allowed to be fully utilized. Personally, I'm looking forward to seeing what both the novice teams and the advanced teams are able to accomplish with it.

Once again, myself and other people working on the project will attempt to answer good questions when it is appropriate.

Greg McKaskle

[Billfred]

Personally, I'd find it much more useful if some of this energy were directed into a technical wish-list. Then both FIRST and the staff working on the project could measure the current 09 project against various expectations.I'm a marketing student (for 13 more days, anyway), but I tend to serve as the technical mentor on my team. We're not going to dethrone WildStang as autonomous mode legends anytime soon, so our needs are more basic. Among the things I'd like to see in 2009:

1) A PDF on the FIRST website that says, in essence, "If you did X under the IFI control system, now do Y with the cRIO". Tethering, downloading code, connecting the radios, connecting joysticks, enabling the robot--the easy stuff.

2) If I don't bring a laptop within five miles of the cRIO, I'd like it to be able to be wired up, turned on, and able to drive a robot around. Maybe it won't be as swanky as El Nitro expressing its displeasure for Soulja Boy in Atlanta, but it will, at the bare minimum, work.

3) A method, however ghettofab, of starting and stopping multiple robots at the same time without a proper field controller. I have yet to attend an off-season event in the state of Florida where the field has worked perfectly, whether for software quirks, hardware maladies, or half the field flooded with four inches of water; the ability to chuck the field controls and just get on with the show is crucial. (For reference, the software quirk was Mission Mayhem 2007, where the field wouldn't make sound effects; our DJ simply invented his own and played them at the appropriate times. Hardware maladies was Robot Rodeo 2004, where we couldn't even start a match; we dumped autonomous and had drivers stick their hands up at the end of the match. Half the field flooded (http://www.chiefdelphi.com/media/photos/25102)...well (http://www.chiefdelphi.com/media/photos/25138)...)

4) Some tutorials on implementing popular sensors on the cRIO would be beneficial, since it seems like a lot of the great white papers here and elsewhere based around the IFI system will be of limited usefulness. (Encoders, gyros, accelerometers, CMUcam if it returns...)

5) If it's to the point it can be shown off, try getting in touch with some of the off-season events that have workshops to give the system at least a little more exposure ahead of January. Even sending one knowledgeable person with a small robot (a la 1519 (http://www.chiefdelphi.com/media/photos/30299) or 102 (http://www.chiefdelphi.com/media/photos/30830)) in their carry-on would go a long way. (I bet a dollar someone will float you a battery for the purpose.)

6) For the sake of those rolling with mecanums, the ability to run four encoders is important. (Perhaps a few more if FIRST ever has another game like Aim High where teams would like to know wheel speed in places other than the drive system.)

7) When selecting an AP for the KOP (and please, do settle on one lest we have to hunt down fifteen manuals for different teams at events without the aid of internet access), think small. Maybe it won't be as small as the IFI radios, but the D-Link router we saw at the Sneak Peek is just a wee bit too much on the bulky side. (While you're at it, please let us know if there are any gamekilling mounting configurations for the AP of choice; such information was crucial to getting the 2007 IFI radio to work better.)

8) Perhaps a stretch, but what about a no-autonomous switch on the robot? I can think of at least one case this season where such a switch on the robot would've spared a team a yellow card. (The team ran their autonomous, which hit the far wall a little hard and forced a match restart. Since they couldn't reprogram their autonomous in the time given, they went right ahead and clocked the wall again. Yellowcardsville.)

9) One LED on the driver station indicating Big Serious Errors (loss of radio link, no/low main battery, software error, internal errors) is necessary. With the display on the new driver station, I don't think you need the individual LEDs of the IFI OI, but some light to make you look at the display for the serious error would be useful. (Of course, if you'd like to give us separate LEDs for those big errors, feel free.)

10) Sounds basic, but please make sure we have four nice places to screw down each thing to mount. I've seen some suspect mounting in the past, and I'd rather avoid any such issues now even if you can run the cRIO over with a Hummer.

Just my two cents; your mileage may vary.

[Doug Leppard]

Help me out on this, it might have been posted but I missed it.

What do you use for the OI?

If no more tethering, therefore in the pits we will program untethered and test untethered?

Also if it is true robots are untethered, at Atlanta in 2009, does that mean potentially 350 robots are transmitting and receiving some in games and some in practice fields and some in the pits?

[tdlrali]

What do you use for the OI?

It's now called "Driver's station" (probably due to trademark issues), and has similar features as the IFI OI - disable/enable/autonomous, 8 digital and 8 analog inputs, 8 digital outputs, 4 USB ports, a small LCD screen, and two ethernet ports (one to robot, one to optional laptop for dashboard)

If no more tethering, therefore in the pits we will program untethered and test untethered?

No, tethering will just use a normal ethernet cable. You will most likely have to turn off the robot-side access point in the pits.

[MattD]

8 digital and 8 analog inputs, 8 digital outputs, 4 USB ports, a small LCD screen, and two ethernet ports

There are only 4 analog inputs.

[Doug Leppard]

It's now called "Driver's station" (probably due to trademark issues), and has similar features as the IFI OI - disable/enable/autonomous, 8 digital and 8 analog inputs, 8 digital outputs, 4 USB ports, a small LCD screen, and two ethernet ports (one to robot, one to optional laptop for dashboard)



No, tethering will just use a normal ethernet cable. You will most likely have to turn off the robot-side access point in the pits.

Thanks, I missed those specs, where are they found?

[Mark McLeod]

Thanks, I missed those specs, where are they found?

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

[qnetjoe]

Personally, I'd find it much more useful if some of this energy were directed into a technical wish-list. Then both FIRST and the staff working on the project could measure the current 09 project against various expectations.

I'm sure you understand that details about the project can't and shouldn't be shared until FIRST is ready to divulge them. So, unanswered questions don't necessarily mean bad things. My personal expectations for the 09 season is that you will indeed feel limited by the elements in the kit. It is, after all, intended to meet the needs of many individuals who do not have the technical knowledge that you do. I also believe that it will hold many nice surprises for you, both in 09 and especially in future years as this very flexible system is allowed to be fully utilized. Personally, I'm looking forward to seeing what both the novice teams and the advanced teams are able to accomplish with it.

Once again, myself and other people working on the project will attempt to answer good questions when it is appropriate.

Greg McKaskle

Greg,

Thank you for you help and insights with this new control system. Here is my wish list:

1.) could someone please give us the name of the Project Head at both FIRST and NI. I am a member of the Colorado FIRST planning committee, president of Colorado School of Mines Robotics Club and a long time FRC mentor. We have a great relationship with our Regional NI sales office and have all the resources to do a mentor workshop on the new control system, but we need to know more about certain things (like access to the Digital Sidecar) so we are able to do such a workshop. Myself and many other are more than willing to sign a NDA. It is frustrating to say the least of the politics inside of NI and FIRST are cutting good people off at the knees. BTW I called FIRST on Monday (4/21) and they told me NI had nothing to do with the new control system, even after the announcement. go figure

2.) Encoder interfaces galore - I would love to see 8-10 encoder interfaces. It would be really nice if some of the encoder interfaces had upper and lower limit switch support. In our lab we setup 9403 channels as follows:

8 x RC-PWM outputs
8 x quadture encoder inputs (channels 0-7)
4 x upper and lower limit switches (mapped to channels 4-7)

Currently in our 2008 bot we used 6 encoders (4 channels had upper/lower limit switches), but that could of easily been 8 if we chose to use a Mecanum drive.

3.) More powerful sensors like gyros, accelerometer, ultra-sonics, laser range finders moved onto a communications bus (I2C, SPI or CAN). This will reduce pin count and if implemented correctly will allow for self diagnostics.

Now Moving on to the long term wish list:

4.) Make a Radio modem cRIO module. - if implemented correctly inside of VxWorks it could be used to provide the supervisory control that FIRST needs while still granting us access full access to the FPGA

5.) Migrate to using a cRIO module for motor control (NI 9505?)

6.) let us use the NI 1742 - I love this thing!

7.) Larger cRIO Chassis maybe 12/16 Slot

[tdlrali]

I started a wishlist over here: http://www.chiefdelphi.com/forums/showthread.php?threadid=67304

[The Lucas]

It's now called "Driver's station" (probably due to trademark issues), and has similar features as the IFI OI - disable/enable/autonomous, 8 digital and 8 analog inputs, 8 digital outputs, 4 USB ports, a small LCD screen, and two ethernet ports (one to robot, one to optional laptop for dashboard)
No, tethering will just use a normal ethernet cable. You will most likely have to turn off the robot-side access point in the pits.

I think you will need a crossover cable to tether, not a normal Ethernet cable. People haven't been talking much about the Driver's Station. This is the new (in development) custom electronics part of the control system. Along with that there is new Field Management System. The cRIO on the other hand is a battle tested industrial controller. If/when there are technical issues with the field (there always are), it is likely most problems will be with the new Driver's Station and Field system, not the cRIO. Also, if I understand the answers to my mentor session questions correctly (I sat in the back and asked a few auto/disable questions), the driver's station will handle more of the on-field control than the old OI. The old OI plugged into the Field Controller through the competition port and most of the work was done by the field controller. The new Field system will be simple/cheaper, and more of the work will be done by the Driver's Station.


The FPGA on the cRIO is an open LV target. This means that LV code can be designated to run on the host PC, the PPC, or the FPGA. Of course LV targets the FPGA via VHDL, and therefore the cRIO is ultimately targetable with C-based .out PPC files and bitfile produced from VHDL. To promote a migration path, promote working, stable robots, and ensure safety, the decision was to keep the FPGA closed for at least the first year. After that, depending on how things go, it could be opened to the extent that there are vanilla, chocolate, and rocky road flavors. It could be opened further by providing 09 source and allowing teams to go nuts. Technically, these are all possibilities, and it is a policy decision as to what makes the most sense for the organization and competition. At this point, I'm sure FIRST is listening, but any opinions you may have honestly aren't well founded. After a season, the feedback will carry much more weight.


I have been wondering exactly how FIRST will implement disable/auto control since I saw the system (that was the root of my question at the mentor session). I understand that FIRST would decide to close the FPGA for safety and other reasons. I think it would be possible to allow teams to customize small portions of the FPGA code and still maintain safety. Based on looking at the Digital Sidecar (http://first.wpi.edu/FRC/digitalsidecar.html), I speculate (no facts) it is already decided that one (perhaps both) NI 9403 Digital I/O Modules will be configured (in FPGA) to provide 10 PWM out, 8 relay out, 14 GPIO, SPI and these cannot be customized. I (and most people here) are not so concerned with changing the number of PWMs provided, but are very interested in customizing those 14 GPIO pins.

I think it should be possible to customize the 14 GPIO (and the NI 9201Analog Input Modules) without sacrificing safety, since those pins should not be controlling motors (PWM and Relay) or pneumatics (NI 9472 Digital Output Module). The disable logic on the PWM, Relay and soleniod should not be affected by changes to the GPIO and analog inputs. Perhaps, teams could write small VIs with the appropriate of Inputs and Outputs for the GPIO that could be automatically inserted into the main FPGA Code. Maybe there could be a custom FPGA loader tool where you simple input 4 VIs (2 GPIO, 2 analog inputs) and the tool inserts these into the appropriate parts of the (hidden) master FPGA source and generates/loads the netlist. I haven't used LabVIEW too much, would it be possible to customize small portions of the FPGA code while keeping the rest of the source hidden from teams? If this is not possible, could there be a simple custom GUI where teams select their sensor types and pins, and downloads the correct netlist to the FPGA?

8) Perhaps a stretch, but what about a no-autonomous switch on the robot? I can think of at least one case this season where such a switch on the robot would've spared a team a yellow card. (The team ran their autonomous, which hit the far wall a little hard and forced a match restart. Since they couldn't reprogram their autonomous in the time given, they went right ahead and clocked the wall again. Yellowcardsville.)


A no-autonomous switch could be easily done this year (well easier than writing most auto routines) and I imagine it would be easy to do next year as well if you want one. I don't want something on the controller that some can accidentally flip and disable autonomous for that match. However, I would love an Auto-only E-Stop for the drivers. No matter how good your auto routine is; things go wrong, collisions happen, sensors fail, etc. It would be nice (and safer) if the drivers could kill an autonomous gone wrong without the consequence of being disabled for the rest of the match.

Personally, I'd find it much more useful if some of this energy were directed into a technical wish-list. Then both FIRST and the staff working on the project could measure the current 09 project against various expectations.


I'll try to organize some of these thoughts into a proper list for the other thread.

[Side Rant] Why are people giving Greg McKaskle negative reputation? :confused: That is a really weird way to to say "Welcome to Chief Delphi Forums, thanks for your insight into the 09 Control System". I know they are just dots, but I suggest everyone reread the reputation FAQ (http://www.chiefdelphi.com/forums/faq.php?faq=reputation_faq#faq_rep2) for the reasons to give negative rep. Some his replies may be a little blunt, but he is positively contributing to the discussion, so be civil.

I understand some people here do not like the changes in FRC or FTC control systems, but don't shoot the messenger. Furthermore, don't shoot an engineer of your new control system who takes the time to answer our questions in this forum. We want people like Greg to become part of our community as he has in other forums. He certainly has contributed quite a bit already, lets make him feel welcome. [/Side Rant]

Wow that was long, can you tell I was catching up on work this week

[yongkimleng]

Not sure when I'd be able to get my hands on a cRIO but here are some suggestions based on what ive read here:

1. smaller AP. I think Fons and Merakis are small and have much lower power draw. They can be re-flashed to act as APs and can work off 9-18V. Range within line of sight is 200m+ and got a whole range of 802.11g channels to choose from.

2. run/stop autonomous/manual switching could be just some code at the processor level and some of the FPGA to totally stop the FPGA signalling, cut off power from the PDB, etc. I think locking out the FPGA totally would mean that we'd be missing out on the cool stuff.

3. assuming the system runs off 802.11 entirely, using the principles of a WDT (watchdog timer) on the realtime processor and have the OI sending "heartbeat" packets every T interval, there would be a pretty good system there to prevent the robot from going out of control when the OI loses its link. The competition controller can use the similar system to decide if robots should be in run/stop or autonomous/manual control modes.

[synth3tk]

[ above post reported ]

[coolbho3000]

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.

Scrap VxWorks.

I can't wait until someone ports Linux to it.

Would it be that hard to get a PowerPC build running?

[artdutra04]

Scrap VxWorks.

I can't wait until someone ports Linux to it.

Would it be that hard to get a PowerPC build running?Why?

If you want Linux on an embedded control system, you can already buy those (http://www.charmedlabs.com/index.php?option=com_content&task=view&id=29).

And judging by notable implemtations of VxWorks (http://en.wikipedia.org/wiki/Vxworks#Notable_products_using_VxWorks), it seems like it's more than capable.

[yongkimleng]

Why?

If you want Linux on an embedded control system, you can already buy those (http://www.charmedlabs.com/index.php?option=com_content&task=view&id=29).

And judging by notable implemtations of VxWorks (http://en.wikipedia.org/wiki/Vxworks#Notable_products_using_VxWorks), it seems like it's more than capable.

Now thats...cooooool :ahh:
And hey its just about the price of a vex microcontroller + programming kit!

[pitzoid]

I guess you all missed this announcement:

http://www.vexrobotics.com/docs/Vex_Qwerk_4-17-08.pdf

[Vikesrock]

I guess you all missed this announcement:

http://www.vexrobotics.com/docs/Vex_Qwerk_4-17-08.pdf

What makes you think that?

While interesting, that isn't really relevant to this thread (about the 2009 FRC control system), nor FIRST as a whole anymore (now that FTC has its own non-IFI platform)

[The Lucas]

Scrap VxWorks.

I can't wait until someone ports Linux to it.

Would it be that hard to get a PowerPC build running?

There is Linux for Embedded systems, its even running on the Moto RAZR phones (http://en.wikipedia.org/wiki/Embedded_Linux).
However, given the choice (no price difference) I'd rather have the kernel that was built to be an RTOS rather than one that is converted to work like one. The cRIO is very expensive so I wouldn't recommend tinkering with your only cRIO (buy a really awesome desktop instead, its cheaper). If you want to tinker and install Linux on an embedded system, I highly recommend installing dd-wrt (http://www.dd-wrt.com/dd-wrtv3/) on a compatible router. It's low risk and you get some amazing features.

[lynca]

While interesting, that isn't really relevant to this thread (about the 2009 FRC control system), nor FIRST as a whole anymore (now that FTC has its own non-IFI platform)

I hope FIRST keeps IFI relevant , since it was built by FIRST members and specifically for FIRST.

[Vikesrock]

I hope FIRST keeps IFI relevant , since it was built by FIRST members and specifically for FIRST.

True, I was referring specifically to the relevance of the new Vex controller to FRC, FTC, or FLL. Other IFI products may still be relevant to these competitions and the new controller may still be relevant to teams for other, non-competition, projects.

[yongkimleng]

There is Linux for Embedded systems, its even running on the Moto RAZR phones (http://en.wikipedia.org/wiki/Embedded_Linux).
However, given the choice (no price difference) I'd rather have the kernel that was built to be an RTOS rather than one that is converted to work like one. The cRIO is very expensive so I wouldn't recommend tinkering with your only cRIO (buy a really awesome desktop instead, its cheaper). If you want to tinker and install Linux on an embedded system, I highly recommend installing dd-wrt (http://www.dd-wrt.com/dd-wrtv3/) on a compatible router. It's low risk and you get some amazing features.

not to mention, now wrt supports overclocking of some chipsets up to 240mhz..

[dcbrown]

Comparision of ports of VxWorks on PPC and RTLinux has shown key elements in terms of real time response favors VxWorks by 30-50%. RTLinux isn't a slouch, but does fall short in real time response in comparison.

This article comes to mind, but I remember reading a couple others:
Performance Analysis of VxWorks and RTLinux (http://www1.cs.columbia.edu/~sedwards/classes/2001/w4995-02/reports/ip.pdf). In general, even if you are not writing a bunch of ISRs for devices, the nature of data flow programming depends upon the deterministic response of handling hard clock interrupts in order to time slice all your tasks.

Another issue is one of support. RTLinux would end up needing a grass roots support effort on this platform along with a port/creation of its own "WPILIB" equivalent. But the real heartache would come with the FPGA and having to integrate that into RTLinux.

Just my opinion - it would be an interesting academic exercise, but you'd be fighting a huge uphill battle to get it adopted by more than a handful of teams because it doesn't provide significant differentiators in terms of functionality while at the same time having potential detrimental performance issues by comparison.

[yongkimleng]

I guess its a matter of choice one has to make, depending on their financial capabilities in using VxWorks or climbing the uphill task.

For those familiar with Linux, probably wouldn't mind taking a look at using RTLinux on it. As for the FPGA interface, no clue, but probably a kernel module for interfacing with it over the PCI bus has to be made if non currently exists.

[synth3tk]

I know this is pretty much off-topic, but
not to mention, now wrt supports overclocking of some chipsets up to 240mhz..
I'm looking at my WRT54GL settings, and it supports 250MHz. I do agree that it has some amazing features, though I haven't tried the Samba share, SSH access, or hotspot settings.

[yongkimleng]

I know this is pretty much off-topic, but

I'm looking at my WRT54GL settings, and it supports 250MHz. I do agree that it has some amazing features, though I haven't tried the Samba share, SSH access, or hotspot settings.

Not forgetting the undocumented TTL serial port on the circuit board. More possibilities there! Could do some justice to the Vex system

[EricVanWyk]

I believe at this point this discussion deserves its own thread.

[valiot]

I took a lot of video this year in Atlanta. My first one up is a run down of the new controller. Watch here:

Video of cRIO controller in a robot (http://vishots.com/2008/04/29/video-of-crio-compact-rio-controller-used-in-2009-frc-competition/)

[rfolea]

Outstanding Video - Thanks!

[MikeDubreuil]

Video of cRIO controller in a robot (http://vishots.com/2008/04/29/video-of-crio-compact-rio-controller-used-in-2009-frc-competition/)
Great video... Andy Deck from NI says they are donating a controller to every team. Does this mean registration fees will be going down? :rolleyes:

[Branden Ghena]

Andy Deck from NI says they are donating a controller to every team. Does this mean registration fees will be going down? :rolleyes:

Actually, it means the kit will still cost the same. The cRIO is an expensive product, and I believe that NI is donating somewhere around $10 million to FIRST to allow them to use the cRIOs and still keep costs down.

[Madison]

Actually, it means the kit will still cost the same. The cRIO is an expensive product, and I believe that NI is donating somewhere around $10 million to FIRST to allow them to use the cRIOs and still keep costs down.

Ignoring any other changes -- registration for veteran teams should be reduced in 2010 and beyond. The fee was raised $1,000 when FIRST began allowing teams to keep their IFI control systems each year. If we are not going to be provided a new control system each year, that fee increase should be repealed. If registration remains the same, veteran teams are getting less value in future seasons than they have in the past. I don't particularly care how expensive the NI control system is -- that is FIRST's concern. My team's concern is that our considerable expense provides good value.

That we're not receiving a new control system each year, irrespective of how powerful or cool the NI system may be, represents decreased value for the registration we currently pay. Actually, it represents additional expenses for our team to maintain the same level of development and outreach. I am surprised there hasn't been more discussion about how this new system will affect registration fees in the future.

[EricVanWyk]

Actually, it means the kit will still cost the same. The cRIO is an expensive product, and I believe that NI is donating somewhere around $10 million to FIRST to allow them to use the cRIOs and still keep costs down.

This is speculation. FIRST has yet to announce registration costs for 2009.

What is certain is that no part of your registration fee ends up in NI's pocket.

[tdlrali]

Where is the VxWorks documentation that some of you were talking about? I couldn't find anything relevant on the windriver website. If it was posted already, I'm sorry, it was lost somewhere on the last 20 pages...

[dcbrown]

Where is the VxWorks documentation that some of you were talking about? I couldn't find anything relevant on the windriver website. If it was posted already, I'm sorry, it was lost somewhere on the last 20 pages...

See post http://www.chiefdelphi.com/forums/showthread.php?p=740276#post740276, just be aware that the cRIO port of VxWorks doesn't have all the components listed in the doc set - the specifics of VxWorks on cRIO won't be released until some time in the future because the C/C++ interface is not currently a public released development environment.

[coolbho3000]

Why?

If you want Linux on an embedded control system, you can already buy those (http://www.charmedlabs.com/index.php?option=com_content&task=view&id=29).

And judging by notable implemtations of VxWorks (http://en.wikipedia.org/wiki/Vxworks#Notable_products_using_VxWorks), it seems like it's more than capable.
Why port Linux to anything? :p

Anyway, the NI one is more powerful, legal to use in FRC (correct me if I'm wrong - not too familiar with the rules yet), and much cheaper for teams.

[Kevin Sevcik]

Why port Linux to anything? :p

Anyway, the NI one is more powerful, legal to use in FRC (correct me if I'm wrong - not too familiar with the rules yet), and much cheaper for teams.Given that the Qwerk has a 200MHz processor vs the cRIO's 400MHz, a (I think) 500K gate FPGA vs 2M gate FPGA, and a $349 retail price tag vs. $3000 retail..... Well I think that about says it all.

[Jwxie]

cool
there are so many terms i don;t understand
-.-rookie hard...

[kamocat]

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

It is mac compatible, somewhat. The first hint is that they have 4 CDs for Windows, and only one for mac. I certainly haven't found any compiler (for free) yet, and it seems they don't really give support for their DAQ on OSX. Heck, I haven't found any compiler for free yet. Can't they give us the compiler for the CRIO-9074? Compiling is usually half of the practicing in programming (though I know with this, most of the debugging is done while it's still a VI).