Team 166 Has Open Sourced Its Code

[platypus]

http://www.sourceforge.net/projects/frst166code08

Team 166 has released its robot code to the masses! Noting that it is still a work in progress (most of it has been tested on test boards and a chassis, which is worth...something), feel free to use it, edit it, and upload new code to the project.

Here's a brief listing of stuff in it:

-6 kinds of Drive Code, including Mechanum Drive
-Code to Utilize EEPROM that has been successfully used for the past two years
-Code for our manipulator this year, with OI integrated
-Code for the IR receiver
-Code for hybrid mode


Enjoy!

[Guy Davidson]

I'm sorry to disappoint you, but you should take it off as soon as you can. Your code is based off Kevin's code, which states, in the begining of every file

Originally Posted by Kevin Watson

You are free to use this source code for any non-commercial use. Please do not make copies of this source code, modified or un-modified, publicly available on the internet or elsewhere without permission. Thanks.

It's a great thing you're doing, but unfortunatley, it breaks the rules.

[blaxbb]

Originally Posted by sumadin

I'm sorry to disappoint you, but you should take it off as soon as you can.

You could just remove all of Kevin's files and just release the code that you wrote.

[platypus]

Assuming that the 2007 default code available on IFI's website doesn't fall under these restrictions, then our code does not actually include any of Kevin's files. At one point, his adc and gyro code was included and those files and documentation are still in the zipped folders posted for the project, but they have since been removed and the only trace left that they were ever used is a few stray lines that were commented out and never removed afterward.

Removing Kevin's code would be no problem at all, and I'll see to it immediately. Thanks for bringing the issue to my attention -- I clearly didn't think of that.

[Joe Ross]

Besides Kevin's code, you have two additional problems.

The sourceforge project shows that the project is GPL, but none of your source files contain any reference to the GPL and a copy of the GPL is not included with your source. The bottom of this page tells you how to properly apply the GPL http://opensource.org/licenses/gpl-license.php

In addition, since you don't own the IFI code, you can't license it as GPL, so their code should be removed from your project as well.

[Tom Bottiglieri]

A little constructive criticism... I see a lot of logic being implemented in conditional statements that does not need to be. For example:

if(pressure_sensor == 0) compressor = 1; 	
    else compressor = 0;

could be

compressor != pressure_sensor;

From what I see you can cut out a good chunk of code and boost your efficiency by doing some simple optimizations.

[Alan Anderson]

Originally Posted by Tom Bottiglieri

From what I see you can cut out a good chunk of code and boost your efficiency by doing some simple optimizations.

[tangential rant]
Compilers, not programmers, should do optimizations.
[/tangential rant]

[Tom Bottiglieri]

Originally Posted by Alan Anderson

[tangential rant]
Compilers, not programmers, should do optimizations.
[/tangential rant]

I guess this is the old machine logic vs. human logic argument. Why have real programmers when the chem, mech, and civil E's can just put in their logic and the code spits out correctly?

But if programmers don't know how to do it then who will make the new compilers after this generation retires?

[wt200999]

Originally Posted by Alan Anderson

[tangential rant]
Compilers, not programmers, should do optimizations.
[/tangential rant]

The programmers should optimise for readability while the compiler optimises for other things

[Eric Finn]

Thank you for the info about the code we don't own or have the right to redistribute being on the project. All code has been temporarily taken down and we are going to repost *our* code soon.

EDIT: Our chopshop library (CHOPSHOP.C and CHOPSHOP.H) has been uploaded. This library contains our code from previous years (EEPROM, drive algorithms, etc.) that we keep from year to year. More current code will be uploaded once the writers believe that it's ready to release. Again, thank you for notifying us of the licensing issues.

[ay2b]

Originally Posted by Eric Finn

EDIT: Our chopshop library (CHOPSHOP.C and CHOPSHOP.H) has been uploaded. This library contains our code from previous years (EEPROM, drive algorithms, etc.) that we keep from year to year. More current code will be uploaded once the writers believe that it's ready to release. Again, thank you for notifying us of the licensing issues.

Be careful with this one too. You are not permitted to directly reuse code from previous years, just as you are not permitted to directly reuse hardware components from previous years. You are, however, permitted to use the designs, ideas and algorithms from past years, but your implementation is supposed to be new each year, implemented during the build season (and fix-it windows).

Any code which is published publicly, in a location widely recognized by FIRST teams, is considered COTS and is permitted to be used directly, as per the COTS rules. This allows the use of Kevin's code, or IFI's code, and allows them to update it outside the build season, and all teams to use any version of it.

It is my interpretation of this rule, that if you were to have published your code from past years on CD, or on sourceforge and announced it on CD, then that code would also be considered COTS and would be permitted. It is not clear to me: if you were to develop something prior to the build season, and then publish it during the build season, would that still be considered COTS?

