What Features Should the Default Code REALLY include?

[Joe Johnson]

As promised here: http://www.chiefdelphi.com/forums/sh...778#post258778 I am starting a new thread to discuss what features the Default Code should really include.


Here is my list of good practice routines that I think IFI should include in future default codes:

1. I have just been enabled
2. I have just been disabled
3. I have just entered autonomous mode
4. I have just exited autonomous mode
5. A timer and associated functions (reset, set to time, start, suspend, etc.)
6. A future task scheduler: Pass it a pointer to a function that gets run at time T
7. A step by step auton shell with examples of switches based on position of arms, orientation/position of robot, time, watch dog timers, etc
8. Dual Wheel Encoders and associated functions (reset, CG position calculation, virtual compass, etc.)
9. Support Smart motor controls (read Barello's comments on positive feedback of motor velocity to compensate for back EMF of motors, hysteresis, etc.)
10. Support for PID control loops
11. I have more, but not right now...

I don't expect the folks at IFI to fill in the details of these functions, but I think that it would be a good thing to have shell functions in place that gets called at the right times so that we can get a jump start on programming our robots.

Please add your own thoughts and comments on this topic.

Joe J.

[Tom Bottiglieri]

I think:
1)a function that will simplify opening, starting, and stoping timers would be good. Even though i got the timers to work, it would be simpler to just be able to say "Start Counting" Than have to open up the timer the way it is now.
2)An easy function that will assign different In/Out pins to a binary set, where you set which pins hold which unit in the binary value. This will also return that binary value to an int variable.
3)An easy way to measure encoders, and possibly a rotation counting variable to go along with it. (ex. LeftWheelRotation = GetEncoderData(LeftDrive) )

Thats all for now
4)

[Max Lobovsky]

Maybe this is too specific to me, but i'd like a copy of the code with all the absolutely unnecesary stuff removed. This includes

1. those premade functions in user_routines.c
2. any preset control assignments and limits like p1_y to pwm01 or whatever
3. printf
4. im not sure about this one because it may be done all in hardware, but the built in 100th and 1000th of a second timers that can be referenced.

Essentially just leave only code that is neccesary to make the robot FIRST legal (enable and disable, autonomous, etc) and code required to easily read inputs and set outputs

[Mr. Lim]

It sounds like there are some polar views on this topic. There are some teams out there who are at the level where remapping buttons on the joystick to different relays on the RC is difficult. And there are some teams who can setup up interrupt driven encoders to feedback PID-control loops, without breaking a sweat.

I don't think an overly complex default program will benefit the former team, nor will it encourage the learning involved in getting to the same level as the latter team.

I think all the code to do these complex functions should be MADE OPENLY AVAILABLE, similar to how the default IR code was made available this year. But I don't feel that a default program that supports all these functions should be rolled out to every IFI controller when they're shipped out.

It would be nice to have all the code snippets that have accrued on chiefdelphi.com and in various code repositories rolled onto a CD which is included in the kit =)

[Joe Johnson]

It seems to me that IFI could pretty easily set up some simple #ifdef statements to allow for these functions to be used or not based on whatever the team in question wants.

Seriously, why go to all the bother of C if we are not going to use one of the major features of the language? We have all paid the price of having to know how and when to use the cast operation, the least IFI could do for us is reward us with some cool features.

But I digress... ...more importantly, some of the features (like "I've just been enabled", "I've just been disabled", "I just entered autonomous mode", etc.) are just plain good coding practice. IFI should include these types of function calls in the default code just to help train the population of FIRST users. (imho).

Joe J.

[MikeDubreuil]

5.A timer and associated functions (reset, set to time, start, suspend, etc.)

I'd like to see a built in interupt causing clock. With a user configurable frequency, but with a reasonable default, for instance 60Hz.

The clock would make measuring sensor changes over time much easier and almost intuitive.

(60Hz was chosen because it makes gyro calculations easier)

[Astronouth7303]

what Iwant to see:

• Integrated EDU/RC default code
• Corrected Main.c
• a header for all lib functions (see compiler code). (optional)
• Easier template use
• printf that doesn't freak if you don't init first (or documentation on the error)

Anything else?

[dlavery]

Originally Posted by SlimBoJones

I think all the code to do these complex functions should be MADE OPENLY AVAILABLE, similar to how the default IR code was made available this year. ... It would be nice to have all the code snippets that have accrued on chiefdelphi.com and in various code repositories rolled onto a CD which is included in the kit =)

