New Robot Control System!

[ThomasP]

Originally Posted by BrianBSL

I'm not sure what you mean by that - I'm pretty sure that the OS in the phone wasn't coded in Java, unless it runs java byte code natively.

I was just throwing that in there to support the use of high level languages on embedded devices since a few people are complaining about the possibility of using a language like C# or Java instead of C.

[Qbranch]

Originally Posted by Dave Flowerday

Finally, it would be great if they picked a processor with a free toolchain (GCC would make the most sense). AVR or ARM would be a good choice for this. It would open the doors to Mac/Linux development. Unfortunately I think they have a strong relationship with Microchip so we'll probably continue to see more PICs in there...

I have to say that staying with pics is probably the best thing to do mostly because teams' older members as well as software mentors are all experienced in pic architecture, how the peripherals operate, etc. A huge amount of relearning throughout the FIRST community would have to be done if the RC started using a processor from a different silicon manufacturer.

Plus, though other chips are flashier in their features the PIC microcontroller has a very high level of robustness such as high drive current on output pins and the ability to even handle a few ESD hits. I admit that having an ATMEGA8 or MEGA16 or heck even a mot ColdFire would be sweet, but, in the application environment I'd rather take the pic overall. Plus, you get the compiler for free from first...

-q

[Greg Needel]

Change is scary, more now then in other situations. If you look at the past to see how FIRST has handled new technology there have been many problems. Hatch, Banebots, the old FIRST controller, etc. I have my doubts about a change of this magnitude. If I am interpreting this email blast correctly it leads me to believe that the RC, OI, Victor, Spike, Arena Controller, and field control software will be all be gone.

Now I do see the potential for this change which will enable established teams to do more with their robots, but my doubts stem from the rookie teams of 2009 and on. Rookie teams need support from veterans which will be a seemingly impossible task if everyone is in the dark. Utilities like easyC and the WPI libraries will all have to be redone. I know that there is better technology out there which could make things easier but how much harder will it be to run an event when the bugs are still being worked out.

I am happy that they decided to give this development over one year but it concerns me that FIRST might have cut their nose off to spite their face by locking themselves into a new system which as of now is probably just on the drawing board or early stages of development. I just hope that the people who make decisions know what they are doing in this situation.

[Richard Wallace]

Originally Posted by Greg Needel

Change is scary, more now then in other situations. ... If I am interpreting this email blast correctly it leads me to believe that the RC, OI, Victor, Spike, Arena Controller, and field control software will be all be gone.

Maybe not the field control software. I agree it appears that we'll be getting a new arena controller, RC, OI, motor controller, and relay for the 2009 season. The 2007 FMS is a major improvement over what we had; it should be improved further, not scrapped.

Originally Posted by Greg Needel

Now I do see the potential for this change which will enable established teams to do more with their robots, but my doubts stem from the rookie teams of 2009 and on. Rookie teams need support from veterans which will be a seemingly impossible task if everyone is in the dark. Utilities like easyC and the WPI libraries will all have to be redone. I know that there is better technology out there which could make things easier but how much harder will it be to run an event when the bugs are still being worked out.

I agree there will probably be slowdown in new team development by existing teams; that may be offset by team development through new channels if the new control system offers a signficant reduction in learning curve.

Originally Posted by Greg Needel

I am happy that they decided to give this development over one year but it concerns me that FIRST might have cut their nose off to spite their face by locking themselves into a new system which as of now is probably just on the drawing board or early stages of development. I just hope that the people who make decisions know what they are doing in this situation.

I hope so too.

Announcing the schedule for introducing the new system is really the only way FIRST can drive this to happen. 2009 will be a challenging target. I'm just happy that FIRST recognized they can't realistically introduce a new system sooner.

Yes, change is scary; however, this change can and should be a good thing. Many present FIRST participants and volunteers have skills and experience that enable them to help FIRST make that happen; I sincerely hope that potential will be recognized and used effectively.

