New Robot Control System! [Archive]

Shinigami2057

14-05-2007, 09:12

Greetings Teams:

We are pleased to announce we have begun development on a new Robot Control System for the FIRST Robotics Competition. The new system will be introduced in the 2009 season.

While specifics are not yet available, the new electronics are expected to provided additional features such as: greater processing power and memory size, adaptability to a wider variety of programming languages, and include increased support for enhanced peripherals such as new sensors, vision systems, motor controllers etc.

We will keep you updated as we move through the development process. In the meantime, have a terrific summer and please check your email or our email archive page at http://www.usfirst.org/community/frc/content.aspx?id=3520 for upcoming 2008 season information.

Go Teams!

So what do you guys think it will be? dsPIC? ARM? AVR? Blackfin? Robostix? Intel XScale? MIPS?

This could be very very awesome :]

Gamer930

14-05-2007, 09:24

OMG Speechless . . . . . .

USB????????????????
FireWire????????????
Non-Serial??????????

:confused: What other languages could it be??? Java?? actual C++?? C#?? :confused:

Lets just hope it isn't another flop like the 2007 radios were and they do some actual testing :)

Grant Cox

14-05-2007, 09:30

OMG Speechless . . . . . .

USB????????????????
FireWire????????????
Non-Serial??????????
USB is currently available ;)

DRH2o

14-05-2007, 09:40

USB is currently available ;)

But not included :cool:

ZZII 527

14-05-2007, 10:00

If I may venture a wild guess based on my own speculative adventures into radio controlled robotics:

USB joysticks/controllers via a laptop included in the K.O.P. (OI+dashboard combined) and a new radio format - Zigbee? 2.4GHz, 115kbps up to 300'... http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php

Wireless everything, including programming and debugging.

As for..."adaptability to a wider variety of programming languages"...hrmmm, no ideas...

seanl

14-05-2007, 10:06

yay java programminng:yikes:

Qbranch

14-05-2007, 10:07

mmmmm zigbee... that would be GREAT! no more drop outs, crushed flower pots, trashcans, or dented walls!

Don't think i want USB or FireWire for programming... i have this thing against networks getting in the way of me loading code... plus it would be a ton of overhead for the processor to run the USB stack. A dsPIC would be SWEEEET though... I just hope they keep C!

