New Robot Control System!

[lynca]

I like the idea of building off current technology. Adding a PC104 or mini-itx computer to interface with the current IFI controller would be a great way to keep the low-level drivers and expand on high level programming. I thought the Adam-Bots Co-Processor platform was a start in the right direction.

In terms of the actual hardware, Royal Assualt's (357) "Schubox" PCB of a board to inteface to IFI RC is a great idea. I think FIRST should sell a simplified PCB design (like the VEX controller). Letting teams do their own PCB design would bring down the cost of Electronics tremendously.

[Danny Diaz]

Originally Posted by bcieslak

I'll bet its a version of the NxT conroller used for Lego League.

That would be, ummmm, scary. I would really like some of its technologies, though, like Bluetooth and/or a wired connector (like maybe ethernet or maybe sport a USB hub), a FLASH-based filesystem (OMG, an onboard filesystem?!?!) and a way to get a display screen output (OMG, onboard feedback?) but I would definitely prefer something with a little more horsepower underneath. Also I'd like something, as in a newer processor, that could natively handle multiple threads, instead of the emulation we had to do on the NXT (and by WE I mean National Instruments).

But I hope they don't try to migrate to the Inteletek C or the Microsoft Robolab stuff and actually look to see what direction industry is going so we can develop skills that we can use in the future. Maybe something more LABview focused.

On one level I agree, and on another I don't. I wouldn't mind seeing the Microsoft Robotics Studio or even an Intelitek graphical C building environment. I would love to see the controller programmed with LabVIEW - though I must admit I'm a bit biased - but it would still require something with a little more advanced technology than we currently have. I'm sure this will be evaluated as it has been for all previous technologies, whenever the new platform is unveiled.

I suspect the details we be announced two days before kick-off. :-)

I would hope not. For LabVIEW and the USB-6009 devices we've been trying to get informally adopted by FIRST teams we (as in National Instruments) have been trying very hard (unsuccessfully) to release LabVIEW and the devices to teams prior to the competition season, to give them a chance to learn how to use the software/hardware so that it's not such a barrier to its use during the season. I would like to see FIRST adopt the same kind of strategy, except maybe a little more successfully.

-Danny

[BrianBSL]

Originally Posted by lynca

I like the idea of building off current technology. Adding a PC104 or mini-itx computer to interface with the current IFI controller would be a great way to keep the low-level drivers and expand on high level programming. I thought the Adam-Bots Co-Processor platform was a start in the right direction.

In terms of the actual hardware, Royal Assualt's (357) "Schubox" PCB of a board to inteface to IFI RC is a great idea. I think FIRST should sell a simplified PCB design (like the VEX controller). Letting teams do their own PCB design would bring down the cost of Electronics tremendously.

Having teams do their own pcb design is not the way to go. Maybe 10% of FIRST teams could pull that off, and I'd say not all of them reliability. What do the rest of the teams do? As much as I love flexibility, they need a solution that doesn't prevent teams lacking resources to compete, while allowing other teams to expand as necessary.

I say give me some embedded 32-bit processor running an os (vxworks or embedded linux among others) with an FPGA on the IO. None of this x86 stuff - we simply don't need that power nor the complexity. The FPGA can do timing dependent stuff (count encoder pulses and time ultrasonic devices) and have the equivalent of the "master" uP in it to disable/enable the outputs. This leaves the processor open to the teams to do whatever they want with. This is similar to how the CMU Qwerk works, and even how a gumstix/robostix combo works (although yes, the robostix is an AVR and not digital logic). I think the Qwerk is actually a pretty good starting point, although I think it needs quite a bit of SW development before we could use it for FIRST.

As far as wireless between the OI and RC, I don't know that an off the shelf solution such as zigbee or 802.11 will work for this. With 802.11, things such as binary exponential backoff I just don't think will work for our situation - as it isn't impossible to end up with large latencies if the channel is congested (which aren't great if you robot is heading towards a wall, or worse, a person). Remember we need at least 6 robots with dedicated communication between each other. I haven't really put enough thought into it to really make some strong statements on this, however I think the communication between the robot and the OI can be focused on at a later date. I think enhanced processing power and an operating system is more important.

If there are really going to be a year and a half of development time on this, hopefully it will have some serious thought put into it and be a rock solid product.

