Re: NEW 2009 Control System Released
 

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

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

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

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

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

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

Re: NEW 2009 Control System Released
 

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

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

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

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

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

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

I agree 100% with the above.

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

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

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

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

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

Re: NEW 2009 Control System Released
 

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

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

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

-Danny

Re: NEW 2009 Control System Released
 

*chokes* Erm. A bold statement there. But I'd venture to guess that procedural programming makes up a majority of the actual robotics work out in the Real World. (ie. not NASA, academic research, or the military) See this post for an idea of things. OO is fine and dandy, and useful for doing highly complicated and difficult tasks like machine vision and such.... But there's a distinct difference between complication and utility.

Re: NEW 2009 Control System Released
 

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

Two points:

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

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

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

These are all related to the fear that NI's ultimate goal is that someday we will all be programming our robots in LabView because the C/C++ interface is crippled. The NI reps have stated many times that is not the goal and the C/C++ and LabView libraries will be of similar quality. If you want to program in C, nothing is stopping you.

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

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

I agree, but I don't see that as a significant challenge. Plus with the wireless programming interface and the increased debug capabilities, programming problems will be a lot easier to find so it kind of balances out.

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

Re: NEW 2009 Control System Released
 

Jay,

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

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

I am sure it will all work out.

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

Should be an interesting year.

Re: NEW 2009 Control System Released
 

This was sent out tonight...

Re: NEW 2009 Control System Released
 

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

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

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

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

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

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

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

Re: NEW 2009 Control System Released
 

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

NI_RIO_PEEK(FPGARef, address, &result);

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

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

Greg McKaskle

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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


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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

Excellent comments Al.

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

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

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

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

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

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

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

I also wonder if Kevin Watson will stay involved.

Re: NEW 2009 Control System Released
 

I remember NI making available some DAQ hardware to teams that proposed what they'd do with them. What if some combination of FIRST and NI accepted proposals from teams to devise methods of getting the new hardware exposed to as many as possible before the season? With some bias towards geographic diversity (lest all the Mid-Atlantic teams that host off-seasons would have pretty epic odds), you could probably get a lot of teams up to speed pretty quickly, more with the benefit of YouTube/Vimeo/TBA.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

Minutes is probably a little optimistic. For a team with a laptop that just meets LabVIEW requirements, I'd guess 10-15 minutes, since a fix to some base level code is going to invalidate a fair number of things. And the field controller... That's going to be complicated enough that any fixes would probably be done over lunch.I'll note that on a 1M gate NI FPGA, I managed to implement the forward kinematics for a 3-DoF rotational joint device, X-Y-Z PD loops, and the transverse Jacobian to take those XYZ forces back into joint space, with lookup tables for all the trig functions. It only took 30 minutes to compile on my 2.0 GHz dual-core laptop. And if I changed some of my built in constants for joint lengths, it wouldn't fit on the FPGA anymore. So while I don't think it'll take hours to recompile the safety, PWM, and (hopefully) encoder logic on the FPGAs, it's definitely not going to be mere minutes.

Re: NEW 2009 Control System Released
 

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

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

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

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

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

???

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

The biggest plus is also the biggest minus:

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

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

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

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

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

Re: NEW 2009 Control System Released
 

This is assuming, of course, that all this functionality is actually implemented on the FPGA for us. I'm not entirely certain that's a given. Of course, if it's not on the FPGA and we aren't allowed to implement it ourselves, I'm going to feel pretty darned silly still doing quadrature encoder counting using interrupts. Actually I'm going to feel pretty annoyed even if they implement the encoder logic on the FPGA for us, since it's pretty unlikely ever team is going to need the exact same number of encoders. Seeing as how a mechanum system with two feedback controlled joints would potentially need 3 times the interfaces as a two wheeled kit bot.

Re: NEW 2009 Control System Released
 

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

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

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

Re: NEW 2009 Control System Released
 

Dave,

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

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

Greg McKaskle

Re: NEW 2009 Control System Released
 

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

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

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

Greg McKaskle

Re: NEW 2009 Control System Released
 

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

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

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

:ahh:


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

Re: NEW 2009 Control System Released
 

Actually, I think it's well nigh impossible for you to programmatically override the supervisory control of the master processor in the IFI controller. All the outputs controlling real world devices sent through buffers controlled by the master processor, so it has the final say if a motor's turning or not. And it takes very little data back from the User Processor in a very controlled manner, so I don't think you could even reliably override it with packet overruns or something.

Re: NEW 2009 Control System Released
 

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

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

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

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

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

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

-Danny

Re: NEW 2009 Control System Released
 

This is getting off-topic, but...

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

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

Re: NEW 2009 Control System Released
 

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

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.

It's definitely possible to send interrupts from the FPGA to the RTOS, 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). The WPI libraries could make this simple for us.

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.

[Edit]: Come to think of it... this won't work too well, but I think the idea may be feasible. Can anyone fix it?[/Edit]
[Edit2]: 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.[/Edit2]

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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?

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

There are only 4 analog inputs.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.


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?

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.

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

Re: NEW 2009 Control System Released
 

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.

Re: What you love to prepare for weekend?
 

Re: NEW 2009 Control System Released
 

Scrap VxWorks.

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

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

Re: NEW 2009 Control System Released
 

Why?

If you want Linux on an embedded control system, you can already buy those.

And judging by notable implemtations of VxWorks, it seems like it's more than capable.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

I guess you all missed this announcement:

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

Re: NEW 2009 Control System Released
 

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)

Re: NEW 2009 Control System Released
 

There is Linux for Embedded systems, its even running on the Moto RAZR phones.
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 on a compatible router. It's low risk and you get some amazing features.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

Outstanding Video - Thanks!

Re: NEW 2009 Control System Released
 

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:

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

See post http://www.chiefdelphi.com/forums/sh...276#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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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.

Re: NEW 2009 Control System Released
 

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

Re: NEW 2009 Control System Released
 

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