Problem with compass based steering code
gncguy
Posts: 35
I'm having problems with the Stamp math.· I have a boebot set up with two BOE boards.· One handles the elctronic compass and transmits the measured direction via the SEROUT command.· The main board recieves the angle via SERIN.· the communication is working.· It is the·sterring calculations that have the problem.· I try to compute which way to turn based on the error in the direction angle (delang). Sometimes the delang becomes the 2**8 number (65322).· So I am doing my math incorrectly.· I have attached to the code if someone could check the code for my math.· The code is full of DEBUG statements so that I can see what is going on.· Also, I have turned off the looping for the time being.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
'--------------------CalculateDesiredHeading----------------- 'This section recieves two variables in the form of 'degree values 0-360. One is the desired heading as given 'by _GetGPSHeading (above), the other is given by the compass 'Theta1 is compass heading, theta2 is GPS heading _CalculateDesiredHeading: 'get the current heading GET 39, Word theta1 'theta2 is already given by previous method IF(theta1 > (180 + theta1)) THEN theta1 = theta1 + 360 ELSE IF(theta1>(180 + theta2)) THEN theta2 = theta2 + 360 ENDIF ENDIF IF(theta1 > theta2) THEN LOOKDOWN theta1 - theta2, >=[noparse][[/noparse]55,40,20,0], headingGPS headingGPS = headingGPS + 1 ELSE LOOKDOWN theta2 - theta1, >=[noparse][[/noparse]55, 40, 20, 0], headingGPS headingGPS = 7 - headingGPS ENDIF DEBUG DEC1 ? headingGPS, CR, CR PUT 48, headingGPS RETURNThe input to this code is two headings: one given by the compass, and one given by the user (your desired heading). The output is a relative heading 1-7. In my program, I then figured out what the sensors were saying, and figured out there heading. Next, the two headings were compared and action was taken. A heading of 1 is far left, 4 is straight, and 7 is right.
·
You can write quite a few nested statements as something like this:
if conditionA = true and conditionB = true
''do stuff
else if conditionD = true and condidtionC = true
''do stuff
''and so on
As to my avatar, take a look at Swiftsure BS2e Robot
One can use nested IFs, and GOTOs, too, in confused (and confusing) programs.· One can with equal ease write confused (and confusing) code while avoiding these particular constructs completely.
People write confused code because they don't plan what they're going to do before they start writing code.· It's a beginner's error to write code before planning it.· I did it for a long time, to my later sorrow.
If you want to write good code, the thing to do is document the program first, before you write a single line of code.· Document what it's going to do, how it's going to work, what your assumptions are.· It's amazing how much easier this makes the writing of the code itself.
The same is true of anything else, of course.· Would you build a house, and only afterwards set down how you wanted it to look, where the front door was, which way the bathroom door opened, how many windows the kitchen had?· Of course not, although I have seen houses built that way (one in Texas, and the famous Winchester house in California).
It's planning, and clarity of thought, that make good programs -- not silly rules like "avoid GOTOs" or "don't use nested IFs".· Planning, and clarity, make equally for good houses, good cars, good airplanes, good washing machines, good programs·-- and good toy robots, too, I guess.
A good planning document doesn't have to be fancy.· It can be scribbled on the back of the Valentine your neighbor's kid shyly gave you, but if it's clear, and if it enables you to know what you want to do, it's good enough.· You'll change the plan [noparse][[/noparse]the·design] many times anyway,·if it's complex at all, but it will save you far more (in cost and time) than you spent to do the planning first.
Avoid anything you don't like, but not because some expert (or some yokel) says it's bad.· Through about thirty years of assembler programming on IBM mainframes, there were a few instructions I avoided for no better reason than that I found them hard to understand.· My work product never suffered because I preferred BCT (branch on count) and avoided BXLE (branch on index low or equal).· But on those occasions when I started coding without actually designing the program first, my work product was stinko.· Eventually these occasions became rare, as I slowly smartened up.· So can you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 11/24/2008 4:59:43 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
It's these "silly rules" that give code it structure. One could just as easily say that it's silly to put comments in the code because it spaces things out too much. Yet what it really does is makes it easier to understand. Same thing with GOTO's and nested IF's. Or perhaps you think formatting the code is a silly rule: why not just left align everything? Because it makes the code hard to understand. Understanding your code is key to a well working program, and that is why we have these silly rules that some yokel made.
First off, GOTO: it has uses, but for the most part, look at main-stream programming languages like C++ and JAVA (Those are the only ones I'm looking at, so don't bring in other languages): they use lots of the equivalent to GOSUBs (by using method calls) and never use a GOTO type statement. The problem with GOTO is that it can create difficult code. If you are careful, GOTOs can be useful. For the most part though, it's a pain.
Next, nested IF's: most statements are more natural when read with an AND (or OR) and not as a set of "IF this is true, IF this too is true".
IF true AND true
is easier to read and understand then
IF true THEN
---IF true THEN
By putting your decision statements in a row, you can scan over a block of code and know exactly what it does at first glance. By using nested if statements, you have to spend longer looking at a block of code to get the true meaning. There are some situations where nested works better:
IF a is true
---IF b is true
---IF c is true
---...
is better then
IF a is true AND b is true
IF a is true AND c is true
IF a is true AND ...
But for simple statements
IF true
---IF true
you can instead write it as
IF true AND true
I agree with planning: it makes anything easier.
I'm sure you're just regurgitating what you were taught somewhere.· I agree it's possible that following these silly rules may make some really bad programming a little easier for other really bad programmers to read, but I'll take intelligent planning and meticulous commenting·over mindless mechanical adherence to stupid purities any day.
When I see people spout this nonsense, I'm reminded of an expression from the writings of Ambrose Bierce:·
" ... one who utters with his tongue what he thinks with his ear, and feels the pride of a creator in accomplishing the feat of a parrot."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
You're right: it is nonsense. It's not impossible, just more difficult. The "silly rules" are a framework, ready for you to use. Image that you have one of those laser keyboard things (that project onto your desk), and that it reset itself every day. So, every day you had to say that "This key is Q, this key is W, this key is E," and so on. It would quickly sap all your energy and lead to mistakes. Sure, if you got to be really good, then perhaps you realize that you don't need a Q key, so you skip it. The same is true with code: by having everything setup for you, you can get onto creating a product, rather than designing the tool that is required.
I hope that you are out there teaching new programmers, to prevent this sort of problem...
Your analogy mystifies me.· I see no similarity at all between your projected-keyboard example and anything else in your argument or in mine.
The last ten years I worked, I was a traveling consultant.· I'd fly to Chicago this week, Cheyenne next week, New York the next -- I don't ever want to ride an airliner again -- spending most of my time examining the assembler language of programmers who had left, or died, or been promoted, and were no longer available to enhance/correct their own stuff.· I saw an incredible lot of code -- I still have archived several million lines of other people's code -- that would have been improved by imposing something analogous to what you espouse.· In essentially every case, though, it would have been improved much more by imposing what I espouse.· That's why I espouse it.
Most of the really egregious errors I found , however, didn't result from a lack of your practices, nor of mine.· A typical example would be one from a huge telecommunications company in Irving, TX, in which hundreds of programs decided whether a year was a leap year or not, by testing whether the last digit of the year was even or odd.· Honest Injun, they really did, and they based their customer billing (landline & cell phones, millions of customers) on it.· Neither your ideas nor mine could necessarily have prevented that.· But if your ideas had been followed, the repairs would have been easier to find, and if my ideas had been followed they would have been much easier both to find and to fix, and likely would not have been entombed in the code to start with.
One thing I learned very thoroughly:· most programmers stink, and most programming stinks as a result.· These facts were very profitable for me.
Looking over my prior post, I'm a little ashamed to have scathed you so severely.· Please accept an apology for the excess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Anyway, my analogy with the keyboard is this: that be having to redefine the new key layout every day, you are wasting your time that you could be spending working. The same applies to code: by having to redefine the standards every time you create a new file, you waste time. Granted, there is a sliding scale of what is good practice: I think most programmers would agree that proper indentation is critical to code, while probably most differ on how to capitalize variable names (first word lowercase, following words first letter capitalized...) Maybe I'm more traditional, and maybe you are more modern. Either way, the programmer has to find out where he fits along the line.
BTW, I'm not against planning out what to code before sitting at the terminal, in fact, since much of my time is spent away from the computer, I carry a notepad where I can doodle out designs and algorithms.
So, to be clear, I'm espousing that programmers should follow standards (including avoid GOTOs and certain IF structures) to make their time more efficient and effective. What is it that you are espousing?
Edit: @gncguy: sorry for hijacking your thread... Has your problem been fixed yet, or is your thunder being stolen?
Post Edited (SRLM) : 11/24/2008 1:43:35 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· -- Carl, nn5i@arrl.net
Post Edited (Carl Hayes) : 11/24/2008 5:04:03 AM GMT