What Features Should the Default Code REALLY include?

[Joe Johnson]

As promised here: http://www.chiefdelphi.com/forums/showthread.php?p=258778#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:


I have just been enabled
I have just been disabled
I have just entered autonomous mode
I have just exited autonomous mode
A timer and associated functions (reset, set to time, start, suspend, etc.)
A future task scheduler: Pass it a pointer to a function that gets run at time T
A step by step auton shell with examples of switches based on position of arms, orientation/position of robot, time, watch dog timers, etc
Dual Wheel Encoders and associated functions (reset, CG position calculation, virtual compass, etc.)
Support Smart motor controls (read Barello's comments on positive feedback of motor velocity to compensate for back EMF of motors, hysteresis, etc.)
Support for PID control loops
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]

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 (http://sorceforge.net/) library for IFI-FIRST software to go along with the openFIRST (https://sourceforge.net/projects/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! :)

[Max Lobovsky]

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 =)
I agree, no point of putting in all these unnecesary functions into the main code when often a significant part is uneeded.

[Mark McLeod]

Obvious library functions include most of the programming topic threads like math libraries, common switch usage, less common sensor specialities like the gyro neutral position and accumulation, PID functions for hitting specific positions or velocities, a collection of autonomous styles, multiple action queue handling, high/low pass filters, the list goes on.

One thing teams can look at is their code from this year and functions or code snippets that can be turned into functions to be shared with other teams. One of the things you notice especially on these forums is the wide variety of programming techniques. Some people write the shortest, fastest code possible, others emphasize clarity and teaching of first year students. With a wide variety of solutions available to chose from new programmers could begin with what is easiest to understand and progress to more complex or efficient methods in later years.

[Joe Ross]

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)

[Mr. Lim]

Excellent discussion going on in this thread.

Features I would like to see in the default program:

non-linear transfer functions for joystick controls - who hasn't heard a team complain their robot controls are too sensitive/too jerky? :mad:

[Guest]

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.

[Guest]

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.
(Wow! This thread has divulged off-topic... Anyway...)

The question is go with a new repository or build on the old one (http://nrg.chaosnet.org/repository/)?

And, if "build on the old one" is the plan, what are the top 5 [specific] features you would like to see added?

[Max Lobovsky]

(Wow! This thread has divulged off-topic... Anyway...)

The question is go with a new repository or build on the old one (http://nrg.chaosnet.org/repository/)?

And, if "build on the old one" is the plan, what are the top 5 [specific] features you would like to see added?
Well it would be very nice if it was integrated with CD, maybe you could merge your code in. Other than that, i think the main feature it needs is some way to manage changes to the code. A bugzilla installation would be pretty cool, but it is kinda pointless when the biggest piece of code so far is like 15 lines. Actually, now that i mention it, a bugzilla installation for the default code is really needed. Im sure there have been at least 15 or 20 different changes and improvements posted about the default code.

[Guest]

Version editting at the nrg.chaosnet.org respository has been added.

[Max Lobovsky]

Version editting at the nrg.chaosnet.org respository has been added.
Wow, that was quick. Were you working on it before, or did you just write that stuff?

[phrontist]

UPDATE:

I just took a long hard look at the NRG system. It's beautiful. I look foward to contributing code!

[Max Lobovsky]

this is in reply to phrontist mentioning CVS in the previous post. he apparently deleted that

a CVS system would be great, though im sure something must already exist that would be appropriate for our needs. I looked at some CVS systems at the beginning of this season and realized that they are way way overkill for the few hundred lines we call software. If a CVS-lite doesn't exist, then we should sure make it!

I don't think we really need a CVS system for the code repository, but i was saying this just because it would be a very useful tool for most teams. For the code repository, the code base will probably small enough so it makes more sense to discuss individual changes on a forum or something like that.

[Guest]

Wow, that was quick. Were you working on it before, or did you just write that stuff?Just wrote it.

[Astronouth7303]

(Wow! This thread has divulged off-topic... Anyway...)

The question is go with a new repository or build on the old one (http://nrg.chaosnet.org/repository/)?

And, if "build on the old one" is the plan, what are the top 5 [specific] features you would like to see added?

Integration into CD (Or access from). I'm thinking like a Whitepapers section in the programming forum.
More nesting of categories. I know that isn't an issue (yet), but if this thing takes off...
Whitepaper doc to go with code.
Multiple file grouping (.h and .c together, for example)
Improved interface (I'm too used to CD!)

[Joe Johnson]

I typed up a long message about coding standards for sharing code and then decided that starting a new thread was better.

See this thread: http://www.chiefdelphi.com/forums/showthread.php?p=259590#post259590


Please read through to the end because there is a call for volunteers at the end -- FIRST may need you...


Joe J.

[Max Lobovsky]

Integration into CD (Or access from). I'm thinking like a Whitepapers section in the programming forum.
More nesting of categories. I know that isn't an issue (yet), but if this thing takes off...
Whitepaper doc to go with code.
Multiple file grouping (.h and .c together, for example)
Improved interface (I'm too used to CD!)

I'm sure Silver Star will have it done for you in a second :)

[Guest]

Integration into CD (Or access from). I'm thinking like a Whitepapers section in the programming forum.
More nesting of categories. I know that isn't an issue (yet), but if this thing takes off...
Whitepaper doc to go with code.
Multiple file grouping (.h and .c together, for example)
Improved interface (I'm too used to CD!)

1. CD Integration - There is access from CD. Go to the front page of CD and click FIRST Code Repository.
2. More nesting - Infinite nesting is possible with the current system. Just click "Make a new folder" checkbox after clicking the "Add" link. Put in a Folder title, and select the parent folder. Don't put code or description. (This has been there for a while now).
3. I shall add this - for now, you can put 'whitepapers' in the description box.
4. This is already there! Just put both in the "Source code" box. I will add multiple boxes, but it seems unnecessary.
5. Can't do ... :(

[Guest]

1. CD Integration - There is access from CD. Go to the front page of CD and click FIRST Code Repository.
2. More nesting - Infinite nesting is possible with the current system. Just click "Make a new folder" checkbox after clicking the "Add" link. Put in a Folder title, and select the parent folder. Don't put code or description. (This has been there for a while now).
3. I shall add this - for now, you can put 'whitepapers' in the description box.
4. This is already there! Just put both in the "Source code" box. I will add multiple boxes, but it seems unnecessary.
5. Can't do ... :(
Infinte nesting now enabled for all users (anyone who is logged in can now add folders, subfolders, subsubfolders, etc.)

[Guest]

I've added:

Full bug reporting capabilities (does not use 3rd party bug program):
- Report bugs with description, line numbers, and version
- Automatically displays relevant code below report.
- Users can "Report a Fix" in order to change the status of the bug to "fixed". The red X means not fixed, green check means fixed.

An example is here: http://nrg.chaosnet.org/repository/viewcode?id=26

In addition, I've added a "most recent contributions" listing to the repository index. Lists name of contribution and type (bug report, version, entry, or comment.)