An updated OI with oLED matrix display (like those new osram pictiva (http://www.pictiva.com) ones, got the 3" screen demo kit, full color graphic display screen) for more readouts on the screen and the ability to make graphical outputs would be sweet...

Maybe moving all of the pwm outs up to 16 bits might be cool too... I did that on our robot this year and LOVED the results... not only do you get a ton more resolution but you also get to use all integer math for integrators n stuff since your numeric range is so huge...

I'd also like to see a higher chop rate speed controller, like 2KHz chop rate as opposed to the 120hz now so the first robots lose the angry buzzing.

I feel like i'm writing a christmas list... :o

-q

EHaskins

14-05-2007, 10:21

I want Linux!:D

I can't wait until 2009.

Tom Line

14-05-2007, 10:47

I for one hope they remember that while many newer langauges are nice, they are not taught at many high schools.

Visual Basic and C are basic languages that most schools will teach (if they teach anything). Going too far afield with the language (C# or C++ comes to mind) will force quite a few folks to have to try and learn a new langauge. I don't think that would be in the best interest of the competition.

Simple functionality improvements like wireless uploading to the Robot OI would be an incredible step forward in usability.

The option of storing several different compiled versions on board would be nice at times.

I actually appreciate the limited memory size and limited processing power. How many folks were forced to learning something new because doing floating point and trig killed the processor? It also prepares them for the state of the industry in most manufacturing environments. Finally, it forces folks towards elegant programming - clean code without a lot of garbage.

Madison

14-05-2007, 10:48

It's interesting that they'd decide to announce this so far in advance. I wonder how long it'll be before they release more information and whether this will affect how much development people put into auxiliary control system hardware next season.

Dave Flowerday

14-05-2007, 11:02

Sounds like this is not being done by IFI... anyone know who the new control system vendor is? I hope they're able to continue the same quality and reliability standards that IFI has created.

I also hope that FIRST is seeking out input from mentors in the program on the issues that would arise with this. Hopefully they're talking to software and electrical people about this.

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

Greg Needel

14-05-2007, 11:12

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.

Covey41

14-05-2007, 11:54

This topic is less than 3 hours old and the Chief Delphi community is complianing already:

Sounds like this is not being done by IFI... anyone know who the new control system vendor is? I hope they're able to continue the same quality and reliability standards that IFI has created.

Let's not forget the 2007 radios! (No cell phones near the radio towers.)

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.

I don't care who designed it, or who makes it, NO ONE makes anything perfect the first time, or for that matter everytime.

Lets disprove a new saying overherd at the VIP reception in Atlanta:
"FIRST - Technolgy building egos"

The process just started, give them a chance!

Rohith Surampudi

14-05-2007, 11:58

I want Linux!:D

I can't wait until 2009.

i met 2 gentlemen in Atlanta, one from Google, and one from Red Hat who mentioned to me that they were hoping to have linux in our robots for the next season... maybe this is the results of their work...

Dave Flowerday

14-05-2007, 12:01

This topic is only less than 3 hours old and the Chief Delphi community is complianing already
That's not a complaint at all. My concern is that this is a critical piece of the FIRST puzzle and we have a good, working solution in place. I'm all for new technology (and I think the control system could use a refresh). FIRST has a good history of having things "not work" in the 1.0 release (see scoring software for the last 4 years as an example).
Let's not forget the 2007 radios! (No cell phones near the radio towers.)
Yes, this was a problem. But, given the amount of stuff produced by IFI, it's fair to say that that was anomaly. Also, the problem was resolved before any official competitions occurred (and seemed to be a complete non-issue from that point on).

Danny Diaz

14-05-2007, 12:03

mmmmm zigbee... that would be GREAT! no more drop outs, crushed flower pots, trashcans, or dented walls!

Zigbee? Zigbee wasn't designed for bandwidth - The 802.15.4 bit rates are specifically limited to 250Kbps compared to 1Mbps for Bluetooth. I personally would prefer wireless 802.11[n/g] for everything, if power was not a concern.

-Danny

Richard Wallace

14-05-2007, 12:04

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

14-05-2007, 12:05

Something like this would be a giant step forward...
http://www.analog.com/en/prod/0,2877,BF537%252DSTAMP,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 :)

Qbranch

14-05-2007, 12:14

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

14-05-2007, 12:19

This topic is less than 3 hours old and the Chief Delphi community is complianing already:

Let's not forget the 2007 radios! (No cell phones near the radio towers.)

I don't care who designed it, or who makes it, NO ONE makes anything perfect the first time, or for that matter everytime.

Lets disprove a new saying overherd at the VIP reception in Atlanta:
"FIRST - Technolgy building egos"

The process just started, give them a chance!

First off, I don't think anyone is complaining. We are just identifying difficulties which will need to be addressed. It may come as a shock to someone without a team but it makes it very difficult to build a program at a school when drastic things change from year to year. Over the past couple years (05+) there have been some major consistencies which increased the quality of the robots across the board. Things like the kit chasis and transmission along with easyC gave teams without engineering support the ability to make decent machines. Now as someone who has been in FIRST longer then I have you have seen things change more over the years with both good and bad results. The overall trend is to fix things that need improving like moving from the FIRSt built robot control system to the Pbasic IFI system and then making the change to the C IFI system. Each one of those changes was big and they had their problems but the structure was there to overcome. I have no idea what they are looking at or who would build it I just know that change can cause unwarranted problems. I have faith that whatever gets built will work and the community will adapt, I just hope that the changes are being made for the correct reasons like improving technology or making things easier for teams and not fed by other private agendas.

As for your quote about technology egos, without context it doesn't really seem to apply to this situation unless you have some other information about a new control system you would like to share.

Qbranch

14-05-2007, 12:22

Zigbee? Zigbee wasn't designed for bandwidth - The 802.15.4 bit rates are specifically limited to 250Kbps compared to 1Mbps for Bluetooth. I personally would prefer wireless 802.11[n/g] for everything, if power was not a concern.

uhm... right now we're at 19200baud on the first control system... thats 19.2Kbps... I'd rather take the stability of Zigbee at a speed thats already 13 times faster than what we're using now... not to mention to actually use all the bandwidth of 802.11n/g you'll be using most your processor just to do communications...

At the place where I work, we use some MaxStream ZigBee chip modems to link our plant AGVs together, and as of yet the system has proved flawless and the range excellent, in the 250' x 250' steel-constructed factory they can still communicate with eachother at extremely low (often no) packet drop rates.

Anybody have any other suggestions on radio systems that would be interesting? I know that theres more out there than just Zigbee and the 802.11x standards... any other suggestions?

-q

Bharat Nain

14-05-2007, 12:24

I have to agree with what Dave and Greg said. This is a huge step on the part of FIRST. I wish IFI communicated with us earlier when they had the 8.3/8.2v bug and the radio problems so teams like us were not wondering if something was wrong with our code. All this was a result of a version 1.0 as mentioned above. I hope FIRST puts in a lot of time and effort into pre-testing the new control system. There are more than enough off-season competitions through out the continent for this to be tested. The hardest part of accepting a new control system is their familiarity with FIRST. IFI has been a very long time partner and they know the way FIRST works and its requirements. I hope we know who the new vendor is and I hope they attend many competitions next year to understand what is required. Version 1.0 of the new control system should be 2007-2008 off-seasons so by the time the season rolls around, a lot of the bugs are worked out and there is considerable amount of experience among FIRST teams. Like many others, I will not be happy if we have to deal with a very buggy system in the 2009 season. I am sure FIRST realizes this but I hope they take appropriate steps to ensure this wont happen. At the championship, we were told there will be increased communication between FIRST and teams, so we should get updates as this progresses.

Eldarion

14-05-2007, 12:48

Actually, I kind of like the idea of having a 802.11x transceiver on each robot. It would open up some interesting possibilities as each robot could now communicate not only to the arena controller, but to the other robots on its alliance. Can you imagine the autonomous mode possibilities? :ahh:

chaoticprout

14-05-2007, 12:52

This completely awesome, and the only thing I'm bummed about is that I won't see it as a High School student, graduating in 2008.

JesseK

14-05-2007, 13:05

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.

Rich Kressly

14-05-2007, 13:15

The hardest part of accepting a new control system is their familiarity with FIRST. IFI has been a very long time partner and they know the way FIRST works and its requirements. I hope we know who the new vendor is and I hope they attend many competitions next year to understand what is required.

...and here's where my real concern is too. If and I repeat "IF" (becuase we've had no official word) IFI is not the developer or involved in the new system:
1. How well will the new vendor know FIRST? While it's fair to give people time to get up to speed, does anyone really want to work their bottom off during the build and have things not work in competition?

2. How well will teams and volunteers be able to handle the multitude of potential issues that go along with the incredible flexibility we're talking about?

3.. Will the vendor be able to provide the same expert customer service that IFI has provided? A system expert on the ground at every regional from Wed night through Saturday (even when there are ten events in a week) and several at the Championship?

I'm all for new and better as long as it benefits teams and events, but I have very real concerns here.

Danny Diaz

14-05-2007, 13:35

...and here's where my real concern is too. If and I repeat "IF" (becuase we've had no official word) IFI is not the developer or involved in the new system.

Every bone in my body tells me this is something FIRST has already dealt with or is currently dealing with. You list a lot of good points, but realize that when you think of all the bad things that can happen (new vendor, support, etc...) there's at least 2 people at FIRST who have also thought of this. Changing technology is never an easy thing to do, it must be approached with caution - I think we should give FIRST the benefit of doubt in such areas.

-Danny

bcieslak

14-05-2007, 13:38

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

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.

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

BC

Roger

14-05-2007, 13:39

Since we're all putting our wish list items up, I just hope they make the board plugs and numbers a mite bit bigger so I can see the darn things. Good thing the kids are doing it because I certainly can't!

And upgrade from C to something like FORTRAN.

:D Okay, seriously, we can stay with C. Just as long as Kevin can understand it I'll try to keep up.

Joe Matt

14-05-2007, 13:42

lynca

14-05-2007, 13:58

Danny Diaz

14-05-2007, 14:32

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

14-05-2007, 14:36

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 (http://adambots.gotdns.com/cgi-bin/view/Main/CoProcessor) platform was a start in the right direction.

In terms of the actual hardware, Royal Assualt's (357) "Schubox" PCB (http://www.andersonrobotics.com/gallery2/main.php?g2_itemId=1388) 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

14-05-2007, 14:47

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

14-05-2007, 15:29

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

14-05-2007, 15:34

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

Jacob

marccenter

14-05-2007, 15:38

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

14-05-2007, 15:43

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

14-05-2007, 15:54

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

14-05-2007, 15:55

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

14-05-2007, 16:00

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

14-05-2007, 16:07

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

14-05-2007, 16:25

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

14-05-2007, 16:46

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

14-05-2007, 16:47

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?

tseres

14-05-2007, 16:53

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.

Dave Flowerday

14-05-2007, 16:58

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! :p

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

artdutra04

14-05-2007, 17:06

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

14-05-2007, 17:39

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.

Schnabel

14-05-2007, 17:42

I wonder if a form of blue tooth is going to be used since the technology is all ready there and has been used for a few years.

Danny Diaz

14-05-2007, 17:47

I'd love to see a control system in which all of the processing is done on the OI by a laptop...

I dunno about that completely. I would love to see the OI end of things be done on a laptop and a "custom circuit" you'd use with the laptop. That way you could go REALLY crazy with your user control station, and use things you previously weren't allowed to do or that you couldn't do easily. I can easily imagine being able to perform TONS of pre-processing on the laptop before the data gets sent down to the robot controller, and then perform post-processing before data is sent to the screen (like we do now with a LabVIEW dashboard). Yeah, I can dig that.

I'll go on record saying I don't like the idea of a laptop, however, and let me tell you why. How many times have you installed software onto your [windows] laptop and have it become extremely unstable? Have you ever accidentally dropped your laptop? I can think of about 100 reasons why a laptop is probably worse for these kinds of scenarios just because of reliability. And will the laptop stand up to issues of reuse? <sigh>

But I think it's a cool concept.

-Danny

Danny Diaz

14-05-2007, 17:59

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 (http://www.ddj.com/184411097) makes for a VERY interesting read.

-Danny

ZZII 527

14-05-2007, 18:06

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.

Could somebody please fill me in on what IFI is doing in Boston? I'd love to see it.

Also, since I originally speculated on the laptop situation, I feel I should temper that suggestion a bit - I don't see it as a really great option namely because of the durability, not the cost. The cost of the current OI is ~$350. Add on the radio modem and some chicklets, all of which aren't necessarily needed with a laptop/wireless solution, and you can get into the price range of a low-end model, which is all we would need. (Yes, I know the chicklets aren't in the kit cost now.) But I would agree that its durability would be questionable, given the amount of abuse laptops seem to take at competitions. OI processing is a cool concept, though. Maybe the RC does real-time sensor-type stuff and the OI does game strategy-type stuff.

It's fun hearing everyone's interesting ideas. No need to shoot down ideas in this thread - I think they all have some merit.

Karthik

14-05-2007, 18:09

I'm glad FIRST is getting a head start on this, even still, I'm worried that this timeline is too tight. 20 months of development time on a project of this nature is not much at all. Consider that the 2007 IFI radios were under development for over two years. Many of you may recall that they began field testing a revision of these radios at IRI in 2005.

The control system is the make or break part of the FRC. Before joining FIRST, I was part of a competition that had many control system issues. The result was a competition that very unprofessional and definitely uninspiring. Let's hope that the migration to a new system doesn't lead us down this road.

Rob2713g

14-05-2007, 18:18

vivek16

14-05-2007, 19:49

i think visual basic, C, and java are pretty much the most widely used programming languages. our school stopped teaching C :( . but visual basic and java are taught. although C is a very powerful i think others are becoming more popular.

vivek

BornaE

14-05-2007, 20:38

I would love it if we had event programming like visual basic than a loop

Richard Wallace

14-05-2007, 21:20

During the Championships, there was a team who was testing something wirelessly on the Newton half of the practice field. We were on the Galileo half and were told by the practice field operator that they were testing something new and that it was a unusual for this to happen. Unfortunately, I did not check which team it was. I believe it happened on Saturday morning. Anyone know what team this was and what they were testing? It seems like they could have been testing something related to this new system.I was the practice field operator you recall. The team being 'tested' by IFI was the (More) Martians (70). The IFI guys were trying to diagnose a radio related problem, and as you know radio operation is generally not allowed in the pits. You'd have to ask the (More) Martians if IFI ever figured out their problem.

That test had nothing to do with the new robot control system we are discussing here.

Not2B

14-05-2007, 21:38

As anyone taken a look at this?
http://www.terk.ri.cmu.edu/
It's a telepresence robot, you run it over WiFi off your laptop. So far, cool, but so what...

It's sponsored by Google.
It's sponsored by Microsoft.
It's sponsored by Intel.
It's run by Carnegie Mellon Univeristy (CMU)

I don't know. I'm a mechanical guy - but it seems cool to me.

Adam Y.

14-05-2007, 21:41

Could somebody please fill me in on what IFI is doing in Boston? I'd love to see it.

Also, since I originally speculated on the laptop situation, I feel I should temper that suggestion a bit - I don't see it as a really great option namely because of the durability, not the cost. The cost of the current OI is ~$350. Add on the radio modem and some chicklets, all of which aren't necessarily needed with a laptop/wireless solution, and you can get into the price range of a low-end model, which is all we would need. (Yes, I know the chicklets aren't in the kit cost now.) But I would agree that its durability would be questionable, given the amount of abuse laptops seem to take at competitions. OI processing is a cool concept, though. Maybe the RC does real-time sensor-type stuff and the OI does game strategy-type stuff.

It's fun hearing everyone's interesting ideas. No need to shoot down ideas in this thread - I think they all have some merit.
It's a robotics convention/conference. It's more bussiness related than anything. Soemeone from IFI is giving a talk about the market for educational robotics.

Salik Syed

14-05-2007, 21:49

I am excited. As a programmer it was frustrating to deal with low level stuff that didn't really matter to me. Hopefully this new system will allow programmers to tackle problems that are actually algorithmically interesting. I'm all for the higher level stuff.

In fact an added layer of abstraction between hardware and software would be beneficial for all teams regardless of skill level... having a more powerful environment would allow for more options to veterans, and an easier interface for rookies.
I don't think everyone needs multi-threading support for a Robot ... but the option of having having advanced features like it is a good thing. I know we had to do our own super simplistic psuedo-threading during autonomous.

The only real necessity is that we use this added power to make things easier... Please don't make it like windows programming or Direct X. A set of library functions and a very simplistic interface for programming would be nice for newbies.

It'd be awesome if we could hook up our robot to a windows laptop style interface. They could even provide software for building simulated robots so we didn't have to wait on the actual robot all the time. It honestly wouldn't be ridiculously hard to do... a simple physics model, constraints tool and a library of sensors/components.

Furthermore I would like to see a kit-bot which comes with more sensor integration... i.e a kitbot which anyone can throw together that will give you shaft-encoders, gyro and camera. With this should be included simple library functions for driving, turning tracking. Then we could actually do something a bit more interesting in autonomous. Right now most of autonomous is writing low-level stuff that should be library code. Moving an arm to a position isn't hard ... it's just tedious

MikeDubreuil

14-05-2007, 21:55

My 2 cents...

I would lose confidence in FIRST management if they moved away from IFI. Technically speaking, we could not be where we are today without IFI. I can think of zero reason to move away from IFI's hardware. Their Spike and Victor are considered top of the line components in the robotics arena. From my experience Zigbee isn't a good choice, 802.11 seems like overkill. I bet the new change looks something like this:

IFI creates the new OI and RC. Victors and Spikes are unchanged.
OI includes USB support.
RC includes a Microchip micro and some type of fast user processor, maybe even a DSP offering oodles of memory.

sanddrag

14-05-2007, 22:15

Chris Marra

14-05-2007, 22:27

I predict an absolute coordinate field positioning system in 2009. I mean, they give us a lot already, and not a lot of teams use it. Too many do-nothing auto modes. You gotta look at it like this: what are they are they gonna do to make it so easy that you have no excuse not to do it? That's now the FRC control system technology has been moving the past few years, and I bet for 09 it will take a big leap.
http://www.chiefdelphi.com/media/photos/26078
I'd love to see something like this implemented for teams. At the same time though, providing teams with a new dashboard capable of mimicing something like StangPS but for a kitbot frame with 4 encoders would be a HUGE step forward for enabling teams to compete in autonomous.

Eldarion

14-05-2007, 22:34

http://www.chiefdelphi.com/media/photos/26078
I'd love to see something like this implemented for teams. At the same time though, providing teams with a new dashboard capable of mimicing something like StangPS but for a kitbot frame with 4 encoders would be a HUGE step forward for enabling teams to compete in autonomous.

That brings up an interesting point. How many projects of the size and scope of that one are going to be affected by the RC change? I know mine will be affected somewhat, but can you imagine if someone got a perfect autonomous system (or AI...) completed that only ran off of the RC, and then the hardware (and possibly the programming language) changed underneath them? :ahh:

I'd be steamed! :)

Mark Pierce

15-05-2007, 09:18

I think it's great that we now know:

That 2008 will have a similar control to 2006 & 2007
That they are working on the next generation now.

I'd still like to see updated compiler and libraries for next year, but am really happy to see improvements coming. I've seen the evolution from the 1999, 2000-2001, and 2002-2003 Basic stamp based controllers to the 2004-2005 8450 controllers to the 2006-2008 8722 controller. This is the first time we've known this soon that change was coming. I hope we get the tools early enough to install on the school computers and have training sessions before the season starts. I hate trying to guide student programmers, install tools, and learn a new system's intricacies during build season.

My wish list includes (I really don't have time to prioritize these):

Easier sensor hardware interfacing (SPI and serial ports, encoder interfaces, etc.)
Better debugging tools and robot feedback. I've spent way too much time working around chip errors/compiler errors/communication glitches/Easy C quirks/etc.
Better connectors and wiring methods.
Libraries and tools to simplify programming

I hope that a some of us get a chance to provide input and help in the new system. I'd be happy to help test and develop libraries/training resources for the new system before the 2009 build season.

JaneYoung

15-05-2007, 10:27

I hope we get the tools early enough to install on the school computers and have training sessions before the season starts. I hate trying to guide student programmers, install tools, and learn a new systems intricacies during build season.

This aspect of experiencing a successful year is very important.
a. it helps mentors mentor
b. it helps students learn without added stress
c. everyone can work more efficiently

Cuog

15-05-2007, 11:32

I'm certainly excited about a new control system for 2009. Sadly I may not be on a team that year as I graduate in 2008, but mentoring sounds like fun:)

For me and I'd hope many out there a hardware change will bring about new and exciting possibilities. For me it really is about the adventure and not the end result, and I hope that these changes bring a new and exciting adventure. Whether they stay with IFI or not doesn't seem to be well addressed but I don't think it matters, if its IFI they will likely do as they always do and work closely with teams and come out with something great, if its not IFI then it will be another company that I am quite sure will do the same thing before FIRST would consider them for such an integral part of the robot designs. I certainly have faith that the many brilliant minds running FIRST will be able to pull this together.

Also I would like to point out to those worrying about time that build season is 6 weeks, or roughly two months because there is still work happening at competiions and on fix it windows etc. so FIRST has given itself the equivalent of 10 seasons to work this out. Just think of how much we accomplish in 10 seasons, I'm sure FIRST can do the same.

I think that a new processor with lots of power and options will be a great improvement. I would love to see something that can use graphical interfaces like EASYC to get a quick autonomous for those that want it, and still the option for the embedded linux people to "hard code" their own amazing systems. By giving so many options that it will be hard for any team to use them all I think FIRST will really open the door for better autonomous modes just because of the number of choices.

This may also be another chance for FIRST to level the field again. With the new system rookie teams and veteran teams will be pretty close to each other once again in terms of knowledge and it will encourage a LOT of cooperation among teams which was my favorite part about this year's game.

Andrew Schuetze

15-05-2007, 13:05

It's a robotics convention/conference. It's more bussiness related than anything. Soemeone from IFI is giving a talk about the market for educational robotics.

Here is the abstract from the conf. webpage (http://www.roboevent.com/rb2007_speakers.htm)

Robotics in the Classroom
- Jason Morrella -
Director of Development, Education and Competition
Innovation First

At Innovation First, Jason Morrella is helping to develop the Vex platform to meet the wide variety of demands and needs facing educators and the educational robotics market for middle schools, high schools and universities/colleges. Before joining Innovation First, Jason was a Regional Director for the FIRST Robotics organization covering the western United States. Jason has spent ten years working with educators and industry leaders to help schools build a foundation to develop and support robotics programs, and for communities to hold competitions for these schools to participate in. Before joining FIRST, Jason was a teacher and robotics coach in the San Jose Unified School District, where he was named Teacher of the Year for the 1998-1999 school year.

John Gutmann

16-05-2007, 19:45

:confused: What other languages could it be??? Java?? actual C++?? C#?? :confused:

That doesn't depend on the processor it depends on the compiler. I am sure if you looked hard enough you could find a compiler for the controller now that you can program in BASIC. I am sure they are going to pic a Processor that has alot of availible compilers. Which would force me to lean towards the AVR......or an ARM if they wanted us to have higher processing power. But for some reason I just don't think they would go for an ARM processor, I don't think it is neccesary. Basically anything you can do on a 32 bit ARM processor you can do on an 8 bit RISC processor it just takes more clock cyclesm and maybe additional hardware. I don't see any problem with sticking with an 8 bit system, I have seen 8 bit webservers, and USB systems, etc. I would put my money on a atmega128 or a atmega2560 both by atmel.

But then again, I may be a little biased.......;)

-John

Eldarion

16-05-2007, 20:07

That doesn't depend on the processor it depends on the compiler. I am sure if you looked hard enough you could find a compiler for the controller now that you can program in BASIC.

http://www.melabs.com/products/pbp.htm

:)

(No, I haven't used this product, as I happen to like C. But it was given good reviews by Nuts and Volts magazine)

ThomasP

17-05-2007, 02:28

Eldarion

17-05-2007, 02:49

"adaptability to a wider variety of programming languages"

Anyone else thinking .NET?

I think it's the most obvious choice, one control library for the bot and people get a choice of 3 different languages to program in.

Interpreted languages, or for that matter languages that require large library files to run compiled programs, are generally not suitable for embedded control. Simply put, it would require a small laptop in order to do a typical robot's tasks using Java, .NET, Visual Basic, or any other language of that type due to the increased runtime overhead, both in terms of the CPU and RAM.

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers! :)

Something like EasyC is different in that it actually reduces your high-level instructions to C and them compiles the resulting C code (correct me if I am wrong here!). If the current trends continue and no low-level access is required, then EasyC is probably the best solution to the programming problem.

There are two ways that you can utilize increased CPU speed or RAM storage:
1.) You can program as efficiently as you did on the smaller machine, and as a result the machine can do more tasks, or
2.) You can fill up the new resources with programming language "bloat", offering few new features and probably introducing many bugs!

Just my $0.02. :)

ThomasP

17-05-2007, 07:57

Interpreted languages, or for that matter languages that require large library files to run compiled programs, are generally not suitable for embedded control. Simply put, it would require a small laptop in order to do a typical robot's tasks using Java, .NET, Visual Basic, or any other language of that type due to the increased runtime overhead, both in terms of the CPU and RAM.

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers! :)

Something like EasyC is different in that it actually reduces your high-level instructions to C and them compiles the resulting C code (correct me if I am wrong here!). If the current trends continue and no low-level access is required, then EasyC is probably the best solution to the programming problem.

There are two ways that you can utilize increased CPU speed or RAM storage:
1.) You can program as efficiently as you did on the smaller machine, and as a result the machine can do more tasks, or
2.) You can fill up the new resources with programming language "bloat", offering few new features and probably introducing many bugs!