Not to hijack the thread, but let me go off on a tangent for a minute. I think that the core of the idea mentioned above is great. We need to establish an environment where teams are able to grab modules of software to perform advanced functions for their robots. Rookie and veteran teams could share both algorithms and specific code segments. Teams can help each other with their software designs in much the same way that we currently share hardware designs. But to do this, rather than include a CD in the kit, it would be preferable to have an on-line library of open source software that can be continuously updated and expanded as more teams make use of the resource. Think along the lines of a SorceForge.net library for IFI-FIRST software to go along with the openFIRST project already in place.

If we can establish something like that (and yes, some of us are already talking with FIRST about the idea of an officially-supported open source project, so stay tuned!) then we could see a significant number of function modules becoming available to all teams. The teams could then pick and choose what they need based on their particular robot designs.

To get this effort started, it would be wonderful to have an initial set of modules to populate the library that would be useful to just about every team. So now back to Joe's original question, with a slight twist. If IFI-FIRST provided default code that cleanly supported the ability to drop in library module calls, what types of functions would we want to have? Joe's list of "good practices" makes a lot of sense - I would accept all these in the "we gotta have 'em" class. Modules to support common sensing functions (IR detect, time-of-flight IR, sonar, contact sensing, photo detectors, shaft encoders, capaciflective proximity sensing, etc.) similar to the IR code from Kevin Watson would be useful. But what else?

-dave

p.s. perhaps even more important, in addition to thinking about what modules you would like to see, start thinking about what modules you could CONTRIBUTE!

[Joe Ross]

Originally Posted by dlavery

We need to establish an environment where teams are able to grab modules of software to perform advanced functions for their robots. Rookie and veteran teams could share both algorithms and specific code segments. Teams can help each other with their software designs in much the same way that we currently share hardware designs. But to do this, rather than include a CD in the kit, it would be preferable to have an on-line library of open source software that can be continuously updated and expanded as more teams make use of the resource.

Something along the lines of this:http://nrg.chaosnet.org/repository/ ?

[MikeDubreuil]

Off-topic, sorry guys:
If an open source repository is made, It would be nice if each function had its own thread in a message board forum. This way you could get specific help if you don't understand something.

[Max Lobovsky]

Wow, im surprised i never thought of that before, Mike. Good idea. A code repository should be CDs next feature (though i dont know about every last function having its own thread, but yeah, every code snippet)

Originally Posted by Joe Ross

Something along the lines of this:http://nrg.chaosnet.org/repository/ ?

I added a "Comment" feature to the Repository some time ago. If you have questions, just click on the code snippet and then click Post a Comment.

The problem is too many people wanting code, and not enough people contributing code

[Astronouth7303]

I think CD is a great place for a repository, though it is a bit specialized.

Would the repository be just for .c and .h files, or could we include software? Examples: Lookup table generators, dashboards, etc.

[Tom Bottiglieri]

I am up for the repository idea. I have already started making libraries of my own source code for different drive techniques and other random tasks that I may want to use on the robot someday.

[Mark McLeod]

Lots of useful stuff can be included in a repository.

On a side note, one of the management questions that needs to be addressed is how and how much to control submissions? Also, there will need to be a version process in place to handle error corrections and expanded/changing capabilities.
I'm thinking mostly along the lines of quality control answering such questions as “has the code been tested and debugged?” Oftentimes when we're debating coding issues on the Programming Forum we'll post code suggestions off the tops of our heads, but there will be typos or logic errors that didn't necessarily seem important in the original context. Later you'll see the code with errors popup again in postings as someone attempts to use it "as is," not understanding that there are or may be bugs. We may want to consider some kind of peer review or monitoring.

Other issues are standards, e.g., coding, interface compatibility, documentation, etc. It's easy for you experienced programmers out there to handle the myriad styles one encounters by getting submissions from across all of FIRST, but the majority of Team programmers tend to be new to programming and are sometimes thrust into the job. The repository has to be made both easy for newbies (at least with the simpler/common functions), as well as easy for the rest of us to help newbies chose and integrate functions appropriate to their level of understanding.

Most of the programming mentors are out there driving home lessons in coding standards, testing procedures, configuration management, etc. These are second nature to us and need to be communicated through any repository. I don’t mean to say everyone will accept, implement, or follow the same standards, but there should be some basic standards in place to set a good example for new programmers to follow.