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.
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) )
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
those premade functions in user_routines.c
any preset control assignments and limits like p1_y to pwm01 or whatever
printf
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
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 =)
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).
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!
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.
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.
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)
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.
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.
[font=Verdana]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.[/font]
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.