[Eldarion]

Something like this would be a giant step forward...
http://www.analog.com/en/prod/0,2877...DSTAMP,00.html

As far as auxiliary control system hardware goes, I for one will continue working on it. The new processor is still a general-purpose computer system, and application-specific computers will always perform better at their specific task(s).

It would seem to me that the new system, if properly designed, could actually offer teams the chance to incorporate more sensors and sophisticated control algorithms (maybe even AI?) than the old system.

Just my $0.02.

I am sad to see the old system go though, especially after reverse-engineering the field control system

[JesseK]

I hope to god it's not Java-based.

Java on an embedded system is horribly bloated and slow compared to other programming languages and techniques. It's also very very easy to create memory leaks when you have several different software/hardware packages that you're trying to integrate together. So some might see Java as a blessing for an easier language to program/debug in, but the catch is that it will be terribly slower unless the processing speed is that much vastly greater.

For you Java programmers, see if you can create any sort of code for your current drive train using event handlers, enums (Java 1.5+), and other nifty dynamic things that Java allows (like the Math functions). Then force the code to perform an exception in the Event queue (easiest one is a null-pointer exception on state data that you expect to be there but isn't there). That 25-line stack trace is enough to convince me that this language is too bloated for the simple things we're trying to do.

[tjcasser]

Originally Posted by JesseK

I hope to god it's not Java-based.

To argue the flip-side of it... I disagree entirely. I think Java could be a very interesting choice.

I'll admit that I am biased - Java is about 70% of what I do for a living. However, I also had the opportunity this past week at JavaOne (Sun's annual developers' conference) to get some coding time on Java-powered robots and found the code base they were using - Java Micro Edition - to be easy to work with and fairly streamlined when it came to handling commands. I think it would certainly introduce a different level of challenge with a language transition, but I don't think that there ought to be an automatic concern that "Java is too bloated" to work. The proof, as they say, is in the pudding.

Furthermore, it's not like Java is not being taught in the schools anyway - in many schools, it's taking over from C as the language of instruction, and the AP exam in Computer Science now covers it.

That all being said, I think that while I would certainly welcome the use of Java in FIRST, there needs to be some serious consideration given to the amount of code and experience that would be left behind that first year after a change.

[Chris Marra]

In the midst of everyone suggesting laptops, Bluetooth, 802.11 wi-fi networking, can we all take a step back and look at the feasible possibilities of FIRST? Over time the games and structure of the organization has slowly shifted from a very small kit of parts to a comprehensive one that includes a robot in a box. I am not calling this a negative change, because it is great for rookies just getting started, and still allows for mobility in veteran teams.

Arguably the most difficult component of the robot to customize, in fact, would be the controls system. Short of an EE/CS or ECE on your team, many students are probably lost when it comes to the world of C and an embedded robot controller that honestly is not too user friendly. Between serial communications, MPLAB, IFI Loader, and all of the steps required to write code and get it onto a robot, it is no small task (EasyC is an exception).

However, the actual system controlling the robot is extremely efficient and streamlined, considering it is specifically designed for an application specific task, which it accomplishes, and does so at a relatively low cost. Adding in features like Bluetooth, Wi-Fi, or even using Mini-ITX or laptops significantly adds to the cost of the KOP, and to me, it doesn't make things more simple.

I would expect to see a controls system that is more featured than what we see from IFI today, considering the PIC can be a relatively limited resource, and one that will be more rookie friendly, featuring a number of expanded options built into the design. 195's LCD diagnostic tool in 2006, and their theoretical dynamically generated PDA autonomous mode come to mind, and something a step above MPLAB designed to eliminate code barriers might also be possible (Yes, I know, EasyC). Beyond USB support, and maybe a new radio protocol, why does FIRST need its robot controllers to be laptops or feature Bluetooth? As it stands, C: Works, Victors: Work, CMUCAM: Works, and their only motivation in a new control system must be to help rookies and add enhanced features that go beyond a PIC in the new RC/OI. At the end of the day, FIRST is not a consumer product that needs flashy stickers with new features on it, and I think its important that the controls system reflect this by adhering to a very simple principle: KISS.

[Nuttyman54]

I would like to preface this post with the fact that I am NOT a programmer, and know very little about how the control system works.

I've noticed a lot of people in this thread mentioning FIRST's failed attempts at a "1.0 release". From my observations, a lot of these problems (Hatch, Banebots, Radio issues) appear as such due to insufficient testing time. Had the Banebots been tested under load (like Dr. Joe did), had the radio issue been discovered earlier, etc, I'm sure the teams would have never known there was an issue, because FIRST and the vendors would have fixed them ahead of time.

I'm hoping that the reason for the early announcement (as compared to previous announcements of changes in the KOP) is so that they will have sufficient time to test the system under competition conditions, hopefully with the aid of teams.

I will reserve my judgment of the new system until I have seen it in action, or at least seen more information. Speculation at this stage is nigh useless.

[tseres]

i just really hope they stick with IFI. IFI does everything for FIRST. I'm a rookie this year, but was the pre-2004 RC extremely different from the 2004+ RC's? i dont think FIRST will throw everything they have out. maybe i can hope for a screen on the OI? that would be so mich cooler than the dashboard. And i think the tranition from a PIC will be a slow one...if the new system is too different, no one will be familiar with it. you could potentially have a seasoned FIRSTer who now knows little or nothing about a new system. I noticed in the email it said "multiple programming languages." as long as they keep C (for now) i'll be happy. i'm sure they'd support many different (or popular) languages. maybe something like VB (lol)? personally, the only thing i would want is a better processor for trig (i'm told they dont like trig now...).