Unfortunately, in my quick perusal of the rules, I am unable to find the exact rules at this time in order to quote them here. Hopefully someone else can help me out, find them and post them.

[dcbrown]

Compilers, not programmers, should do optimizations

Correct. Too bad we don't have a decent optimizing compiler available.

But is it better to have code that reads:

    for (samples_recieved=0; samples_recieved<10; samples_recieved++)
    {
           :

Or code?

    for (samples_left_to_receive=10; --samples_left_to_recieve !=0; )
    {

Both do equivalent things, the best optimizing compiler won't turn one into the other and yet the 2nd is much more efficient in that the change in control variable also will set status/results for testing and avoid a second comparison operation. With the PIC18F, the above is 3x+ times more efficient due to a programmer choosing a different but equivalent method.

Does this really matter? In most cases, no. But if the code happens to be executing at interrupt level or is executed thousands of time per second then generally yes it does matter. A few changes like this usually can reduce the interrupt code footprint to 1/2 to 1/3 of what it was. Typically I scrutinize only about 10% of the code I write for efficiency, yet the run-time impact can be huge.

Knowing the underlying architecture of a processor you're working on also can impact which code constructs you choose to utilize. Yeah, it would be great if the compiler figured out this stuff for you... but often it doesn't or like above can't. On the PIC, for example, computing ram addresses isn't exactly efficient. In some cases if makes sense to unroll "for(...)" loops. For example:

    for(ndx=0; ndx<10; ndx++)
    {
          sample[ndx] = 0;
    }

is terribly inefficient. It takes 14-16 instructions to calculate the ram address plus the overhead of ~13 instructions to manage the loop variable. Choosing to unroll the loop in the above case into the following is a huge win as the code execution is on average 10x times faster with little change in code size.

    sample[0] = 0;
    sample[1] = 0;
    :
    sample[9] = 0;

Anyway my point is a programmer should care about how code constructs map to the underlying architecture. If they didn't, then the way to go would be to just change everything to extended floating point precision and do all calculations that way -- the "smarts" in the compiler would figure out when we needed integers vs floats and 8 bit values vs 32 bit values and hide all that nonsense from the programmer.

PS
Another common trick/practice on the PIC when dealing with loading data from h/w such as:

379:               	timer_count = TMR1H;
380:               	timer_count <<= 8;
381:               	timer_count += TMR1L;
382:               	timer_count -= offset;

 06730    50CF     MOVF 0xfcf, W, ACCESS
 06732    6F17     MOVWF 0x17, BANKED
 06734    6B18     CLRF 0x18, BANKED

 06736    C517     MOVFF 0x517, 0x518
 06738    F518     NOP
 0673A    6B17     CLRF 0x17, BANKED

 0673C    50CE     MOVF 0xfce, W, ACCESS
 0673E    6E2B     MOVWF 0x2b, ACCESS
 06740    6A2C     CLRF 0x2c, ACCESS
 06742    502B     MOVF 0x2b, W, ACCESS
 06744    2717     ADDWF 0x17, F, BANKED
 06746    502C     MOVF 0x2c, W, ACCESS
 06748    2318     ADDWFC 0x18, F, BANKED

 0674A    5119     MOVF 0x19, W, BANKED
 0674C    5F17     SUBWF 0x17, F, BANKED
 0674E    511A     MOVF 0x1a, W, BANKED
 06750    5B18     SUBWFB 0x18, F, BANKED

A simple change can result in much more efficient code by using an anonymous union structure:

typedef union u_U16
{
	unsigned int data;
	struct {
		unsigned char b0;
		unsigned char b1;
	};
} u_U16;

u_U16 timer_drift;


384:               	timer_drift.b1 = TMR1H;
385:               	timer_drift.b0 = TMR1L;
386:               	timer_drift.data -= offset;

 06752    CFCF     MOVFF 0xfcf, 0x516
 06754    F516     NOP

 06756    CFCE     MOVFF 0xfce, 0x515
 06758    F515     NOP

 0675A    5119     MOVF 0x19, W, BANKED
 0675C    5F15     SUBWF 0x15, F, BANKED
 0675E    511A     MOVF 0x1a, W, BANKED
 06760    5B16     SUBWFB 0x16, F, BANKED

Another quick 3x increase in code size and execution efficiency.

[baop858]

Aren't chars unsigned by default on the 3.10 compiler?

[platypus]

Our of our code (specifically that code produced by us) is available now for download either individually or all at once. All code by Kevin or IFI has been taken down.

Our code is now properly licensed, with the copyright statement at the top of each file. You may use it, copy it, and edit it. We request that if you make useful updates to the code (and test them to success), then by all means, please share those updates in this thread.

Thanks to all who have posted about issues so far. Whenever you find anything, just post it here.