Just my $0.02. :)

They have a .NET Compact Framework, Java Micro Edition, etc... with more processing power and memory, the new RC could easily run one of the newer languages just as fast as the current RC runs C and then it will only get faster from there.

Qbranch

17-05-2007, 08:18

Still though... I'm sure the stack sizes (not to mention pertinent memory associated with the interpretive code executor, and all the processing overhead for that) are massive... probably far beyond what an embedded processor can handle. A blackfin or coldfire maybe, but...

<rant>

well to put it simply i like a low weight class for my software... a medium amount of hardware, light software, means fast execution. I'd rather have my quick and fast C than a big bulky processor running a whole ton of code I didnt write (means that it'll probably crash since its near impossible to debug their machine code)...

</rant>

well... maybe i'm old fasioned... just i've always found the close interatction with the hardware of the processor that assembly and C provide...

-q

mathking

17-05-2007, 13:59

The fewer layers of abstraction, the faster the program will run, with assembly language being the fastest. However, this speed increase is offset by increased development time. I believe a good compromise is reached in the C programming language, as do many other robot programmers! :)

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

Eldarion

17-05-2007, 14:25

Assembly is only faster if you write good assembly code, and you are smarter than the writer(s) of the compiler. A good compiler with a lot of optimization can take high level language code create object code which runs faster than most of the code student programmers could write in assembly. One reason C became the language of choice for embedded chips was the creation of specific compilers which allowed for small, fast code.