well, whether we like it or not, there will be a new system, bugs and all. i guess all we can do for now is deal with the 2008 season and trust that FIRST will make the best choice on what to do.

[Kevin Sevcik]

Ok, my thoughts on this briefly.

First, I don't particularly like Zigbee, Bluetooth, 802.11[^a], etc for our little application here. Yes they work well for the things they do, but I don't think they'll work all that hot for our robots. Zigbee and 802.11[^a] especially are subject to interference from all sorts of stuff including the myriad of wireless networks that pop up at competitions. We all know they're there, we all know that no amount of FIRST telling people no won't prevent this announcement: "Will all teams please turn off their wireless networks, they are interfering with robots on the field." I realize that pit wifi networks interfering with the field in this manner is a slim possibility. But it is currently impossible for them to interfere with our 900MHz modems. Plus, how many of us demo robots in wifi-dense corporate settings? I don't want our robot failing spectacularly when we try showing off to sponsors. I make exception for 802.11a and other 5GHz flavors since they're in a much less popular and populous band. I realize this opinion probably isn't going to prevent a move to the 2.4 GHz band since it's the only place to go, but I don't have to like it.

Second, running OSes on robots by default. I realize that we're all expert Linux programmers and all that, but moving to that complex of a platform makes me nervous. Nervous for our young teams. This move is certainly going to be accompanied by new graphical tools and wizards for the rookie teams, etc. I think the question is just how much fancy pants autonomous code you're likely to be running out of the simple option. And just how easy it will be to make the jump to the more complex option. Coding in a multi-threaded, preempting real-time operating system is just a little more complicated than what a whole lot of our teams are managing with MPLAB right now.

In summary, yes I'd like more power and memory. But not at the cost of (relative) simplicity and reliability. I'd really be fine with a bigger faster PIC with some SPI and I2C ports available. Given the GDC's stance on repeated code use from year to year, just how much sleep are you and your mentors planning on getting with 6 weeks of coding and debugging this flashy linux RTOS based robot to look forward to?

[Dave Flowerday]

Originally Posted by Kevin Sevcik

Given the GDC's stance on repeated code use from year to year, just how much sleep are you and your mentors planning on getting with 6 weeks of coding and debugging this flashy linux RTOS based robot to look forward to?

