Spoiler: Could this be the new software for the FRC 2006?

[Chris_Elston]

CoreChart™FR is a flowchart like Graphical Icon Assembler designed for the popular FIRST Robotics Competition robotics controllers. Based on CoreChart Professional it simplifies the programming of the PIC18F8520 chips in the Innovation First Inc robotic controllers used by the competition. CoreChart underpins the highly successful University High School Industry Robotic Peer Mentoring Program for microchip Innovation Skills development.

Looks like CoreChart has been developed for the FRC.
http://www.elabtronics.com/Corechart...ple_Manual.pdf

Could mean easier programming in the 2006 season.

Anyone have any insight?
http://www.elabtronics.com/CoreChartFR.htm

Here is a link to a TRIAL download: (30 days)
http://www.elabtronics.com/CoreChartFR_Setup.zip

[MrToast]

Bah, where's the Mac version?

[dez250]

USE AT YOUR OWN RISK! This software has not been endorsed by either FIRST, IFI or Radio Shack Publicly to use on any of the products.

[rufu5]

This seems similar to the programming software for the Radioshack Vex kits. Its called "EasyC" and it makes the average school teacher or high school student a "programmer" in about 30 seconds. While this program is only in beta, I have gotten a chance to work with it (and gotten my hands on one of those nifty little orange programming boxes) and it is amazing. You simply pull a motor or sensor or if statement, etc from a box on the left into your "work area" and it creates a visual flowchart of the code you are creating.

It is great to see that there will be a full scale version of this for FRC robots as well. Makes my job about 1000x easier

[Gdeaver]

With out a default program its kind of useless for first. Wonder how the the master-slave would be handled. I didn't see any SPI subroutines. No pic C . Goes from graphic to assembler. Would be interesting if they duplicated the IFI effort and it was approved for competition.

[MikeDubreuil]

Originally Posted by Gdeaver

Would be interesting if they duplicated the IFI effort and it was approved for competition.

I don't see a reason why it has to be approved for competition. I thought IFI's stance always was if you modify the code and introduce a bug it's your problem, not theirs.
IFI put a built in safety mechanism. If your "user processor program" doesn't play nicely and behave the way the "master processor's program" wants you to it will shut off the outputs making your robot dead in the water.

[Chris_Elston]

This software has not been endorsed by either FIRST, IFI or Radio Shack Publicly to use on any of the products.

I think it could be "Endorsed" by FIRST. The title says " for FIRST" and it's got FIRST logos on the website. Seems to be they would have to gotten permission to endorse it...just my thoughts...

[CmptrGk]

If its really for an FRC bot, why are there pictures of a Vex bot on the page?

[Ryan M.]

Originally Posted by rufu5

You simply pull a motor or sensor or if statement, etc from a box on the left into your "work area" and it creates a visual flowchart of the code you are creating.

I haven't tried it out yet, so I'll ask:

It sounds similar in idea to the LEGO RIS default programming environment. Is it?

[Dave Scheck]

If in fact FIRST decides to go with this, and based on the information provided, it seems like there's a good chance that they will, I really hope that they don't require teams to use the program (which they probably won't).

While a tool like this can be very useful in teaching logic and program flow, it quickly becomes messy and hard to read when you start doing complex things.

Just look at the VEX Controller Examples on the page listed in the original post. Check out the example on page 16. Simply looking at the code makes it impossible to figure out what's going on. I look at the diagram and am immediately overwhelmed by a barrage of shapes and colors. The text on the symbols is useful for some things (like pwm01 = 40), but for others it is very non-helpful. "IF Zero"...are they saying "if(0)" or "if(somevariable == 0)", and if so, what is somevariable? They also use GOTOs, which can be incredibly confusing and are usually taught to be avoided at all costs.

In an example in the FRC examples on page 14, I look at their flowchart and understand what they're doing, but without reading their description, where does TEMP2 come from? It turns out that it is set in the Get_Analog_Value routine, but who would've guessed? Is it hard-coded that rc_ana_in1 gets assigned to TEMP2 or is that user definable?

Point is, it adds a layer of abstraction that makes the code harder to read. Does this mean that we'll have to compile twice? Once for the flowchart, then once again to compile the assembly into the IFI code skeleton?

I understand that the programming world is moving toward things like SDL and UML to autogenerate code, but there is still no substitute for learning how to write code for yourself. In fact, I contend that you are better off learning to program in a textual language then applying that knowledge to autogeneration. There's just so much control you can have with a high level graphical language, not to mention that the generated code is usually enormous and inefficient (two things that cannot be sacrificed on the FIRST controllers)

I think that the money and effort spent on developing this tool would have been better spent coming up with a solid curriculum to teach students how to program in C. With a little time and practice, I think that most people would find that there is no magic involved in programming.

I appreciate the efforts made by Elabtronics, and I hope that there are some people out in the FIRST community that will benefit from them. I just don't see myself using a graphical tool like this on anything complex.

[Ian Curtis]

This seems very similar to programming in FLL. Most teams use Robolab (graphics based) but teams are allowed to use ScriptEd (which is a scripting language) (even if BricX isn't allowed).

[Alexander McGee]

Bah, I'll stick with LabVIEW. Once I figured out how to control the RC with LabVIEW, I haven't looked at C code.

[roboticsguy1988]

Originally Posted by iCurtis

This seems very similar to programming in FLL. Most teams use Robolab (graphics based) but teams are allowed to use ScriptEd (which is a scripting language) (even if BricX isn't allowed).

Yes it does. Very much so.

If you think about it while a lot of people prefer the normal programming of an FRC bot using mplab. This could help some teams who may not have the mentor support to teach a student C. I think its still a benefit to the FIRST Community no matter what. There will always be teams that will not have the full capabilities as others and this is something to help those teams.

[Hutch]

I sure hope they DON'T switch to this... Programming is already really easy (I mean, all hardward interfacing code is provided, the autonomous scripting is there if you choose to use it, etc.) and more simplification would just ruin any remaining challenge to it IMO.

Or maybe provide it but still let you use C...

[Cyberguy34000]

Bahh... I think you programmers are overlooking something. While it might be easier for the initiated, C++ is a nightmare to learn in a matter of weeks for people with no prior experience. For small teams who barely get away with programming enough code to make their robot move in a few directions, this thing could be a godsend. For people who don't understand C, this could help them to actually have some autonomous code among other cool features that wouldn't have been possible before. True, it would be a bad thing to require the use of it for all FIRST teams, as many teams have programmers that are fully capable of coding in C, but I think it's shortsighted to blast something that you aren't familiar with.

Ultimately, used as another tool to help teams get off the ground faster, this thing could be great.