What Features Should the Default Code REALLY include?
 

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.

Re: What Features Should the Default Code REALLY include?
 

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)

Re: What Features Should the Default Code REALLY include?
 

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

Re: What Features Should the Default Code REALLY include?
 

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 =)

what is #ifdef for?
 

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.

Re: What Features Should the Default Code REALLY include?
 

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)

Re: What Features Should the Default Code REALLY include?
 

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?

Re: What Features Should the Default Code REALLY include?
 

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! :)

Re: What Features Should the Default Code REALLY include?
 

I agree, no point of putting in all these unnecesary functions into the main code when often a significant part is uneeded.

Re: What Features Should the Default Code REALLY include?
 

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.

Re: What Features Should the Default Code REALLY include?
 

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

Re: What Features Should the Default Code REALLY include?
 

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.

Re: What Features Should the Default Code REALLY include?
 

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)

Re: What Features Should the Default Code REALLY include?
 

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:

Re: What Features Should the Default Code REALLY include?
 

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