Feature Creep!
When designing software, it can be easy to get
sidetracked and start adding unplanned features. It
happened in this project when I decided to add a “menu”
for difficulty settings, display options, and a demo mode.
When I realized I was getting too far from my original
plans, it was a hard choice, but I put some of the other
features on hold.
I did add the menu — which was fairly easy since it was
just another state to add to the main loop — but I only
implemented one option in this version of the puzzle. The
option I kept was the basic difficulty setting, so the user
could choose to play the default random game or the
original version where each switch affects its neighboring
LEDs.
It is obviously okay to add more features if they are
important to you, but if it goes too far, it is possible that
the changes will complicate the existing software. This
could make it take longer to write or debug. At its worst,
feature creep can cause the project to go into that “in
progress” box that many of us seem to have. I am happier
to have finished the first version of this project, and one of
these days I may work on the additional features.
STEER WINNING ROBOTS
WITHOUT SERVOS!
Perform proportional speed, direction, and steering with only two Radio/Control channels for vehicles using two
separate brush-type electric motors mounted right and left
with our mixing RDFR dual speed control. Used in many
successful competitive robots. Single joystick operation: up
goes straight ahead, down is reverse. Pure right or left twirls
vehicle as motors turn opposite directions. In between stick
positions completely proportional. Plugs in like a servo to
your Futaba, JR, Hitec, or similar radio. Compatible with gyro
steering stabilization. Various volt and amp sizes available.
The RDFR47E 55V 75A per motor unit pictured above.
www.vantec.com
Order at
(888) 929-5055
Conclusion
This puzzle box was just a basic example, but the
concepts can be applied to any device or subsystem. For the
next version, I still may add the difficulty options, and I also
plan to make the puzzle more truly random, even though I
haven’t noticed any obvious patterns yet. I also didn’t
implement the pin that does something when the user has
won, and instead just made a flashy display for now.
I may need to choose another microcontroller unless I
can optimize some of the code better, since I ran lower on
program memory than I originally expected. More feature-rich microcontrollers would prevent this problem (if you
have the funds and physical space for them) and they can
simplify software design as well, since they have fewer
limitations.
I hope this article gives you some ideas about a basic
method of software design you can use. This general
process is only a guideline for getting started, but even a
little planning can go a long way. You can add more rounds
of analysis and design based on your project’s needs,
and this process can be adapted to the way you prefer to
work, even incorporating other design methods you have
seen. SV
SERVO 06.2010 53
