NEW 2009 Control System Released

[artdutra04]

Originally Posted by Kevin Sevcik

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]

Originally Posted by Kevin Sevcik

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

Originally Posted by BrianBSL

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]

Originally Posted by Kevin Sevcik

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]

Originally Posted by Greg McKaskle

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

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 or 102) 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]

Originally Posted by tdlrali

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]

Originally Posted by tdlrali

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]

Originally Posted by Doug Leppard

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

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

[qnetjoe]

Originally Posted by Greg McKaskle

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/sh...threadid=67304

[The Lucas]

Originally Posted by tdlrali

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.

Originally Posted by Greg McKaskle

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 , 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?

Originally Posted by Billfred

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.

Originally Posted by Greg McKaskle

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