In my post I should have stated that I was referring to the old assembly gurus who could code circles around the C compilers. I would not expect students to be able to code to that level (I cant either! :o )

Bharat Nain

17-05-2007, 18:39

I have been thinking about this and if FIRST was not going to use the IFI processor, here is what I would do if I were FIRST:

1) Research the different ready-made processors available in the market.
2) Pick out everything that is decent and buy them
3) Vigorously test each processor in conditions that real competition would require
4) Research the company and determine if it is a work-able partnership.
5) Work out details with the partnering company to provide adequate supply and support for all FIRST teams.

There are a lot of other things to figure out such as speed controllers, spikes etc.

So, even though we have all our wishes of the type of processor and its features, I am sure FIRST is researching this in a planned manner and will determine what is best for our applications. We might not get what we expect or like, but hopefully it is what is best for us.

Storcky

17-05-2007, 19:10

Visual Basic and C are basic languages that most schools will teach (if they teach anything). Going too far afield with the language (C# or C++ comes to mind) will force quite a few folks to have to try and learn a new langauge. I don't think that would be in the best interest of the competition.

Our school only teaches Java (for the AP test). I had to learn C on the fly with our programming mentor.

tjcasser

18-05-2007, 09:10

Interpreted languages, or for that matter languages that require large library files to run compiled programs, are generally not suitable for embedded control. Simply put, it would require a small laptop in order to do a typical robot's tasks using Java, .NET, Visual Basic, or any other language of that type due to the increased runtime overhead, both in terms of the CPU and RAM.

They have a .NET Compact Framework, Java Micro Edition, etc... with more processing power and memory, the new RC could easily run one of the newer languages just as fast as the current RC runs C and then it will only get faster from there.

Just let me recap something I mentioned earlier in this thread, IIRC.

Having played with robots programed in Java last week, I can tell you that Java ME does work rather well when it comes to developing software for small, power constrained devices. (You actually use the same interfaces that you use for writing programs that run on a Java-enabled cellphone.) .Net CF has a slightly larger footprint, but it too likely could handle the processors that I imagine FIRST is looking at using in the post-2008 era.

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

mathking

18-05-2007, 10:50

When they say 'support for multiple languages', that smacks to me of a device that's capable of running an operating system in some fashion, rather than just a simple processor... so it's back to the whole wait-and-see...

I have been talking with some of our other mentors about this. I think that some sort of OS is the most likely alternative. The other possibility we see is a development environment which allows code from different languages to be compiled to processor readable object code.

I will also second the notion that Java has a number of features that do lend themselves to robot programming. In particular Java handles events and exceptions well. Just as a simple example, I made some code for the InteliBrain robot from Ridgesoft that uses the CMU cam and can find the FRC game light and move the robot to within 5 feet of it very quickly. If the Java code is used with an IDE that compiles the code efficiently, it will not be anything like Java byte codes. Something like xCode perhaps.

Steve W

18-05-2007, 20:20

This topic is less than 3 hours old and the Chief Delphi community is complianing already:

Let's not forget the 2007 radios! (No cell phones near the radio towers.)

I don't care who designed it, or who makes it, NO ONE makes anything perfect the first time, or for that matter everytime.

Lets disprove a new saying overherd at the VIP reception in Atlanta:
"FIRST - Technolgy building egos"

The process just started, give them a chance!

Gary F, the issue is that FIRST does not give us good products to start with. Such a major change is questionable. What is more questionable is what is not said. FIRST did not say tha "FIRST and ***** are designing a new controller" They did say that they are building a new controller, quote "We are pleased to announce we have begun development on a new Robot Control System". No other people mentioned. FIRST has told us many times that they are short staffed and how stretched they are. I question their ability to do justice to a new controller in such a short time frame. We do not need any more fiascoes!

I find it surprising that IFI did not make the announcement if they were the ones working on it. IFI has been the strongest point with FIRST suppliers. No one else has stepped up and made things run as well as IFI. I would hate to see them go.

One question that I do have, why are you quickly jumping on us for discussing? Are you involved with the new product?

Salik Syed

18-05-2007, 20:46

John Gutmann

18-05-2007, 21:14

Protronie

19-05-2007, 00:54

I have to say this topic has me scratching my head. I know just next to nothing about programing. My skills are in the nuts and bolts of things and quick fixes that get the job done.

I've been struggling to learn some C programing. Info here and from the young people I've work with have begun to help me understand programing.

I would hope that FIRST would take things slow and thoughtful before changing the programing languish .
I'm sure I'm not the only one that feels like a blind man in a room full of sharp objects when it comes to programing.

I would love something where all your would have to do is type:
Robot go forward 20 feet, turn right 90 degrees, go forward 10 feet, stop.
And it would do just that. :]

I know its a dream but its my dream so hey... ;)

Your never too old to learn new tricks, but some old dogs just take longer to learn them. :D

Well thats my 2 cents on this.

ThomasP

19-05-2007, 01:13

Where is have you thought about laptop size? the fragile LCD screen on it? Cost? a way to mount it. A operation system that will run without error, which means perfectly with a higher efficiency. This means no linux, no unix, no mac, no windows. they all get errors occasionally.

An embedded device is for more then controlling a microwave......there is is embedded devices in more things then you think. Cell phones and PDAs have said "embedded devices" in them. So if a PDA can have one why not a robot? If you give me a really good reason. I would certainly change my view on the subject, but until then I still think embedded is the way to go.

-John

Have you heard of cheap laptops? I went to Dell just now and saw laptop for $550, only $100 more than the current RC. If Dell became a sponsor, I'm sure they could knock another $100 off the price to match the other RC...

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.

Kevin Sevcik

19-05-2007, 02:40

Have you heard of cheap laptops? I went to Dell just now and saw laptop for $550, only $100 more than the current RC. If Dell became a sponsor, I'm sure they could knock another $100 off the price to match the other RC...

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.
Erm. The issue with slapping any random laptop on the robot is that it doesn't DO anything. Not by itself. Laptops have no way to communicate with remote joysticks or speed controllers or anything else. Don't think for a second that all the analog, digital, PWM, and special serial I/Os that we want are going to come cheap. That kind of hardware will run you atleast another $300. And that's not covering how the heck you talk to the joysticks.

Also, since when do we programmers start begging to get off easy? The mechanical side of things may have more motors and parts options than ever, but they still have to cram everything into the box and get it under weight. I think it'd be a bit unsporting if the programming side of the equation suddenly had effectively unlimited hardware resources.

Qbranch

19-05-2007, 16:26

...Don't think for a second that all the analog, digital, PWM, and special serial I/Os that we want are going to come cheap. That kind of hardware will run you atleast another $300. And that's not covering how the heck you talk to the joysticks...

...I think it'd be a bit unsporting if the programming side of the equation suddenly had effectively unlimited hardware resources.

I couldnt agree more. Just to reinforce, here's a sample price list of just SOME of the stuff you need to interface the CPU with a robot and a remote control pannel:

1) First, the previously mentioned laptop... $550

2) (1) NI DAQcard-DIO-24 card providing 24lines of digital i/o... NEARLY replaces the 16 digital i/o lines leaving 8 lines of I/O left for pwm... $199