[Lil' Lavery]

This a tremendous change. The control system is the foundation of the robot, and robots are the foundation of FIRST. If this new system does not perform, it could mean some serious issues for everyone.
I hope FIRST at least considers IFI (if they are not already the guaranteed vendor) as the vendor for this next generation control system. Innovation First Inc. was founded by FIRST mentors, and has maintained a intricate and successful link with FIRST. IFI understands FIRST, and the needs of FIRST teams. I hope the vendor for the next generation system does as well. I also hope that this doesn't harm IFI's bottom line in anyway.
We had a proven technology in place, that performed well. FIRST moving towards a new system indicates to me that they probably want more ambitious solutions and use of technologies. More frequencies? More memory? More processing power? What will we do with these technologies (if they are delivered properly)? More autonomy? Who knows...
I just hope they pull it off well, 2009 doesn't seem that far away.

[petek]

Adding one more voice of hope that FIRST is looking at the big picture on this, I hope they don't forget VEX and how sharing the core architecture, libraries and development enviroments facilitates prototyping and learning with the less-expensive and newbie-friendlier VEX system, AND creates a stepping stone to FRC.

If IFI is involved in the new system I sure hope they migrate VEX, too. If they aren't, does the FRC system move say anything about FIRST's long-term plans for FVC? I continue to maintain that the only way FIRST can hope to have a team in every high school is with FVC - or a similar-scale program.

[whytheheckme]

I'd love to see a control system in which all of the processing is done on the OI by a laptop..... Meaning all of your code is run there, etc. Then all you need onboard is a little encoder for all of your sensors which gets transmitted to the OI. Then you are pretty much limitless as to what you can do with your bot, and how much processing power you have. Imagine controlling your robot using your mouse and keyboard!

Perhaps an operating system (some *inx) that is a standard among FIRST. You need this operating system installed on your laptop for it to be able to compete. Then you can write code for this OS, and the OS runs it in a nice, controlled manor. Then you can write drivers for devices, etc. Kinda moving away from PIC technology into something more modern.....

Then imagine the possibilities. People of the CD and FIRST community writing programs which interface with each other (for alliance feedback between robots). The the computer can automatically decide what the best course of action is....

Then imagine totally autonomous robots!!!!!! ZOMG!!! I think this is the ultimate goal... and doing something like this would be the next step toward it....

OK, I'm getting ahead of myself.... but I think it would be cool

Jacob

[marccenter]

Most folks have commented more on the hardware side,
so I will focus my comments on the software side.
I hope we move away from C programming and to
a graphical language like the way I have been programming for the past three years - Matlab and
Simulink. For high school students who haven't yet
been exposed to these packages, think Robolab or
NI Labview.
My professional experience at GM has enabled me to
seen us move from Motorola 6800/6801/68HC11assembly language (1982-1995), through MC68332
C (1995-2007) and now Mathlab/Simulink (2004-2007).
For those programmer's who are operating in C , that's
Great, but for me, I haven't touched pure C in the last
five years other than to work with the FIRST IFI controller.
I hope FIRST can cut a deal to give student's the tools
that we will be using in the workplace in the near future.
How may other folks out there are using the Mathworks
software productline to autocode into "C"?

[Alan Anderson]

Originally Posted by marccenter

...I hope we move away from C programming and to
a graphical language like the way I have been programming for the past three years - Matlab and
Simulink. For high school students who haven't yet
been exposed to these packages, think Robolab or
NI Labview.

More appropriate to the audience, think EasyC.

For those programmer's who are operating in C , that's
Great, but for me, I haven't touched pure C in the last
five years other than to work with the FIRST IFI controller.
I hope FIRST can cut a deal to give student's the tools
that we will be using in the workplace in the near future.

Assuming by "tools" you mean "graphical programming environment", FIRST did do that.

[Adam Y.]

Originally Posted by Joe Matt

I find this VERY interesting, FIRST usually doesn't announce things like this early. Could it be used as a scare tactic against IFI? Possibly, probably not. I think we might see FIRST in the future asking us what we want to see, and this announcement as a way of giving everyone a heads up. Maybe this is why Team Forums are more limited this year?

/me ponders the possibilites

Actually, my best guess is that this product is going to be announced on Wensday by IFI in Boston. They really don't want some random person posting this information and hence they send out the email so that people are suprised by some random Joe posting it on Chiefdelphi.

[Pavan Dave]

Wow...Making my life harder arn't they... I like Andrew Lynch's idea of releasing a schematic or a PCB layout etc, with basic functions so that it will run without much work for the rookies. I think that this would also give the Controls subsystems a little more work and a little more importance due to the nature of the brain and its relationship with the robot. I think if FIRST said, "Hey you must use ABC123 Processor and X,Y,Z chips, but the rest is up to you" it would be great.

Change is always good, it's just your perspective of change which blinds you from the potential possibilities.

[Dave Flowerday]

Originally Posted by marccenter

I hope we move away from C programming and to a graphical language like the way I have been programming for the past three years - Matlab and Simulink. For high school students who haven't yet been exposed to these packages, think Robolab or NI Labview.

I think options are great. More languages, high level interfaces for those who want it, but also... retain the low level (C) interface for those of us comfortable with it!

The SW kids on our team have mastered writing C code for the robots and I'm proud of them for doing it. In my opinion, knowing how to write code in C helps immensely for being able to efficiently use higher-level languages and interfaces. Kind of like how students always learn how to do long division and calculus by hand, even though there are higher-level tools out there that they could use.

Give us choices - don't make the decisions for us!

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

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