Hi, we are currently working on a new autonomous program which uses infared sensors for more accurate readings I know several teams have done this. Anyways this is what we have come up w/ so far… can anyone spot a mistake? It tokenizes but there is a Basic run error when putting it on the robot.
if auton_mode=1 then auto1:
goto end_auto_loop:
auto1:
first:
if dist>7 then end_first:
drive_R=0 'ur going backwards remember
drive_L=0
if rc_sw3=0 then end_auto_loop:
dist=dist + whlc
goto end_auto_loop:
end_first:
turn:
if dist>9 then end_turn:
drive_R=difrdir
drive_L=difldir
if rc_sw3=0 then end_auto_loop:
dist=dist + whlc
goto end_auto_loop:
end_turn:
open_pnuematics:
if dist>10 then end_open_pnuematics:
p1_sw_trig=1 'open lower pneumatic
p2_sw_top=1 'close shoulder pneumatic
end_open_pnuematics:
straight:
if dist>16 then end_straight:
drive_R=255 'straight now
drive_L=255
if rc_sw3=0 then end_auto_loop:
dist=dist + whlc
goto end_auto_loop:
end_straight:
straight2:
if dist>21 then end_straight2:
drive_R=255 'straight now
drive_L=255
Well, one guess is that you’re feeding 255 as a value. That particular value is used to store something partaining to the code (I forget what) but basically, avoid it. Try using 254 instead.
Man I need to open up pBasic again!
It been so…long…
Anyaway, the new language sould be revealed 10/01/03
Sachiel7 has it pretty well correct, but I don’t think (s)he (trying not to be presumptuous, here) explained the concept well enough.
To my knowledge, when you send the value 255 to a speed controller, by defining either drive_L, drive_R, or PWMn as 255, the speed controller interprets this as 0V (or 0% duty cycle), rather than +12V (100% duty cycle), which is full forward.
254 is the maximum value which you’re supposed to send to a speed controller.
I just looked at the RC Reference Guide, on IFI’s website, and there isn’t a very descriptive explanation as to what specifically is wrong. Id est…
Programming Problem: Basic Run Error Indicator
If after programming and resetting the Robot Controller, the BASIC RUN ERR LED is ON, then the
basic code has no output. This means that the code is not running properly. Check for errors in the
code. The BASIC RUN ERR light is controlled by the Output microprocessor.
So, actually, now that I think of it, if you’re sending 255 as a PWM output, it (the Output microprocessor) might interpret that as the end of the SEROUT command from the BS2, and think that it’s supposed to then recycle (start its sequence all over). Perhaps changing the values from 255 to 254 will do the trick.
A value of 255 in the wrong place will not cause a Basic Run error, unless you’re very lucky. Instead, it’ll make your robot do a “not-so-happy” dance, with random LEDs blinking and whatnot, due to the problem Jim mentioned, that the SEROUT command gets screwed up. We had this problem in 2002, and it took a bit of time to figure it out :).
Instead, one thing that I’ve noticed, unless you have any debug statements, leaving the serial cable in the Programming Port will trigger an error, I believe a Basic Run error, but I can’t remember what exactly.
Another possible problem is that someone touched the uP init section, and I’m pretty sure that can’t be touched or it’ll break. Also, make sure you use the Constants section correctly, because I believe any value used in SERIN and/or SEROUT must be “signed” by a Constant. It’s been a while, so I can’t remember exactly, but definitely check the default code on www.innovationfirst.com/firstrobotics to make sure nothing crucial changed.
Well, after a short collaboration with my team’s lead programmer, we agree that for the robot, 255 exceeds the max value of what the robot controller can understand. 254 is the max value, I believe. Try changing it to that and then running the program. That should help
EDIT: Another idea is to check your var declarations, and make sure you have everything declared, as well as checking constants and SERIN and SEROUT. Also, try unplugging the serial cable from the program port and resetting the bot. When we had basic run errors and did that, they usually went away. Otherwise, we turned to the lead programmer and made him go fix the code
As far as I can remember, sending two values of 255 in a row in the serout will cause a reset, and everything will be messed up. This is why there are two 255’s at the beginning of the serout. It tells the processor that the outputs begin there. If it resets later, the variables wil not match up with what is being outputed, hense undesired motor output. If this makes no sense, I can try to explain it better, but for right now I am too tired.
I think the consensus is that 255 should be avoided, due to many reasons.
*Originally posted by Jeremy J * Well, after a short collaboration with my team’s lead programmer, we agree that for the robot, 255 exceeds the max value of what the robot controller can understand. 254 is the max value, I believe. Try changing it to that and then running the program. That should help
Yes, this is the case of a common fencepost error. In most programming languages, including this one, counting starts at zero instead of one. So if you want 10 numbers, it is really 0 through 9, not 1 through 10. So there are 255 values that you can assign a PWM, but it is 0-254
a) NEVER EVER EVER EVER EVER set a PWM to 255. EVER! As
Damian Manda said, sending two 255’s in a row will cause the RC to think that all bytes following it are the start of a new Serout command. Thus, what should have been output to PWM5, for example, may end up being interpreted as relayA, causing stuff to go massively haywire.
b) The “wrapping” of numbers isn’t really an issue here. PWMs are stored as bytes (8 bits), so they can have 256 values (0-255). It’s just that 255 means something else…
c) For you power freaks out there that are concerned about not getting that extra 1/256 of an output to your speed controllers, don’t be! The Victors interpret anything above about 240 to be full ahead and anything below about 17 (IIRC) to be full reverse. The only even semi-real disadvantage to not being able to use 255 is that you’ll loose 1/256th of a rotation on your servo.
Thank you, thank you, thank you, Rob for saying everything I’d wanted to scream since starting of reading the post. Probably better you said it though, since I tend to get a little excited. Oh well, it’s all been said. But anyway, that code looks like a perfectly good SELECTION of code - there may be an error somewhere else that you didn’t include; though your 255 error is an almost certain culprit of your problem. Tell us if it’s still not working out for you.
I think it is unlikley that setting the pwm values to 255 is causing the problem. But, it depends on what PWM values the variables correspond to. If this was the problem, you’d have a problem sometime into running the program, not on download.
how big is dist and whlc and do you overrun anything when adding them together? Same thing, this shouldn’t cause the error, but is something to look into.
I think the most likely cause was already mentioned by Ian. If you tried to read in a new sensor, but didn’t define the constant saying that you want to read it, your serin will be mismatched with the initialization. Look at the section of the code labled “DEFINE CONSTANTS FOR INITIALIZATION”
It would also be helpful to see more of your code if one of the suggestions doesn’t help.
Fotoplasma has it right, and I like how Rob described the problem. I remember researching this, and if you look into the code, every time it sends out to the RC the new packet it sends “255,255” at the beginning to tell it that this is new information if I’m not mistaken. The purpose of this, is code has errors, it skips (delta_t counts how many times it’s skipped for those that don’t know) and when it skips, without that “255,255” it’ll interpret the inputs as part of the line before, and we all know we don’t want that. So when you have 255 run in another part of the robot, as someone put it, it does a dance, because it keeps translating the inputs into different areas and each time it errors (I believe) the outputs will swap again, so things go nuts. I’m not 100% sure about all of this, but this is the conclusion I came to awhile ago and I think that’s what happens. But yea, swapping your 255 will almost ALWAYS fix that. Another trick if that doesn’t work, stick a debug statement somewhere before the lines to output “hello” or something, just so you can tell if the code gets to that without having an error, then move the debug around to find the problem area, then you work with that area and sometimes it connects to something else and then you have to look at that as well. I hope this helps. Good luck!
*Originally posted by rbayer *
**b) The “wrapping” of numbers isn’t really an issue here. PWMs are stored as bytes (8 bits), so they can have 256 values (0-255). It’s just that 255 means something else…
**
Not true, if you read the Innovation FIRST comments (which I doubt anyone does anymore :rolleyes: ) it specifically says that a PWM can have 255 values, not 256. So the wrapping error is very important for people to understand, since it is 0-254, not 1-255
Originally posted by Joe Ross
[b]I think it is unlikley that setting the pwm values to 255 is causing the problem. But, it depends on what PWM values the variables correspond to. If this was the problem, you’d have a problem sometime into running the program, not on download.
how big is dist and whlc and do you overrun anything when adding them together? Same thing, this shouldn’t cause the error, but is something to look into.
I think the most likely cause was already mentioned by Ian. If you tried to read in a new sensor, but didn’t define the constant saying that you want to read it, your serin will be mismatched with the initialization. Look at the section of the code labled “DEFINE CONSTANTS FOR INITIALIZATION”
It would also be helpful to see more of your code if one of the suggestions doesn’t help. [/b]
Joe, what you’re describing is what causes Basic Init Errors, and not Basic Run Errors.
From the Innovation First Full-Size Robot Controller Reference Guide:
Programming Problem: Basic Run Error Indicator
If after programming and resetting the Robot Controller, the BASIC RUN ERR LED is ON, then the
basic code has no output. This means that the code is not running properly. Check for errors in the
code. The BASIC RUN ERR light is controlled by the Output microprocessor. Programming Problem: Basic Init Error Indicator
If after programming and resetting the Robot Controller, the BASIC INIT ERR LED is ON, then the
basic code did not properly initialize the data packet structure with the master microprocessor. Check
the initialization part of the code for errors. A common mistake is having a different number of
variables in the SERIN command, as compared to the requested data setup in the “Set the Initialization
constants you want to read” section of the code. The BASIC INIT ERR light is controlled by the Master
microprocessor.
My guess is that either[list=1][li]the 255s are causing the problem, or [*]some part of the code other than that of which we have visibility is preventing the serout from being executed.
[/li][/list=1]
BTW, the two relay bytes are deliberately interspersed in the serout command between PWMs 1, 2 and 3 to prevent 255s output to PWMs from causing problems in the most common cases where someone is using the default code (or has made minimal modifications to it.) So, Salik, if you’re using two consecutive PWMs (not including 1 and 2) for drive_r and drive_l, there’s your problem. (Actually, it is still possible to provoke this problem when you’re using PWMs 1 through 3 if you happen to turn on all the relays in one of the relay bytes.)
Are you using the newer version of PBASIC or the older version? Innovation First came out with a newer version for the 2003 season, and it doesn’t use that format for the IF statements. I don’t know if that would tokenize properly, but might be your problem.
However, if those 255s aren’t causing a problem now, they will later. Outputting 2 values of 255 in a row will mess up your program.
*Originally posted by golf_cart_john *
**Are you using the newer version of PBASIC or the older version? Innovation First came out with a newer version for the 2003 season, and it doesn’t use that format for the IF statements. I don’t know if that would tokenize properly, but might be your problem.
**
With the 2003, the code works the same as every other year, you could just use the new version if you wanted but the old IF loops work fine still.
Originally posted by gwross My guess is that either[list=1][li]the 255s are causing the problem, or [*]some part of the code other than that of which we have visibility is preventing the serout from being executed.
[/li]> [/list=1]
Yes, you’re right about the serin. I realized that after I looked at that same document for a different reason, today.
Originally posted by gwross
BTW, the two relay bytes are deliberately interspersed in the serout command between PWMs 1, 2 and 3 to prevent 255s output to PWMs from causing problems in the most common cases where someone is using the default code (or has made minimal modifications to it.) So, Salik, if you’re using two consecutive PWMs (not including 1 and 2) for drive_r and drive_l, there’s your problem. (Actually, it is still possible to provoke this problem when you’re using PWMs 1 through 3 if you happen to turn on all the relays in one of the relay bytes.)
This is why my initial inclination was that the 255’s are not causing the problem. However, after going throught the code snippet, both won’t be set to 255 until dist > 9. So, either dist would have to be initialized to > 9 or the sensor would be giving a larger value then was expected. It should definetly be fixed, but I don’t think it is the cause of the problem.
salik: it appears that whlc is the number of feet that you have traveled. Is that correct? How is this value computed? Are you reading it directly from your infrared sensor, is it being calculated in your program based on sensor readings? is it calculated in your custom circuit?
One common cause of your program taking to long to execute a loop is too many debug statements. Are you using any anywhere else in your code?
BTW, the two relay bytes are deliberately interspersed in the serout command between PWMs 1, 2 and 3 to prevent 255s output to PWMs from causing problems in the most common cases where someone is using the default code (or has made minimal modifications to it.)
Actually, they are interspersed to prevent problems from occurring when both relay output bytes are 255. A change from 255 to 254 will make almost no difference with the analog PWM outputs, but changing this in a relay output would completely reverse one of the digital output pins, most likely causing very undesired operation. Also, if i remember correctly, the default code sets a maximum of 254 for all the PWM outputs it uses.
My guess is that somewhere else you are doing one of 5 things:
getting stuck in an infinite loop
taking too long on part of your code. This could be caused by a loop that is ran multiple times or from several debug statements
skipping over your serout statement
you are using the serout statement incorrectly.(i.e. outputting to the wrong pin, etc.)
not looping back to your serin command.
It is hard to say without seeing the rest of your code. If you could post all of the code, it would be very helpful in determining your problem.