3) (1) NI DAQcard-6024E card providing 16lines analog input and 8 lines digital i/o (to replace remaining 8 pwm pins)... $699

4) (opt) To get all the nice brought out pins the FIRST controller has, you'll need a breakout board, two of them, for a total of... $300

5) (2) USB->Serial converters, one for TTL port to a vision system or other peripheral, one for communication with the radio... $20

6) (2) XBee-PKG-R RS-232 Radio Modems for communication between the robot and the operator interface... $218

7) (1) PICDEM HPC Explorer board to make your own Operator Interface... $59

8) (opt) PC board for breakout of pins from the HPC board to your joysticks n such (optional if you want to make your board look nice)... $20~50

Provided you have your own joysticks and everything, this brings the sum total of this control system to $2065 as opposed to the current control system's price of $1147. I might also add that the components listed above would also need a safe haven in which to rest within the robot, which would add a large amount of weight and fabrication time to robot designs.

Well... that was a fun research project.

C code just because it's lower level doesnt mean it's bad, it just means it lets you operate closer to the actual control hardware than other programming languages. Also, I'd rather have a controller that weighs less than a pound and takes up very little space than a laptop which weighs several pounds and takes up a lot of space. Plus, the premade IFI operator interface pannel makes constructing an OI pannel a whole lot simpler.

Have a good weekend folks,

-q

BrianBSL

19-05-2007, 19:09

I don't see what the big need for an "embedded device" is ... why limit our selves to using chips that were designed for controlling microwaves? The way I see it the only thing these types of chips should be doing is communicating low-level data -- PWM values, sensor inputs etc.

It makes sense to use these chips if you have a very small robot or a flying robot that cannot wirelessly communicate to a master processor, and needs a computer which is light weight and low on power consumption. The robots we build for FIRST do not fall into this category. We can slap a laptop onto a FIRST bot very easily ...2-3 lbs extra is marginal, battery consumption is also very low.
It would be nice to be able to do more object oriented programming instead of having to deal with simple low level constructs. It would open a whole new world of possibilities.

I know others have covered this, but I absolutely cringe at the prospect of a general purpose PC as the primary robot controller.

By embedded controllers, no one means 8051's to control microwaves, we're talking about Xscales and such that run your pocket pc phones and DSP's that run your TV's and digital cable boxes. We're talking about full size ARM/DSP/etc 32-bit processors which are designed for embedded systems and not general purpose computing, which is exactly what we need. We don't need video, we don't need IDE, chances are we don't even need a PCI bus, which on a x86 system require external northbridge and southbridge controllers which are just excess. In addition, the price on them is far more than necessary for our platform, and they typically have a much shorter lifecycle than embedded microprocessors. What happens 4 years after the launch when Intel has EOL'd or obsoleted the chip that was chosen? We're stuck modifying the system in some way to support whatever we can get. Not to mention the fact that they often lack GPIO and extensive external interrupts, as well as other things that are 100% necessary for our application. Nor do we want to have to worry about some fancy DC-DC system to provide 4 different voltages to stuff.

And, I've never found that we have 2-3lbs to spare to put a full size x86 system on our robots. In addition - embedded doesn't have to mean small, battery powered, low current consuming devices. I have some cards at work with what would be considered "embedded" processors on them that will far outperform an equal cost x86 system.

Just because it is what you are familiar with doesn't mean its the right tool for the job - luckily, hopefully, FIRST will have a team (IFI or someone else, who knows at this point) that can handle it, and we will adopt to whatever they come up with.

And as far as cost - just because Dells sells laptops for $500 (which is cheaper than the current IFI robot controller) doesn't mean thats what an integrated system costs. The two microprocessors on the RC cost no more than $40 total - when bought as single units (and get deeply discounted by bulk purchase, as well as the fact that Microchip might be kicking something in). I'd estimate the whole board has $100 of parts to it. There's some serious markup here, as there is some serious support and R&D that goes into it.

P.S. - I think my cell phone runs code a bit higher up than C... and I know it runs Java.
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.

Salik Syed

19-05-2007, 20:58

BrianBSL

19-05-2007, 21:11

Well I'm saying why not build an interface for transferring data between a x86 type system and a low-level controller such as a PIC. Then we could easily build libraries to program via any language we wanted.

I think it'd be a lot easier to debug software problems when we can run development tools straight on the processor. Having an embedded device without extensive debug tools would be a nightmare. With a PC type controller I could run 3rd party debugging tools straight on the robot and know exactly why my code doesn't work. All that is necessary is driver libraries written for a few different languages.

Also what about external 3rd party libraries written for desktop PCs? Do you think they will port over seamlessly to your embedded processor? What if I want to run some complex image processing or motion planning ... how do I do that without modifying code that was probably written only to work with a limited set of hardware (A PC!)?

Embedded devices are nice for 3 reasons: low cost, light weight and portability. If we look at ease of use and flexibility the fact is that PCs win hands down. Cost is certainly a factor, but we are not mass producing these robots and selling them so a few bucks really doesn't matter much, nor do our robots need anything tiny and lightweight to fit in a phone.
Except they aren't. They have bloat because they are designed for general purpose computing. Those 3 reasons apply to some embedded systems, but there are many high end embedded devices that don't fit those 3 reasons once so ever, and are used because they provide enhanced performance for the specific application, whereas a PC is designed to provide general purpose performance, and not for a specific application. We know our application, and therefore a general purpose solution is not optimal.

Adding a PIC to a PC only solves some of the problems with the current system - the lack of performance for complex algorithms and floating point math. However, it doesn't enhance the lack of serial IO for multiple sensors (no user accessible TWI, for example), nor the lack of vectored prioritized interrupts, among other things.

And cost certainly is a factor, no matter what you say. When you start with $300 in hardware, WITHOUT ANY GPIO, then you have a problem. Remember, right now we are starting with $40 in hardware, that already has GPIO. Do we really want a $1000+ robot controller?

What time of image processing algorithm isn't designed as a library or provided as source code that will compile with anything? It shouldn't be hardware dependent at all.

And as far as debugging, any real system would have a JTAG port or similar functionality. Plus with a RTOS you should be able to have serial console or other similar access. I don't really understand what a general purpose pc adds. Thousands of engineers every day work on controllers designed to do similar things to our robots, and very very few of them use PC's as the controller for it.

I'll say it once again, x86 is not the solution. Just because it is what you are familiar with doesn't mean it is the best solution. Everyone will stick with what they know being the only possible/best solution, but in this case it isn't.

Eldarion

19-05-2007, 21:14

I say everyone should get an FPGA and program in Verilog! :rolleyes:
They are so much more powerful than general-purpose computers...

Qbranch

19-05-2007, 21:37

I say everyone should get an FPGA and program in Verilog! :rolleyes:
They are so much more powerful than general-purpose computers...

Yeah but you've been working with them to make your vision system for a long time!

Have to say though... the power and the parallel processing capability of FPGA's is enticing... though i've herd the compilers for FPGA's as well as the hardware itself is extremely expensive, little out of the range of most of us unless its for a 'real' project not a fun project.

Anyhow, the possibilities are interesting... :ahh:

-q

BrianBSL

19-05-2007, 21:42

Yeah but you've been working with them to make your vision system for a long time!

Have to say though... the power and the parallel processing capability of FPGA's is enticing... though i've herd the compilers for FPGA's as well as the hardware itself is extremely expensive, little out of the range of most of us unless its for a 'real' project not a fun project.

Anyhow, the possibilities are interesting... :ahh:

-q
Most FPGA companies have a soft-core microprocessor solution for it. Xilinx has the MicroBlaze, with hard-core PowerPC's on some of their FPGA's. Some pre-synthesized "master code" could be provided as the hardware description for part of the design (including the motor IO), and then teams could optionally add digital logic as necessary, or use the pre-provided logic. Then, they could program flash directly that would hold the microprocessor code. Pretty much, this allows them to ignore the digital logic part and just use the microprocessor if they would like, or have the ability to add digital logic to the FPGA itself. Cost is an issue, however. For example Xilinx's EDK sells for $1000 or so - although if you only needed their SDK (just a port of eclipse) and gcc, it may be significantly less.

artdutra04

19-05-2007, 23:03

...We can slap a laptop onto a FIRST bot very easily ...2-3 lbs extra is marginal, battery consumption is also very low...I'm sure the hard drive would love all those high gee impacts. :rolleyes:

Eldarion

20-05-2007, 00:39

Yeah but you've been working with them to make your vision system for a long time!

Have to say though... the power and the parallel processing capability of FPGA's is enticing... though i've herd the compilers for FPGA's as well as the hardware itself is extremely expensive, little out of the range of most of us unless its for a 'real' project not a fun project.

Anyhow, the possibilities are interesting... :ahh:

-q

Actually, that is the same misconception that prevented me from working with these powerful little buggers for quite a while. :)

The software (compiler, IDE, etc.) is completely free (download the Xilinx WebPack). The development board that I am using for my vision system is "only" $150, and comes with a programming cable and power supply.
EDIT: If you don't need as many gates as I did (you probably won't) you can get the same kit for $99. That's less than the cost of a microcontroller development kit and compiler! :ahh:

So , on the contrary, they *can* be used for fun projects... :evil laugh:

Adam Y.

20-05-2007, 00:39

The "little dog" robot has an embedded processor only for motor control and PID on the joints. They connect it wirelessly to their workstations (running Solaris) to do the actual computations and decision making. The roboticists need ease of use and flexibility ... PC based processors provide that. You have easier debug support and an almost infinite collection of library software at your finger tips.Thats really nice and all but rapid experimentation is the only purpose to little dog. In fact from what I understand the information gathered from Little Dog is ported into Big Dog. I honestly doubt that Big Dog is running a traditional computer.

Alan Anderson

20-05-2007, 00:52

...I would love something where all your would have to do is type:
Robot go forward 20 feet, turn right 90 degrees, go forward 10 feet, stop.
And it would do just that. :]

I know its a dream but its my dream so hey... ;)

I helped develop an autonomous scripting system for our 2005 and 2006 robots that does exactly what you're dreaming of. We didn't use it this year because it seemed more important to make everything driven by camera feedback instead of by a prewritten script.

If things go well in our off-season software training this fall, I'll consider polishing it up for publication here.

ThomasP

20-05-2007, 01:26

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.

BrianBSL

20-05-2007, 09:28

Actually, that is the same misconception that prevented me from working with these powerful little buggers for quite a while. :)

The software (compiler, IDE, etc.) is completely free (download the Xilinx WebPack). The development board that I am using for my vision system is "only" $150, and comes with a programming cable and power supply.
EDIT: If you don't need as many gates as I did (you probably won't) you can get the same kit for $99. That's less than the cost of a microcontroller development kit and compiler! :ahh:

So , on the contrary, they *can* be used for fun projects... :evil laugh:
Yes - I own both the Spartan 3 and Spartan 3E dev boards (although my Spartan 3 is currently non-functional, thanks to me accidentally putting 12V at an IO). The 3E would be a very capable starting point as it can easily hold a MicroBlaze and plenty of other logic, and has the SPI A/D etc. I had considered developing an interface to one of these for our robot this year, but there simply wasn't a need for it with autonomous being so worthless. The Virtex 2 Pro and Virtex 4 boards with the built in PowerPC's are quite out of our reach as far as price, however.

As far as the cost of software - the synthesis tools (ISE webpack) and simple simulation tools (the free ModelSim) are free. However, the EDK - which lets you setup the microprocessor inside the FPGA (includes the logic for the MicroBlaze and the stuff to setup the PowerPC) is expensive ($1000). I think that would be a necessary part of any FPGA system for a robot controller, as writing your autonomous in Verilog or VHDL would just be a pain, not to mention the synthesis time, whereas 64+ megs of DDR memory and plenty of flash memory with an Eclipse SDK and gcc and g++ would be a welcomed change. I've had 20+ min synthesis times on a Virtex 2 Pro project I was working on, which I simply don't think will work for FIRST applications.

Eldarion

20-05-2007, 13:12

As far as the cost of software - the synthesis tools (ISE webpack) and simple simulation tools (the free ModelSim) are free. However, the EDK - which lets you setup the microprocessor inside the FPGA (includes the logic for the MicroBlaze and the stuff to setup the PowerPC) is expensive ($1000). I think that would be a necessary part of any FPGA system for a robot controller, as writing your autonomous in Verilog or VHDL would just be a pain, not to mention the synthesis time, whereas 64+ megs of DDR memory and plenty of flash memory with an Eclipse SDK and gcc and g++ would be a welcomed change. I've had 20+ min synthesis times on a Virtex 2 Pro project I was working on, which I simply don't think will work for FIRST applications.

I agree with the need for an embedded microcontroller. I wonder if any of the open-source ones listed on this page might do? http://www.opencores.org/browse.cgi/by_category

Qbranch

20-05-2007, 16:21

I helped develop an autonomous scripting system for our 2005 and 2006 robots that does exactly what you're dreaming of. We didn't use it this year because it seemed more important to make everything driven by camera feedback instead of by a prewritten script.

If things go well in our off-season software training this fall, I'll consider polishing it up for publication here.

Ditto. Team 1024's programming group calls ours RALFF... even has a (slightly unstable :o ) GUI compainion software that allows easy compilation of autonomous scripts by anybody on the team. RALFF was installed on this year's robot however its sensors never worked so it didnt show off like many saw on our amazing 2006 autonomous modes...

I'll have to write a whitepaper on scripting languages sometime... ehh... sometime... :rolleyes:

