Robot Software. OOPic sample programs.

Web	www.PhilBot.com

My other sites

OurCoolHouse

Phil's Resume

Web Portfolio

[Home] [Projects] [Hardware] [Software] [Books] [Links] [Downloads]

Software

My way of writing software must be different from most people's.

I've seen a lot of other computer programs, and it always seems to me that the programmer was more concerned with the "NOW" and not very concerned with the "LATER". I'll give you an example.

My pet peeve with most programmers is their lack of program "Comments". Comments are those lines of text in any program which don't serve any purpose except to "describe" what the program is doing. Many programmers never even consider including comments in their programs because they know what the program's doing...since: "they wrote it". Some other programmers add comments which simply explain in words what each line of code is doing. Both of these approaches indicate to me that the programmer never indends to return to their program in the future, otherwise they would be much more interested in reminding their future selves of what they were thinking at the time they wrote it. They are stuck in the "NOW" and can't even imagine a "LATER" time where they might want to extend or reuse their own program. It's as if they consider their program "disposable".

My approach is exactly the opposite. I won't even consider starting a program until I have considered how that program can help me WAY into the future. If I'm going to be spending the time to write this program, I want to ensure that every idea or concept I create is preserved for me to understand and reuse at a later time. I routinely go back to programs that I wrote 5-10 years ago and reuse major portions of them. By now I know exactly what I have to do to ensure a program's future usefulness:

I always consider the Big Picture first. I always try to think of where this program could lead me to, and I explore ways to make the code more flexible & adaptable to other purposes.
I always try to consider someone who may have to follow in my footsteps, or use something I created. I always try to make it easy for them to see what I had in mind, or use pieces that I have created. I get great pleasure in building components that others can use to make their own ideas come to life.
I will never cut & paste code blocks if I have to do something more than once. As soon as I even suspect I may need to use the same code twice, I put it into a function or subroutine so that it can be called whenever I need to use it. This also goes for when I think a function may be needed in two totally different programs. By making it a function immediately, it makes it easy to move the entire block of code to another program.
Wherever possible I add comments to describe "what" the code's doing, rather than "how" it's doing it. The "How" part is embodied into the lines of code, and it's possible that there could be a bug that hides the actual intent of the code. The "What" indicates what the code was MEANT to do, so if there is a bug that needs to be fixed a year from now, I'll have a record of my intent, even if it wasn't properly realized.
If I ever have to do something "Tricky" in the code I add extra comments to explain the "trick". If it was hard for me to figure out now, it will also be hard to figure out in the future, so I better explain it while it's fresh in my mind.
Wherever possible I don't put fixed numbers in the code. This is called "Hard Coding" and it makes it difficult to reuse or expand the purpose of a program. I put all the fixed numbers and strings at the top of the file as "constants" or "defines" and then reference them by name when they are needed.
Wherever possible I make my code "Configurable" by the end user. If I can prevent someone from actually having to change the code to adapt it, then I've eliminated the opportunity for someone to introduce bugs into the code. The use of .INI files in windows is a classic example of "configurability".

So what does all this mean for Hobby Robotics programming?
Well, as I add robot projects to this site I'll describe my software, and try to illustrate how I think the process should work. Use the link(s) below to see what I mean.

OOPic MarkIII Object (OOPic V5.0 Compiler)
In this example I encapsulate all the basic Mark III Sumo interfaces into a single reusable oUserClass object. The idea being that once I get the object right, I can use it on all my different projects without having to bother with writing code to read and write the I/O devices ever again. I can also publish the software so that other users can do the same.
Using the OOPic MarkIII Object (OOPic V5.0 Compiler)
This page has two examples of using the oUserClass I created above. In these samples the only code that you need is the "strategy" code. All the other I/O definition and setup is part of the user class. I've shown two simple Sumo strategies. See if you can create some more.
BOB Lesson A: LED Test. (OOpic V6.0 Compiler)
It makes sense to start with the most basic and/or the most useful robot function. For BOB this means checking out the LED indicators. Once I know these work, then I can use them to help me test all the other functions.
BOB Lesson B: Proximity Sensor (Eye) Test. (OOPic V6.0 Compiler)
Here we'll verify that the three Eyes work by hooking them up to three of the LEDs. Eyes are great for finding opponents or preventing BOB from running into walls.
BOB Lesson C: Motor Drive Test. (OOPic V6.0 Compiler)
Next we'll make sure we can control BOB's wheels. We'll ensure that the correct wheel is turning in the right direction, and that we can vary the speed. Then we'll have him drive around without bumping into things.
BOB Lesson D: Line Sensor and SUMO BOB. (OOPic V6.0 Compiler)
By adding the Line sensors we have all the elements for a Sumo robot. See how we can put all the pieces together.
BOB Lesson E: Optical Wheel Encoders. (OOPic V6.0 Compiler)
Now that we can turn the wheels, it's important to see that we can measure the rotation using BOB's optical encoders. This is one thing that sets BOB apart from any robot that uses hacked Servos to drive the wheels. Wheel feedback lets us consider closed loop position and speed control
BOB Lesson F: Closed Loop Position Control using the Optical Wheel Encoders. (OOPic V6.0 Compiler)
I investigate a simple commanded position wheel driver for BOB. The main program can set speed and position, and Virtual Circuits do the rest.
BOB Lesson G: Closed Loop Speed Control using the Optical Wheel Encoders. (OOPic V6.0 Compiler)
I investigate a simple PID Wheel Speed controller for BOB. The main program can set a speed range from 1 - 100 and Virtual Circuits adjust the wheel drives to hold that speed.