Page 16 of 16 FirstFirst ... 61213141516
Results 151 to 157 of 157

Thread: robot goes backward instead of forward?

  1. #151
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Dean Hystad View Post
    Sensors will not help you make exact turns. You cannot make exact turns. Give up on trying. You need to accept that the robot will have error and your solution needs to compensate.

    You mentioned a problem with the pink bacteria dispensor. It usually works, but sometimes fails. With my team I have them record the failures and we look for a trend. We use the trend information to modify the mission and make it more robust. I think I would intentionally crash the robot into the dispensor and use the dispensor model as a navigational aid. I would use an attachment that would align the robot to the model when the collision occured. I would make the attachment so it could accommodate a lot of positioning error from the two turns and three straight moves I used to drive over to the dispensor. I would not try to make the robot more accurate. I would modify the mission so some innaccuracy doesn't matter.

    I have absolutely no idea what you are talking about with the white lines and logic block and following along white lines. I did not provide any programming example (picture) that could be used to follow white lines. I did supply an example where the robot would drive until the sensors see a line, but line following is much different and requires a different algorithm.

    Stopping a line following robot is a trick. Most folks use the rotation sensor feedback. Below is a simple proportional line follower that stops after one of the motors drives a specified number of degrees.

    RESET B Rotation Sensor
    BEGIN LOOP
    MOVE Unlimited, Steer = (Light Sensor - 50) * Gain
    END LOOP IF B Rotation Sensor > 1000 degrees
    STOP Motors
    IF sensor

    Your driving straight when trying to do a turn problem is just a matter of motor settings. If you are trying to turn, don't use a Move block that commands the robot to drive straignt. Either use a non zero turning value or do pivot turns (one wheel turns) using a Motor block. I do not think this will help you make EXACT turns. Exact turns are unattainalble.

    My boys thought you could just drive the robot around the mat and have success. They no longer think that way. It was hard for me, but I allowed them to fail so they could learn that using odometry (rotation information) is not reliable. The missions they had the best success with did not rely on any kind of accuracy. Next season I doubt they will rely on odometry for any of the missions.
    The problem is our robot makes large turning errors. This kept me worried. When we attached the hand for the rat and trailer, and then we assked the robot to drive straight and then make one turn. Sometimes it hits the trailer, while other times it hits the far off area before the slide of the rat!!

    Can you believe it that when I started doing it and writing the degree fior motor C turn, I started with 390 degrees and increased it slowly and slowly by about 20 degrees, and then 30 degrees, and then 50 degrees. Slowly and slowly till I reached 600 degrees. When I reached 600 degree turn for this turning, it worked once then it never worked again. I decided to choose lesss degrees. I started reducing it by 20 degrees, then by 30, then by 50, then by another 50 until I reachhed 390 degrees again where I just started from!!!! And it worked once, then it never worked. I gave up at the end, and decided not to take them both together. I mean it is a big range from 390 to 600 degrees!

    What does this mean? What do we rely on if not on Odometry? I still don't get it.

  2. #152
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Tom Mosher View Post
    The LOOP block provides several ways to exit. "time" and "number of loop counts" are not good exit methods for driving. Rotations could be useful, and logic gates along with some math blocks can used with many of the sensors providing the measurements.

    Moving based on time is a limited strategy, since the distance traveled will depend a lot on the level of battery charge.
    Even that we are using degrees and rotations only for our missions, but we noticed that missions differ, and the driving path of the robot differs based on the battery level. We it is fully charged the robot was mopving very fast on poiwer 100. When it was half full, the robot did not move fast with a poer of 100. This caused a lot of panic as we could not do the missions until we fully charged it.

  3. #153
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Dean Hystad View Post
    That's an odd prejudice. Were I to use line following in my solution (which I usually try to avoid), I would use whichever "feature" leads to to the areas I am interested in. I can program one or two sensor line following algorithms that work equally well for either. Only using the black "line" is just as limiting as thinking you have to use the lever on the bacteria dispensors.
    What do you mean by features?

  4. #154
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Tom Mosher View Post
    Oops, I used terms that were too limiting, I was writing in a rush. What I had in my mind (and didn't make it out through my fingers) was that the edge of the black line against the white background provides good contrast for the light sensor. Using the other edge of the white background, where the mat tends to be printed in colors other than black, might not be as readily useful. Edge tracking is a better description, rather than tracking the width of either a black or white line itself.

    I'm still trying to visualize what issue "guest2012" was working on. The white and black areas pretty much lead to the same places, plus or minus a couple of cm.
    We were trying to do two missions. One was the trailer with the rat, and the other one was the timer and thermometer.

    #1: For my surprise when going to the trailer, I tried to use sensors, and I could succesfully use the line tracking in the bfginning for white and black, but when we tried to make the left turn to the rat, the turning range was from 39 degrees to 600 degrees. I kep cchanging values from 390 to 600, and then back again from 600 to 390 degrees. The robot did REALLY drive me CRAZY. I did not know what to do so to make perfect turns, and still always do it correctly. I could not use sensors once it reached the other two white lines in front of the rat, because I wanted it to stop there , but every time it makes a different turn,. So, how am I supposed to ask it to stop there if the tuirning keepss on chaning. We could not do both of thgem together. This was my question about making perfect turns.

    #2: The other mission with the timer, we asked the robot to drive straight and then first take the viruses back to the sink. The problem we had is that the robot sometimes makes the correct turn to the sink, while other times it goes far to the other end near the red bacteria. I could not understand why it does this. One of my kids was doing it and she got really exhausted. When it did it correct, we asked it to continue driving towards the timer. When it reached that area, we asked it to fix its position looking for black and white. That was perfect using the logic block from Dean. And then I asked it to move on both whitee lines in that area next to the timer. The problem wee had is when the robot could not stop in that area when we asked it drive on both white lines. (By the way we are using 4 light sensors). And when I tried to use the line follower for black and white, we noticed that the rbot makes a big turn to adjust to next color and hits tha brown table. So, we could not use the line following on the way going to the timer. This was my other question for the line following.

  5. #155
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Tom Mosher View Post
    Without regard to whether these are good techniques, here are my thoughts.

    The "sensor4" example should remain in the loop until Sensor 3 is < Sensor 2. Being just one light sensor value out of 100 lower should cause the loop to exit. Simple measurement noise could be enough to cause that comparison to succeed, and exit the loop. That's a difficult situation, given that the mismatch between the two sensor might be as much as 5 to 10 counts.

    If both sensors are saturated on 0, or 100, then the loop will never exit.

    Verify that the sensor calibration is correct. I expect the loop as-written should be prone to exiting too early, rather than getting hung forever. Unless the sensors are saturated, that is.

    If you're trying to sense that both sensors see black, you can use the logic output of each sensor block, and connect the sensor logic outputs to a logic gate, connect the gate's output to the loop exit, to trigger when both sensors see black.

    For the "sensor5" program, it appears that once the line tracker loop exits, you want to then square to the line by detecting both sensors on White. Here's one possible method. Instead of the three MOVE blocks you show in the diagram, you could MOVE turn for approximately 90 degrees of heading change, then MOVE straight unlimited, followed by two WAIT blocks in sequence (one wait for each sensor to see WHITE). That's just an example, it's not a very robust algorithm, but it will get you thinking. Or, you could use another of your loops like the sensor 4 example.

    A mission can be viewed as series of separate tasks. Each small task has to be thought out and considered carefully.
    The sensor4 program keep driving oin the white linen forever, and I could not stop it. I know iot is a weak technizue to ue one light sensor to drive on a line. But the sensor5 program was a line follower, but the problem it moves slowly, and it is no good for making turns after that because it might stop closer to the right, or closer to the left as it is following the black and white lines. Because after driving straight we wanted it to turn and go get the rat and the trailer. Buut anyways a 390 to 600 degree turningh difdference was a huge difference, and we could not do both of them together.

    Anyway, I wish my kids had enough practice on doing all the missions before going to the match. One of my kids started acting dump at the match, and forgot to return back the baby fish, or even to take the pink bacteria. We had all the missions in order, and I could not use the "presss NXT button" because one of the missions might not work well on first try, and then they had to repeat the mission. I chose two of my students to do the 3 rounds, but one of them did not want to continue after the first round, and was so tensed. She is the one who knows all the missions in order. The oither students who was excellent in programming acted really dump in the 2nd and 3rd rounds without her best friend next to her. She kept forgetting to do some missions, or she positioned the robot so incorrectly for a number of missions, or raised the arm for the groceries very high up manually, even though we programmed the robot to raise it up automatically. I was surprised by the way she acted, but I think she was scared, and getting very tired plus tensed.
    Last edited by guest2012; 05-04-2012 at 02:38 AM.

  6. #156
    Join Date
    Sep 2008
    Location
    Minnesota
    Posts
    2,562

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by guest2012 View Post
    The sensor4 program keep driving oin the white linen forever, and I could not stop it. I know iot is a weak technizue to ue one light sensor to drive on a line. But the sensor5 program was a line follower, but the problem it moves slowly, and it is no good for making turns after that because it might stop closer to the right, or closer to the left as it is following the black and white lines. Because after driving straight we wanted it to turn and go get the rat and the trailer. Buut anyways a 390 to 600 degree turningh difdference was a huge difference, and we could not do both of them together.

    Anyway, I wish my kids had enough practice on doing all the missions before going to the match. One of my kids started acting dump at the match, and forgot to return back the baby fish, or even to take the pink bacteria. We had all the missions in order, and I could not use the "presss NXT button" because one of the missions might not work well on first try, and then they had to repeat the mission. I chose two of my students to do the 3 rounds, but one of them did not want to continue after the first round, and was so tensed. She is the one who knows all the missions in order. The oither students who was excellent in programming acted really dump in the 2nd and 3rd rounds without her best friend next to her. She kept forgetting to do some missions, or she positioned the robot so incorrectly for a number of missions, or raised the arm for the groceries very high up manually, even though we programmed the robot to raise it up automatically. I was surprised by the way she acted, but I think she was scared, and getting very tired plus tensed.
    Practice is pretty important. My girls hated practice. Once a mission was working they lost interest in it. Their lack of practice lead to a lot of wasted time and a lot of mistakes on the table. Fortunately for me they are unflappable and always recovered well. Eventually their dislike for practice and knowledge of it's results lead them to create solutions that were very user friendly. At the US Open our alliance partners got better scores running our robot than we did.

    One of the most common weaknesses I see in FLL teams is poor debugging skills. When the robot acts strangely many teams have no procedure for isolating and correcting the problem. They flail away trying this and that, not knowing what they may find, not making careful observations, and eventually reaching a point where they are frustrated and the robot may be worse off than when they started.

    First rule in debugging - Have a plan.
    Take some time to plan. Record what the robot is currently doing. Everyone has cameras capable of taking video, so take a video of the robot for comparison sake. Write down a description of the problem. Do not use vague words like "Freaks out". Be precise. "The 2nd turn varies from 30 to 600 degrees" is a good description.

    Once you describe the problem take time and document your plans to isolate and repair. "We think the problem is A. We are first going to try changing Z and see what effect that has."

    Run experiments more than once. I had a hard time pounding this into my boy's heads. One run does not a trend make. After you make a change run the robot multiple times to make sure any new behaviors are not flukes. When you've run the robot enough to know what is a fluke and what is a trend, record your observations. In my professional life I have solved many problems while reading through my debug log. An observation made 3 days ago may become very important when paired with insight gained today.

    Second rule in debugging - Do no harm.
    You have a program that sometimes works, or maybe even usually works, but has some undesirable behaviors. This is better than nothing. Make sure you don't lose it. Back everything up to a flash drive or a zip file or another directory before you start debugging. With a backup you always have a fallback AND it is often informative to compare the old software against the new.

    After backing up, my girls "versioned" the modules in question. Using the file manager or "Manage Custom Palette" they copied the old program files and gave them a new name with a version number. In the new file they wrote an introductory comment describing the purpose of the new version. Something short like:

    "Mission gets the pink bacteria. Pervious version failed we think because the 2nd turn acted randomly."

    Third rule of debugging - Divide and conquer.

    It is really hard to see the one or two problems a robot may have when you ae watching it do 20 other things. Break down the problem to the smallest piece that still exhibits the bad behavior. My girls broke all missions up into logical subparts that they implemented in MyBlocks. Their last year they had a mission that did a big arc turn and grabbed some multi-colored loops, then grabbed a loop that was sitting on a table, then released a truck sitting atop a ramp, and finally returned to base. Opening the program that executed the mission you would see 5 or 6 blocks. "Rainbow Hoops", "Table Hoop", "Truck Ramp", and a couple of turns and straights to return to base. Not only did the MyBlocks make it really easy to read the program, but it broke the mission into parts that could be tested independently. If they had a problem with the "Table Hoop" part they could download and run that part by itself.

    Fourth rule of debugging - Pause for contemplation
    My girls wrote a Debug Myblock. It displayed the rotation and light sensor values and did a wait for Enter button bumped. They sprinked these around inside their programs anywhere the robot did something strange. Quite often they were surprised to find that the problem was not with the 4th block in the program, but rather with the 3rd or 5th. This becomes a lot easier to see when the robot stops and waits.

    Hopefully this will be useful. I don't really know if it is or not. I spent a lot of time getting my teams to be calm and to always be making observations. From the start I de-emphasized the importance of table runs. The important stuff was the work we were doing leading up to the tournament. If the robot freaks out, stay calm, be observant and do your best to recover.

    One last note. I don't believe in operator error. If you design missions that are easy to mess up it is a failure of of mission design, not the operator. Most of the problems you see tournament day are not the fault of the operator and they did not happen on tournament day. Most problems you see tournament day started three months ago when you began designing the solution. They were perpetuated through numerous modifications and countless rounds of testing. In other words, the team is responsible for all successes and the team is responsible for all failures.
    Last edited by Dean Hystad; 05-04-2012 at 06:54 AM.

  7. #157
    Join Date
    Feb 2012
    Posts
    121

    Default Re: robot goes backward instead of forward?

    Quote Originally Posted by Dean Hystad View Post
    Practice is pretty important. My girls hated practice. Once a mission was working they lost interest in it. Their lack of practice lead to a lot of wasted time and a lot of mistakes on the table. Fortunately for me they are unflappable and always recovered well. Eventually their dislike for practice and knowledge of it's results lead them to create solutions that were very user friendly. At the US Open our alliance partners got better scores running our robot than we did.

    One of the most common weaknesses I see in FLL teams is poor debugging skills. When the robot acts strangely many teams have no procedure for isolating and correcting the problem. They flail away trying this and that, not knowing what they may find, not making careful observations, and eventually reaching a point where they are frustrated and the robot may be worse off than when they started.

    First rule in debugging - Have a plan.
    Take some time to plan. Record what the robot is currently doing. Everyone has cameras capable of taking video, so take a video of the robot for comparison sake. Write down a description of the problem. Do not use vague words like "Freaks out". Be precise. "The 2nd turn varies from 30 to 600 degrees" is a good description.

    Once you describe the problem take time and document your plans to isolate and repair. "We think the problem is A. We are first going to try changing Z and see what effect that has."

    Run experiments more than once. I had a hard time pounding this into my boy's heads. One run does not a trend make. After you make a change run the robot multiple times to make sure any new behaviors are not flukes. When you've run the robot enough to know what is a fluke and what is a trend, record your observations. In my professional life I have solved many problems while reading through my debug log. An observation made 3 days ago may become very important when paired with insight gained today.

    Second rule in debugging - Do no harm.
    You have a program that sometimes works, or maybe even usually works, but has some undesirable behaviors. This is better than nothing. Make sure you don't lose it. Back everything up to a flash drive or a zip file or another directory before you start debugging. With a backup you always have a fallback AND it is often informative to compare the old software against the new.

    After backing up, my girls "versioned" the modules in question. Using the file manager or "Manage Custom Palette" they copied the old program files and gave them a new name with a version number. In the new file they wrote an introductory comment describing the purpose of the new version. Something short like:

    "Mission gets the pink bacteria. Pervious version failed we think because the 2nd turn acted randomly."

    Third rule of debugging - Divide and conquer.

    It is really hard to see the one or two problems a robot may have when you ae watching it do 20 other things. Break down the problem to the smallest piece that still exhibits the bad behavior. My girls broke all missions up into logical subparts that they implemented in MyBlocks. Their last year they had a mission that did a big arc turn and grabbed some multi-colored loops, then grabbed a loop that was sitting on a table, then released a truck sitting atop a ramp, and finally returned to base. Opening the program that executed the mission you would see 5 or 6 blocks. "Rainbow Hoops", "Table Hoop", "Truck Ramp", and a couple of turns and straights to return to base. Not only did the MyBlocks make it really easy to read the program, but it broke the mission into parts that could be tested independently. If they had a problem with the "Table Hoop" part they could download and run that part by itself.

    Fourth rule of debugging - Pause for contemplation
    My girls wrote a Debug Myblock. It displayed the rotation and light sensor values and did a wait for Enter button bumped. They sprinked these around inside their programs anywhere the robot did something strange. Quite often they were surprised to find that the problem was not with the 4th block in the program, but rather with the 3rd or 5th. This becomes a lot easier to see when the robot stops and waits.

    Hopefully this will be useful. I don't really know if it is or not. I spent a lot of time getting my teams to be calm and to always be making observations. From the start I de-emphasized the importance of table runs. The important stuff was the work we were doing leading up to the tournament. If the robot freaks out, stay calm, be observant and do your best to recover.

    One last note. I don't believe in operator error. If you design missions that are easy to mess up it is a failure of of mission design, not the operator. Most of the problems you see tournament day are not the fault of the operator and they did not happen on tournament day. Most problems you see tournament day started three months ago when you began designing the solution. They were perpetuated through numerous modifications and countless rounds of testing. In other words, the team is responsible for all successes and the team is responsible for all failures.
    Thanks for the debugging information. We always keep the old versions of our programs, and then work on a newly saved version. Because we might sometimes get back to it at any time. I liked how you organized your thoughts. It's a useful technique.

    For the team work, I agree that everyyone is responssible, but these programs always worked for us. I was very confident of these misssions, but somemissions the robot should go straight, or the arm of the groceries should not be touched. I understand they needed more practice. I actually ran into the table in the third round, and said: "Return the baby Fish, do the pink bacteria". It was really embarrassing, and I am pretty sure that the referee has heard me, but I just could not control it. The problem is that the girl who was doing all the missions during the match, did not learn well how her friends positioned the robot for the other missions. I know I should have let her practice before, and this was one mistake I've done, but her thoughts were very limited to doing the timer mission. It was the last mission, and every time she turned the robot to do it. I understand that she worked hard on it, but I should have made it clear that these missions would give us more pints. She did not wait for her friend to finish putting the groceries in the first round because she wanted to do the timer, and this is why her friend was upset. She is an extremely determined student, which I really like about her, but sometimes we look for points that would add up to the total, and not be in rush because of time. Plus the other thing I said about not practicing enough. I personally tried the yellow truck 10 times, and it always worked. We tried all the missions before the match, but I should have asked her to stop working on the timer, and do more practice instead of that so to better know the order and the positioining of the missions. But still I know she is still a kid, and we all do mistakes, and I understand the panic when everyone is relying on her. I wouldn't blame her.
    I'm not saying that we would have won, but at least we would have got a better score. Better than whatever I thought of. I know what was working for us. Anyway, I just learned a lot of things, and I honestly spent nights and days isolated from the real world. It was exciting and enjoyed learning something new, but does not get me any benefit for my own working field.
    Last edited by guest2012; 05-04-2012 at 02:23 PM.

Page 16 of 16 FirstFirst ... 61213141516

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Rule 18/Touch penalty interpretation for a 2-part robot
    By JohnMcDonnell in forum Rules & Missions
    Replies: 6
    Last Post: 12-12-2011, 01:51 PM
  2. Points from last year
    By natterbus in forum Robot Game Strategy
    Replies: 15
    Last Post: 09-24-2011, 10:07 PM
  3. Suspending on Platform
    By william_edds in forum Game Strategy
    Replies: 2
    Last Post: 01-16-2010, 09:15 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •