Goodbye IFI?

[Alan Anderson]

Originally Posted by Tim Delles

Now i do know that IFI employees do surf CD very often. Now not to put them on any spot or anything (they may not know of any plans that may exist with FIRST or the lack there of) but if you know anything can you please fill the FIRST community in on it.

The way things generally work in cases like this is simple: if you know something, you can't say it.

So keep in mind that if someone does say something, it usually means they don't know.

[JesseK]

This is all pure speculation, but it seems fairly logical to me:

I would assume that the move away from the IFI controller isn't simply a move away from IFI, it's a move away from the PIC 18F series of microcontrollers. I programmed an 18F452C in college, using assembly, and I promise you that it has multiple limitations many modern-day programmers would rather not deal with -- like no nesting, no recursion, and procedure/spaghetti-based coding practices. These are all based upon constructs that directly contradict what students and new mentors are taught in college about OOP, which is where high-level programming is these days. You also have to come up with extremely complex algorithms to have any optimised code currently, and it's not exactly easy to teach students Calc.-3/Linear Algebra concepts to a high school student who hasn't been through Algebra 2.

On top of that, some people may have missed the announcement of a NASA robotics platform that was released. While I have yet to review this platform myself it does seem like an easier way for NASA to use this robotics program to help create useful ideas/solutions while teaching the younger generation in the process. It makes sense that FIRST would move to a controller that has the capability to run this platform -- after all, NASA is a big funder of FIRST just like IFI.

------

If you were old enough to understand it, you might remember way back in the late 90's when the cable companies entered the internet arena. The phone companies were all in a panic and everyone was worried about a new standard of internet coming of age. Well in all actuality all it did was bring about competition to the phone companies since they were keeping the high-speed internet lines at equally high prices -- at which point the consumer was getting screwed. Cable changed all of that, and look -- we're about to be able to get 25Mbps here in DC, something that was unfathomable in the late 90's.

Competition is good, let's hope IFI can step up.

[Adam Y.]

I programmed an 18F452C in college, using assembly, and I promise you that it has multiple limitations many modern-day programmers would rather not deal with -- like no nesting, no recursion, and procedure/spaghetti-based coding practices. These are all based upon constructs that directly contradict what students and new mentors are taught in college about OOP, which is where high-level programming is these days.

The problem is that what you describe is a limitation of almost all of the embedded devices that compete with the PICs. Typically, programing techniques that won't cause problems on a computer will typically cause enormous problems in a microprocessor.

[steveg]

Originally Posted by Adam Y.

The problem is that what you describe is a limitation of almost all of the embedded devices that compete with the PICs. Typically, programing techniques that won't cause problems on a computer will typically cause enormous problems in a microprocessor.

While that's true to some extent, I will say that you don't necessarily need an object-oriented language to implement an object-oriented design. C++ and Java do include many features that encourage this style of design, but using MPLab and C (less so in assembly for obvious reasons), it's certainly do-able to have a clear object-oriented style to you code.

The main features of object-oriented design are encapsulation and data abstraction. This means that all of your functions that deal with a common set of data are grouped together and that some variables and functions are meant to be accessed from the outside in order to provide an interface, while others are to remain hidden behind the scenes.

In C++ and Java, classes make it very simple to perform encapsulation, and likewise public, protected, and private keywords make it very easy to abstract your variables and functions.

With an embedded controller, you don't have the overhead for these niceties. Your data encapsulation is done by using "typedef structs" and just by breaking you program up into multiple files. Instead of accessing variables directly, you create functions which access them. You will need pointers. You also need to keep track which functions are part of your interface, and which are lower level.

Here's a decent code example illustrating some of the concepts I'm talking about, in case i'm not making much sense.

Also, just to throw this out there, from a complexity point of view, it's generally considered better to find an iterative solution to a problem rather than a recursive solution.

[ahecht]

Originally Posted by KTorak

I only draw this conclusion with things such as; the new field software (no longer provided by Hatch), the new Banebot 'stuff', and other subtle changes that have been occurring over the past year or two.

That doesn't prove anything. Since 2003, there have been no less than 4 different companies providing field control. There have been 3 different main drive motors, and 4 kit transmissions. There have even been 4 different methods of alliance color identification (I still miss the police lights). Change is constant in FIRST.

[AdamHeard]

Originally Posted by ahecht

That doesn't prove anything. Since 2003, there have been no less than 4 different companies providing field control. There have been 3 different main drive motors, and 4 kit transmissions. There have even been 4 different methods of alliance color identification (I still miss the police lights). Change is constant in FIRST.

Exactly.

it's not even like the "Banebot 'stuff" was replacing anything that had been around a while; the kit gearbox it replaced had only been in for two years and before that drill gearboxes were given (I know they were in '04, any kit gearboxes before that are unknown to me).

[Doug G]

Originally Posted by JesseK

This is all pure speculation, but it seems fairly logical to me:

I would assume that the move away from the IFI controller isn't simply a move away from IFI, it's a move away from the PIC 18F series of microcontrollers. I programmed an 18F452C in college, using assembly, and I promise you that it has multiple limitations many modern-day programmers would rather not deal with -- like no nesting, no recursion, and procedure/spaghetti-based coding practices.

I'm not a software guy, but to say IF they move away from a PIC based system, does that mean moving away from Microchip products? If that's the case, I find this hard to believe with Steve Sanghi, President and CEO of Microchip, so integrally involved with FIRST, on the Board of FIRST, supplier, sponsor, etc...

[Kevin Sevcik]

Originally Posted by JesseK

You also have to come up with extremely complex algorithms to have any optimised code currently, and it's not exactly easy to teach students Calc.-3/Linear Algebra concepts to a high school student who hasn't been through Algebra 2.

Did I miss some new compilier developments in the last few years? Are they now parsing symbolic math into algorithms for us? Or automatically modelling our systems and designing control for them? I mean, really. The whole point of optimization is that you're, well, optimizing. A faster processor doesn't equate to instant optimization.

[Protronie]

Well I know this...
1. I don't like Microsoft or Billy Gates.
2. Something is a foot as Mr Holmes would say.
3. The FIRST powers that be seem to hide too many of their doings behind closed doors.
4. Change will come, and all the crying and complaining won't stop it.

So... either you give up or you deal with it.

[pufame]

Originally Posted by Protronie

Well I know this...

3. The FIRST powers that be seem to hide too many of their doings behind closed doors.

I doubt anyone at FIRST is doing anything "top secret". I mean they just have no real reason to announce any changes until everything is set in stone with whatever decision they made because it doesn't affect anyone in the general FIRST community until that time.

[Tazlikesrobots]

Has anyone considered that IFI controllers are the backbone of just about every major robotics competition (FRC, battlebots, etc.)? Why would FIRST walk away from such a great proven platform? Moving to a control system that has not proven itself in the battlefield does not make sense. If anything else it may be that IFI is working on a joint partnership with someone else to develop a new controller that will set the new standard for robot control.

Look at what IFI did with VEX. They partnered with with Revell (see article at http://www.botmag.com/articles/06-07-07_vexplorer.shtml ), renamed the kit to vexplorer, and judging from the pictures, new kit offers some great new componets!

My two cents.

[Dave Flowerday]

Originally Posted by Tazlikesrobots

Has anyone considered that IFI controllers are the backbone of just about every major robotics competition (FRC, battlebots, etc.)? Why would FIRST walk away from such a great proven platform? Moving to a control system that has not proven itself in the battlefield does not make sense.

FIRST has already announced that they are moving to new controllers in 2009. They haven't specified who they are partnering with for this yet, so perhaps it's still IFI, but either way they definitely are moving away from the proven platform. That particular piece of information is not speculation.

[RyanN]

Has anyone considered that FIRST may be moving to Parallax. If anyone remembers, the 2003 and older controllers used BASIC Stamp (I know until 2000, before that I'm not sure) which had a Parallax programmer. I just went to the Parallax website and found that they now have Transceivers that have the ability to control our robots. And recently they developed a new processor called the Propeller. It basically has 8 CPUs inside of it allowing it to multi task. I'm not sure of the programming language, but Parallax seems to have the right stuff for our robots. I will keep this in mine for the 2009 season, unfortunately I won't be in high school after 2008. This is just an idea, so I'm not saying that this is happening by anything I said, but it is a possibility.

[Andrew Schuetze]

Originally Posted by RyanN

Has anyone considered that FIRST may be moving to Parallax. If anyone remembers, the 2003 and older controllers used BASIC Stamp (I know until 2000, before that I'm not sure) which had a Parallax programmer. I just went to the Parallax website and found that they now have Transceivers that have the ability to control our robots. And recently they developed a new processor called the Propeller. It basically has 8 CPUs inside of it allowing it to multi task. I'm not sure of the programming language, but Parallax seems to have the right stuff for our robots. I will keep this in mine for the 2009 season, unfortunately I won't be in high school after 2008. This is just an idea, so I'm not saying that this is happening by anything I said, but it is a possibility.

There are a LOT of systems out there now days that FIRST may be considering. A system that I have mentioned before that is cool is the QWERK developed by charmed labs. The current version developed for CMUs Robotics Institute has all of the motor control built onto the interface so I would presume that the power for this system, as is, would not be sufficient for FIRST current draws by motors. Possibly such a system would have a daughter board add on that could handle larger currents off the board much as does the IFI system with the Victor SC and Spike Relays.

So I am in the anxious mode but I am content on waiting to hear something official from FIRST

[InnovationFirst]

We posted a response to many of the questions asked, and the issues raised in a new thread.

http://www.chiefdelphi.com/forums/sh...107#post633107

Regards,
Innovation First, Inc.