And eh, again, on the whole x86 based robot controller thing... to make it work (and no, the HDD would NEVER take the g's)... you'd need a heck of alot of hardware... see previous post for an estimate. (http://www.chiefdelphi.com/forums/showpost.php?p=627995&postcount=88)

-q

Salik Syed

20-05-2007, 19:28

Thats really nice and all but rapid experimentation is the only purpose to little dog. In fact from what I understand the information gathered from Little Dog is ported into Big Dog. I honestly doubt that Big Dog is running a traditional computer.

What do you mean by ported into Big Dog? A robot can be used for many things... what you are speaking of is probably a single application that the little dog robot is used for. There are many different universities using the Little dog for very different research goals.

What they are doing at the AI lab is trying to create a knowledge model which allows multi-legged robots to traverse extremely complex terrains. The robot literally learns how to walk across different surfaces as it tries over and over (and often fails) to cross a certain type of surface. For this type of computation they most certainly DO use a traditional workstation for computation. Of course if we were to have an actual military robot or something an embedded processor would be the right choice ... but for experimentation it's easier (for them) to work on a computer.

In response to BrianBSL
Actually when I was talking about cost, I meant for an interface... Users would provide their own PCs so it wouldn't "really" be part of the cost ... everyone has access to a PC or Mac all that is necessary is the right hardware and interface software to make it communicate with a robot.

And now that I look into it more I can see where you are coming from... I still feel like it's not as black and white as you make it because we are still limited by tools that are compatible with the embedded chip.

I don't have much experience with embedded chips...So I think I should probably learn more about them before I say anything else.
Say I wanted to run some Python code to control my robot wouldn't I have to port the source code of the interpreter to work on the embedded chip... ?? Would this be an easier task then writing code to let us have access to the hardware interface?

BrianBSL

20-05-2007, 23:17

Say I wanted to run some Python code to control my robot wouldn't I have to port the source code of the interpreter to work on the embedded chip... ?? Would this be an easier task then writing code to let us have access to the hardware interface?

You can run linux on many embedded processors, including the intel Xscale, so it would be as simple as compiling the Python interpreter for that chip.

Tom Line

21-05-2007, 08:30

Wow.

I'm always impressed with the level of technical knowledge that First folks have.

However, I sincerely hope that First does not go in many of the directions you guys are suggesting. Linux operating system? Math coprocessors? Different computer langauge? Multi-threading? What percentage of the world uses Linux? What percentage of the world knows how to deal with all the complicated options you guys are talking about?

Right now we have a very "simplistic" system. One that I would venture to guess that 90% of the teams couldn't get a camera, encoders, or potentiometers running without Kevin Watson's code or the appropriate Easy-C pre-coded libraries.

I've done C-Programming since high school 18 years ago. But holy-moly! I can't think of a single person I know (and I work in a manufacturing environment where I spend millions of dollars a year working with contractors) who has a sufficient level of hardware interface knowledge to be able to code things like interrupts etc. This is pretty specialized stuff folks - and it becomes even more so when you move away from a very common langauge to even more exotic options.

I would be very disappointed if First moved in a direction that basically threw out all the work that has been done to date. Our team would end up back in the stone age - turning PWM's on and off would be pretty much all we could do.

Golto

21-08-2007, 14:11

SgtMillhouse648

21-08-2007, 15:13

Actually, a good portion of the fisr community, myself included, use Linux. It is hailed for it's reliability. You're probably right about the camera thing there. But in all honesty, all you need a library compiled! And they would'nt be throwing out all the work. Nobody said anything about them abandoning C!

I know that the new PIC processors came out at IFI, I think that it's just an OI upgrade with a USB system.
To be honest, how do you know that a large amount of the first community uses linux? I know for a fact, only one person on our team uses linux, and he only uses it on the rare occasion that he cannot accomplish something easily in windows. Even with all of the help from kevin and the good folks at intelitek, at the midwest regional, there were only two teams that attempted to score during autonomous, and only one managed to score, and even then, we only scored five times out of the whole competition. If things change too much, teams will be left in the dust.
Just my $.02
Malhon

EHaskins

21-08-2007, 15:44

Dave Flowerday

21-08-2007, 15:49

Even with all of the help from kevin and the good folks at intelitek, at the midwest regional, there were only two teams that attempted to score during autonomous, and only one managed to score, and even then, we only scored five times out of the whole competition.
You are incorrectly assuming that the other teams did not attempt because they were not able to and/or the problem was too hard. This is not the case - I can think of several teams at Midwest that I know are fully capable of completing an autonomous task like 2007's (and I'm sure there's many more than that which I am not thinking of at this time). I assume they (like us) decided that the autonomous payoff was not worth the investment and chose to spend their time/resources elsewhere. We chose to focus our software and electrical skills on making our robot easier to control for the operators. In the end, we feel we made the right decision.

SgtMillhouse648

21-08-2007, 16:28

You are incorrectly assuming that the other teams did not attempt because they were not able to and/or the problem was too hard. This is not the case - I can think of several teams at Midwest that I know are fully capable of completing an autonomous task like 2007's (and I'm sure there's many more than that which I am not thinking of at this time). I assume they (like us) decided that the autonomous payoff was not worth the investment and chose to spend their time/resources elsewhere. We chose to focus our software and electrical skills on making our robot easier to control for the operators. In the end, we feel we made the right decision.
And you did an excellent job at that, I am trying to say if FIRST switched over to a completely different control system, that it would make it much harder to accomplish things as fast as it would be with the current control system. To the best of my knowlege, by West Michigan, the championship, and IRI, you're robot had excellent autonomous capabilities. Wouldn't it have been nice to have that in the beginning also? Thats all Im trying to say. If a completely new control system was brought into effect, with nothing similar to the current one, it could take much longer to get to where you could be had FIRST stuck with the current control system, in your case, maybe no autonomous, and the robot much harder to control.
Malhon

Alan Anderson

21-08-2007, 16:43

...I am trying to say if FIRST switched over to a completely different control system, that it would make it much harder to accomplish things as fast as it would be with the current control system....
If a completely new control system was brought into effect, with nothing similar to the current one, it could take much longer to get to where you could be had FIRST stuck with the current control system, in your case, maybe no autonomous, and the robot much harder to control.

I don't understand your reasoning. Different and difficult are not the same word. As a counterpoint to what you're trying to say, consider the significant change between 2003 and 2004's robot controllers. None of the previous PBASIC programming experience applied directly to the use of C in the new system, but the extra power of the new system made doing almost everything much easier. Algorithms remain intact even when the underlying architecture changes, and having more capability in the hardware yields more "breathing room" for fast implementation.

We also don't know how the 2009 control system will connect to the robot sensors and effectors, or how much will be taken care of by the hardware. It could very well be a lot easier to work with than this year's system.

Dave Flowerday

21-08-2007, 17:06

To the best of my knowlege, by West Michigan, the championship, and IRI, you're robot had excellent autonomous capabilities. Wouldn't it have been nice to have that in the beginning also?
You still missed my point. If we wanted it in the beginning we would have had it. The autonomous you saw at other events was implemented mostly in a single 5 hour fix-it window. The control system did not prevent us from implementing it before Midwest. We decided not to do it before then because it wasn't valuable enough, and we were right.
If a completely new control system was brought into effect, with nothing similar to the current one, it could take much longer to get to where you could be had FIRST stuck with the current control system, in your case, maybe no autonomous, and the robot much harder to control.
I agree this is a possibility, and frankly if the new control system does not permit us to at least choose to use C then I will be highly disappointed (however more language options would be fantastic). As long as the designers of the new system don't do anything really ill-advised (like requiring the use of Labview [ugh]) then we should be fine. Remember, the 2007 rules did not permit you to reuse software that you wrote from prior years, so you can't really make the argument that changing systems would force you to rewrite stuff since that was already true this year. Sure, Kevin's stuff would need to be replaced, but I'm sure he or someone else in the community would be right on top of that.

As empirical evidence, in 2003 we implemented this awesome little autonomous system that tracked our robot's position on the field and allowed us to literally draw out our autonomous routines in a GUI. It worked wonderfully, even course-correcting when other robots would bump into it. This system was written in PBASIC (with only 90 bytes of RAM and 16K of EEPROM!) and HC08 assembly. In 2004 they released the C-based controllers and we switched to C on our custom circuit as well. Re-implementing this system on the new setup was a breeze compared to doing it in PBASIC and allowed us to do many new things that we couldn't before. In 2003 there were only a handful of teams capable of something like that. Now, there are dozens of teams trying to recreate what we did back then. And many base their work on a presentation that we put together describing our 2003 system, which talks about the algorithms we used which are just as applicable today as they were in the days of PBASIC (see Alan's post above).

Gdeaver

21-08-2007, 20:58

Question? What would the First community think of going with something completely new , different and proprietary if the software company was flush with cash and in to sponsoring first in a big way. If First committed to their software platform. I'm talking about MSRS. Microsoft is already a sponsor and this year Will launch the Seattle regional. Would you sell your programming soul to MS if it meant lots of cash and support for the First program? I've recently had time to play with MSRS and believe it could take First into the future. There would be an enormous amount of development work but, the pay off in future growth and flexibility could be enormous. With MS's push into robotics and education I don't believe the marriage would be to hard to arrange. However, a divorce would be nasty.

Alan Anderson

21-08-2007, 21:54

Would you sell your programming soul to MS if it meant lots of cash and support for the First program? I've recently had time to play with MSRS and believe it could take First into the future.

Were it up to me, I would turn down that opportunity.

MS Robotics Studio is obviously very powerful. It provides a lot of infrastructure that makes programming act a lot like putting together a network of independent computers. It could very well be the way of the future. For a High School robotics program in the present of the early 21st Century, however, I think it might be a bit much to expect people to embrace.

From the very first tutorial, on detecting a bumper switch contact: "The simplest way to bind the service partner to your hardware is to start an additional manifest which contains the service contract(s) for your hardware."

Yeah, good luck not scaring off potential student programmers with that one. :rolleyes:

dlavery

22-08-2007, 00:19

Question? What would the First community think of going with something completely new , different and proprietary if the software company was flush with cash and in to sponsoring first in a big way.
...
Would you sell your programming soul to MS if it meant lots of cash and support for the First program?
There is a reason that FIRST does not accept sponsorship from liquor companies or tobacco companies. Desite the potential of considrable financial benefit, FIRST has recognized that those products are fundamentally inconsistent with programs involving underage, impressionable young minds. Those companies have cultivated a corporate culture designed to addict and corrupt the creative and innovative intellectual resources of the next generation. They destroy the human capital of the country for the sake of corporate profits.

So why should Microsoft be treated any differently?

.

Pavan Dave

22-08-2007, 09:07

There is a reason that FIRST does not accept sponsorship from liquor companies or tobacco companies. Desite the potential of considrable financial benefit, FIRST has recognized that those products are fundamentally inconsistent with programs involving underage, impressionable young minds. Those companies have cultivated a corporate culture designed to addict and corrupt the creative and innovative intellectual resources of the next generation. They destroy the human capital of the country for the sake of corporate profits.

So why should Microsoft be treated any differently?

.

Because Microsoft makes a load of money and 'support' education and own most people's software souls already. Alcohol companies and tobacco companies don't already have most of the souls of todays people, youth included.

You can't compare Philip Morris to Microsoft.

Pavan.

SgtMillhouse648

22-08-2007, 11:07

agreed 100%

Qbranch

22-08-2007, 11:44

I just like being the only software running on-chip... I have enough fun knowing what my own code is doing in the machine.... I don't need to add an operating system (that isn't mine) and umpteen more programmer's code from the O/S into the mix..... :ahh:

Just my 0.52 Rubles. ;)

-q

Greg Needel

22-08-2007, 12:39

Because Microsoft makes a load of money and 'support' education and own most people's software souls already. Alcohol companies and tobacco companies don't already have most of the souls of todays people, youth included.

You can't compare Philip Morris to Microsoft.

Pavan.

I beg to differ show me a statistic that says that more people have computers with windows then people who drink alcohol.

I think that alcohol companies represent a larger market share then Microsoft could ever accomplish. They also have many outreach programs. It is just a fact of life that when companies make loads of money they have to give some away.

I can understand FIRST's reasoning for not taking major partnerships with cigarette and alcohol due to the perception, but not taking on Microsoft for those same reasons is just a silly argument. Just because there is a portion of FIRST students and mentors who dislike Microsoft for whatever reason that a partnership with one of the largest tech companies in the world should be ignored.

Marc P.

22-08-2007, 13:47

I can understand FIRST's reasoning for not taking major partnerships with cigarette and alcohol due to the perception, but not taking on Microsoft for those same reasons is just a silly argument. Just because there is a portion of FIRST students and mentors who dislike Microsoft for whatever reason that a partnership with one of the largest tech companies in the world should be ignored.

Considering the history of how they became one of the largest tech companies in the world, I'm not so sure that's something FIRST students should look up to, considering the emphasis of gracious professionalism within the program.

Madison

22-08-2007, 14:16

Considering the history of how they became one of the largest tech companies in the world, I'm not so sure that's something FIRST students should look up to, considering the emphasis of gracious professionalism within the program.

Admittedly, I don't know very much about the history of the company -- but that said, I can't imagine that Microsoft has committed a corporate sin any worse than many of FIRST's other major sponsors. We're not exactly in the company of saints here.

Microsoft's employees have been an outstanding source of support for our team on many levels and we're really excited to see the company itself becoming more involved in FIRST and its programs.

Dave Flowerday

22-08-2007, 14:35

but that said, I can't imagine that Microsoft has committed a corporate sin any worse than many of FIRST's other major sponsors
I'm not so sure about that. Microsoft has been convicted for illegally abusing their monopoly in the US and European Union. They lied in court and were even caught red-handed forging video evidence to back up the lie. I'm sure many of FIRST's corporate sponsors have skeletons in their closets too, but these are some pretty serious "sins" from Microsoft.

Personally, I dislike them because I feel Microsoft is largely responsible for the opinion held by many in the world that software which malfunctions, crashes, doesn't do what it's supposed to, etc. is acceptable. I know many, many other companies contribute to this problem as well, but they're really the ones who convinced the public that this is OK. I don't think any other engineering discipline would tolerate the shoddiness that is often considered acceptable and standard practice in software engineering today. I actually had someone say to me once, "Office crashes on me a few times a week, so why should our product have to be any better than that?" That really ticked me off as an engineer.

Alan Anderson

22-08-2007, 15:16

...I can't imagine that Microsoft has committed a corporate sin any worse than many of FIRST's other major sponsors.

You don't need to invoke imagination. Their corporate sins are a matter of legal record (http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm). Only Enron and Standard Oil come to mind as having been more egregiously "corporate" to the exclusion of their customers' interests.

As with any large organization, the people who make up the company are usually much nicer and well-behaved on an individual basis than the combined entity is, but that doesn't change the legitimate distaste many people have for The Microsoft Corporation's behavior as a whole.

Richard Wallace

22-08-2007, 15:32

You don't need to invoke imagination. Their corporate sins are a matter of legal record (http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm). ....Wow! That's some record of corporate sins! The judge's finding begins

"These consolidated civil antitrust actions alleging violations of the Sherman Act, §§ 1 and 2, and various state statutes by the defendant Microsoft Corporation, were tried to the Court, sitting without a jury, between October 19, 1998, and June 24, 1999. The Court has considered the record evidence submitted by the parties, made determinations as to its relevancy and materiality, assessed the credibility of the testimony of the witnesses, both written and oral, and ascertained for its purposes the probative significance of the documentary and visual evidence presented. Upon the record before the Court as of July 28, 1999, at the close of the admission of evidence, pursuant to FED. R. CIV. P. 52(a), the Court finds the following facts to have been proved by a preponderance of the evidence."

and then continues for over 200 pages in the original document format! Jurists are reknowned for verbosity, but even so, 200 pages! :eek:

Madison

22-08-2007, 15:32

I created a new thread (http://www.chiefdelphi.com/forums/showthread.php?threadid=58519) that might be a better venue for discussing the extent to which corporate and personal behavior outside FIRST should impact involvement in the program -- as it appears that's where this discussion is headed. So, that said, please respond to the new thread if you'd like to talk more about that subject and here only if you're talking about the new control system.

Thanks. :)

(Or, y'know, privately message me with your objections and I'll go back to doing my job instead of reading CD. :) )