I have a hunch those asking for Linux or an RTOS probably haven't spent much time trying to debug thread synchronization issues, memory corruption, deadlock, priority inversion, stack smashing, etc. Especially on an embedded target. Especially on a physically-moving embedded target!

When it comes to software, my rule of thumb is that the simpler it can be the better.

Incidentally, it's possible to run an RTOS on the current IFI hardware. FreeRTOS runs on the PIC18. No one that I'm aware of is doing it (and it's not because there aren't people here capable of it).

[Danny Diaz]

Originally Posted by Dave Flowerday

I have a hunch those asking for Linux or an RTOS probably haven't spent much time trying to debug thread synchronization issues, memory corruption, deadlock, priority inversion, stack smashing, etc. Especially on an embedded target. Especially on a physically-moving embedded target!

ROFL. That's actually my job right now (working in LabVIEW Real-Time at NI), and yeah, good luck. I'll testify that working with an embedded RTOS is really cool, really rewarding, and really powerful, but with great power comes great responsibility (and a potential debugging nightmare). Of course tools have come a long way, NASA even had to debug an RTOS on the Pathfinder mission, and the story of how they figured out what was wrong and how they fixed it makes for a VERY interesting read.

-Danny

[artdutra04]

While I'm not directly opposed to change, I sure hope FIRST truly understands and comprehends everything before they move onward with implementing this new system.

Right now, Vex and the FRC controllers share much of the same hardware. Vex is a cheap[er] controller to buy to develop code on. Much time and effort was spent on writing WPIlib and EasyC to program both of these controllers, and to facilitate the use of many of the advanced features (like the CMUcam2) on both platforms.

With a new control system, FIRST needs to understand that:

• A low cost version of the controller (such as the Vex controller) should be cheap and readily accessible. Most FRC teams probably already own Vex kits, so this is essentially free for them.
• Sometimes having a "limited" system with less features than having more-features-than-you-can-shake-a-stick-at is better. While we intuitively always want bigger, better, isn't a "limited" controller much more like the you-have-six-weeks-and-not-enough-time-and-resources-to-do-this-perfectly mindset that FRC has always been about? (I support upgrading the control system, but I also strongly stand beside the limits placed on things like the number/type of motors used, etc.)
• If FIRST wasn't to go with IFI to produce this new system, will the new company provide the immense amount of support that IFI has? Will the new company send reps to every regional? How much experience specifically with FIRST (as opposed to Battle Bots) would the new company have?
• If IFI is developing the new platform, will it be at least cross-compatible with the old system? (I'm thinking of teams - like my own - who have a ton of older IFI control system equipment from being involved with FIRST for many years, that we can use for prototyping/practice robots/etc.)
• If FIRST truly wants the majority of teams to do advanced things with their robots, they need stability! By keeping the same architecture of the control system, robot size/weight, etc. the same year-to-year, teams are given the chance to come up with advanced ideas in the off-season. (Six weeks is enough to implement ideas, but not enough to try entirely new and untested things.) But if FIRST is always changing things around, then teams won't want to develop anything in the off-season if they have any indication that their work will be all of a waste come the next Kickoff Date.
• Any decision made should be in the best interest of the teams competing. Rather than have this be a "secret", I hope FIRST openly and transparently announces soon what exactly is the change they are proposing, and open up for feedback from the community. If there is anyone who knows what is best for teams, it's the teams themselves.

[bear24rw]

I really hope that they dont move away from C.. And I really really hope they dont make us program graphically. I don't think that we need Linux or another OS, I wouldn't mind seeing a faster processor and more memory and eeprom (maybe switch to an arm processor) but i deffiently dont think that we need a computer on our robots. For the radios, they should stick with 900mhz, 802.11 is too crowded and 2.4 has phone issues. The only thing that I would really want to see change in more serial ports on the RC and a faster program loops 26ms is soo slow.