Fred Sayre

22-08-2007, 18:23

Personally, I dislike them because I feel Microsoft is largely responsible for the opinion held by many in the world that software which malfunctions, crashes, doesn't do what it's supposed to, etc. is acceptable.

I agree that this practice is avoidable but many people would choose not to make the sacrifice for that alternative. People still choose a PC that can work with thousands upon thousands of different hardware and software configurations and yet they will still criticize Microsoft for imperfect compatibility. If you lock down those configurations (like Apple) some people opt for that sacrifice of diversity and price for something a bit more reliable. Even when Microsoft seeks to fix these problems - like with user authentication controls, people complain endlessly. Unfortunately you can't expect everything from Microsoft and complain when they in actuality do a pretty good job at satisfying such a large and diverse group of users.

I would still rather have something that does what I want it to do - even if it crashes from time to time, than something that is incapable or too costly.

People buy devices that are made to work reliably and consistently - like video game consoles. More and more now though you find people altering them to run their own software and upgrade the hardware. This is can be risky, voiding warranties and putting reliability into question, but many people would still choose the freedom of having options with their devices.

Ryan Dognaux

23-08-2007, 14:09

I can understand FIRST's reasoning for not taking major partnerships with cigarette and alcohol due to the perception, but not taking on Microsoft for those same reasons is just a silly argument. Just because there is a portion of FIRST students and mentors who dislike Microsoft for whatever reason that a partnership with one of the largest tech companies in the world should be ignored.

FIRST is always wanting to reach every school in some way, that's always some part of Dean's homework. Teaming up with Microsoft could be one sure fire way to do it, so I don't know why anyone would reject that kind of support. Seems silly to me.

Pat McCarthy

10-09-2007, 23:37

There seems to have been a lot of discussion and passionate opinions expressed in this thread about the things desired in the new FRC control system.

I want to make sure that everyone who wants to give input about the control system does.
This thread (http://www.chiefdelphi.com/forums/showthread.php?threadid=58674) contains a link to an official FIRST survey that you can take to let FIRST know how you feel about the old control system and what needs to be improved upon in the new control system.

Not being directly involved with working on the control system when I was on a team, I can't really answer the questions on the survey. However, I want FIRST to get good results so they can make the best control system possible in the future. So please, programmers, electrical people, take a few minutes and take the survey and discuss the survey in that thread.

* Gets off soapbox *

teekon

12-09-2007, 22:40

Qbranch

13-09-2007, 11:16

-- What would be the pros and cons of having different languages like java and c++? I feel comfortable with just using c since thats all we have had so far and i dont really want to learn another language because then that puts me back this year. I think some upgrades on the motion board would be nice though! -- Teekon :)

I was also wondering if any one has tried programming their robot using LabView? -- Teekon

I think this might be going off track for this thread, but not sure what other related threads it might go with, so i'll just put it here...

I agree that its a good idea to stay with C... it works great for the application.

On your note about LabVIEW, I've used it before, its ok, but, its near impossible to document your code, EVERYTHING is passed by value, the 'code' (pictures) you make get really complicated to follow... but yes, i know the interaction it provides between various sensors, platforms and interfaces (the first thing i did with labVIEW in about 5 minutes from out of the box to application running was flip a switch hooked to a USBdaq, and it sends me an email saying "you hit the switch"), not to mention so simple its scary integration of extremely powerful vision processing.

Other than that, I can't see IFI/FIRST putting a processor big enough to run LabVIEW Embedded (http://www.ni.com/labview/microprocessor_sdk.htm). It only runs on 32bit processors like Blackfins, mot PowerPCs, mot ColdFires, etc. While the cost IS comming down for big 32bit dsp-type processors, i don't think its cheap enough yet to happen.

Cool idea though...

-q

p.s. In the defense of lab view... imagine having ONE OF THESE (http://sine.ni.com/nips/cds/view/p/lang/en/nid/12298) for a coprocessor!!!!!

Dung H Cao

22-09-2007, 21:05

BREAKING NEWS!!!

Today at Kettering Kick-Off competition's LabView workshop, an un-official revelation was announced to all workshop attendees that the new FRC controller will be the NI CompactRIO platform (http://www.ni.com/pac/crio.htm) and programming will be via LabView.

The official announcement should be out in about two weeks. Details are being developed for training and support for FIRST teams.

Kevin Sevcik

22-09-2007, 21:36

I am.... skeptical of this. I just priced out a very basic cRIO system that would barely provide similar outputs to the current RC. It was ~$2500. This is sans some sort of radio system and operator interface, plus you'd still need speed controllers and relays for the motors. The current system from IFI costs less than $1200. It... just doesn't seem very sensible from where I'm sitting at the moment. Nevermind that I wouldn't particularly look forward to programming a robot in straight Labview unless they're giving us the Statechart module and a lot of other fancy add-ons.

RyanN

23-09-2007, 01:06

I'm very sure that the new system will not cost over $2500 for just the controller. Obviously there is a high price on this equipment, but the actual cost of production is probably only $200 at most. Same with the IFI controller. Everything at IFI that they sell us are way overpriced, but they monopolize what we can buy, so they can charge us anything they want. Just a rough estimate of a Victor 884. I would say at most $30 of raw materials, the rest is profit.
Actual Cost of IFI control system with parts purchases individually:
RC: 449.95
OI: 349.95
Victor 884: 114.95 * 4 = 458.80
Spike: 34.95 * 4 = 139.80
PWM Cables: 4.99 * 12? = 49.88
RC Radio: 149.95
OI Radio: 149.95

Total: 1748.28

I would estimate actual material cost to be under $200 for everything.

My .02

Also, please don't bash me for my estimate, I'm thinking of it all as just plastic, silicone, copper, and alluminum. Of course you have add in customer service, and everything else.

jgannon

23-09-2007, 02:21

It was ~$2500. The current system from IFI costs less than $1200.
It's worth keeping in mind that the important number from FIRST's perspective isn't how much the system costs to a normal consumer, but rather how much it costs to FIRST. If we are in fact getting the cRIO, then it's safe to assume that NI is donating a good portion of the usual cost. Just hope that your students don't drop the thing once you've gotten it, though.
I wouldn't particularly look forward to programming a robot in straight Labview
Agreed. Though FIRST is about inspiration, and not technical learning, it's probably beneficial to use a language that students are likely to already know, and/or are likely to run into again in industry. BASIC, C, Java, and maybe even Python are all excellent examples... Labview isn't so much.

artdutra04

23-09-2007, 03:53

Last weekend I was driving by FIRST and I heard something about using 2,000 mailboxes in their latest control system.

You download code by sending it as an attachment (encoded in binary) to myrobot@new-uber-robot-controller-5000.ִ̣com, at which point an embedded speaker on the controller blurts out a "You've got Mail!" message load enough to be heard over even Blair and Grady on Einstein Field.

They've also pioneered a radical new power source for the controller, but that's still top secret until Krispy Kreme announces their new donut factory in Manchester, NH next week. But the most important thing to remember is that the new controller is not a big truck, that you just dump stuff on. It's a series of tubes (http://www.youtube.com/watch?v=EtOoQFa5ug8).