No announcement yet.

Sequencer Program

  • Filter
  • Time
  • Show
Clear All
new posts

  • Sequencer Program

    My team tried to create a sequencer program this season with poor results. They used a switch with each brick button starting a run, but the program failed to return after each run, so they had to restart the sequencer and choose the next program. I tried to create a sequencer that would use left and right buttons to choose programs and the center button to start the program. My idea was to display the current program, then use a switch to choose/start the next program. It is not working. I looked around and found other code showing using three separate switches, but I'm wondering WHY this isn't working and why three separate switches works better -- this seems simpler if I'm going to help 8-10 year olds figure this out . (The bottom-most switch would be where the different runs would go.) Thanks.

    Attached Files

  • #2
    I think the easiest way to write a sequencer is to run a different mission based on which of the 5 buttons is pressed. This requires one loop and one switch block. It sounds like this is what your team attempted without success. I don't understand your explanation for how it failed. Was there no loop around the switch block?

    A problem with the button switch sequencer is it is limited to 5 different missions. An easy way around the limitation is write a second sequencer for missions 6 through 10. Another way around the limitation is write a program that implements a menu. This was popular with NXT because it only requires three buttons and NXT only had three. One button to move to the next mission, one button to move to the previous mission, and one button to run a mission. This is a more complicated solution because it requires variables and some logic to handle the bounds problem. Other than that it is very similar to the button sequencer/selector.

    For young kids I would stick with a button/mission map type sequencer, especially since it sounds like they have already done most of the work.
    Last edited by Dean Hystad; 01-29-2018, 08:22 PM.


    • #3
      We had a set of display blocks telling what each button did followed by an unlimited loop block with the switch nested inside. After the first run was completed, it looped back to the switch block again, but the next run would always do weird things, like one of the driving motors wouldn't turn or something. We did not reset the motor rotation sensors back to 0 and we didn't set all the motors to coast in between runs, which I've only heard about since our season ended. That might have been the problem, but I don't know. I've already disassembled the team's robots to start fresh with my new set of kids, so I can't test it. Anything else we need to do to make something like that work?


      • #4
        Take a look at using Display Image instead of Display Text. You can create a custom image that organizes the mission names in the same order as the buttons, or better yet use pictures instead of text. Text is hard to read, but images are easier and quicker to identify. You probably should redraw the screen each time you run a mission. This lets you use the display for other purposes (like displaying debug info) and still have a fresh menu/flash screen when it is time to press a button.

        The controller does a lot of cleanup when you run a program. It resets the rotation sensors and the gyro angle. It resets timers. It resets the motors to coast. It forgets about anything that happened in a previous program. It turns motors off at the end of a program. When you write a sequencer you are responsible for doing all the cleanup. I like to put all this stuff in a my block that I call before and after I run a mission. I call it after I run a mission to set all the motors to coast. I call it before I run a mission to reset the motors, making them forget about any motion that may have occurred while preparing the robot for the next mission.

        This is a sequencer one of my teams used this year. Sequencers can be really simple.



        • #5
          I was thinking that an image would be easier to use than text, but hadn't thought about how to do it yet. I liked the simpler system where each button did a different run, too.

          I'm still curious though about why my program didn't work. I went back and it looks like I didn't add the image right, so here is a closer (hopefully clearer) view of where I think the problem is. I have the switch block set to Measure-Brick Buttons, with different cases for left, right, and center. What I've seen around the web is three separate switch blocks set to Compare - Brick Buttons. Please help me understand the reason why it didn't work. It just doesn't make sense to me. Thanks.
          Last edited by Tim Carey; 01-29-2018, 11:09 PM. Reason: Had to fix the link...


          • #6
            Thanks for the feedback. I hadn't thought of using an image instead of text, so we will look into that. I'm hoping that doing those resets will fix the problems we were having.

            Still, though, I don't understand why the switch block I had in there didn't function right. It never allowed me to switch from one program to the next. I could run the program with the center button, but it would not switch programs. I had the switch set to Measure - Brick Buttons. The other sequencers I saw as I looked into my problem all had multiple switches set to Compare - Brick Buttons. Any explanations would be appreciated.



            • #7
              The problem is probably that you didn't wait for the button to be released. Look at the attached program. What do you think is displayed if I start the program and press the middle button? If you said "I don't know" you are right. The result depends on how long I wait between starting the program and pressing the button. The count is usually up in the thousands before I can press the middle button. The reasons for this is because the default action for the switch is to increment the "Count" variable, and the switch block is being executed thousands of times a second. Most people writing programs that look like this are expecting the switch to wait for a button to be pressed. It doesn't. It peeks at the button state and executes some code based on what it sees.
              It is rare that you want to use the switch block with the brick buttons option. I don't think I've ever used it. Usually you want to wait for a button to be bumped (pressed and released) and then perform some action based on which button was bumped. This is what the code below does. I know the switch block doesn't wait, so I preface that block with one that does. I use the button output from the wait block to select which case to run in the switch block. Note that I don't have to worry about a default action because the button wait block is only satisfied by pressing the left, middle or right buttons, and the switch block has a case for each of those.

              Capture 2.JPG
              Last edited by Dean Hystad; 01-30-2018, 11:12 AM.


              • #8
                That makes sense. Thanks.


                • #9
                  So I'm trying again. All of our robots are half built as the kids are learning robot structure, so nothing to test this with... Took your suggestion about using the buttons to run programs still, but tried embedding another loop to include more mission runs if needed. Set the center button to go to the second loop. Inside second loop, I set the center button to interrupt the inner loop, which I think would take it back out to the main loop. I'm still new at this though, so I wanted a second opinion. Also drew a picture -- easier than I thought. I spent 10 minutes searching the help files on how to create an image file, then opened the image editor. Easy.



                  • #10
                    You don't need a robot to test this stuff. When my daughter's team wrote their first sequencer we did it as a music player. They made a play list and created sound files. If you can flip through a list of song names and play a sound file you can flip through a list of mission names and run a mission my block. This lets you get the menu stuff working without having to worry about resetting motors or gyros. Plus you can test with nothing more than the brick.

                    I don't like the image editor for drawing images. I use my favorite drawing tool to draw the image and save as a .png or .jpeg. I only use the image editor to import the image. Here is an image for a cascaded menu system that runs the rain cloud, faucet, fountain or flower missions. Pressing the bottom button brings up a second menu.

                    I is possible (and not terribly difficult) to make this kind of cascaded menu system remember what menu it was in instead of returning to the top level after each mission. In this example pressing "More" might display a menu for pipe repair, slingshot, tripod, fire and "Back". Pressing "Back" returns me to the menu where I can run the rain mission. Getting something like that to work is you next challenge



                    • #11
                      I don't think what I put together would return to the top level after each mission, just if the kids needed to go back to an earlier mission. If I did it the way I think I did, pressing the center button would swap back and forth between the two menus -- from the outer loop, it enters the inner loop, from the inner loop, it goes back to the outer loop. I'll add the sound files and check it at school tomorrow. You should have been a teacher (if you aren't in some form or other) -- I'm starting to feel like I have to study for a quiz...


                      • #12
                        My eyes are going. I didn't see the link. Yes, that will remain in the same menu until you press a button to back out. Since you got that, how about going for extra credit. Try giving the user visual queues that the program is waiting for a button press.

                        This stuff is kind of addicting, isn't it? I always encourage teams to expand their programming horizons. The very first program my girls wrote used two motors as joysticks to move an image around on the screen. Then we added a second image that moved randomly about the screen. if you superimposed the two images and pressed the middle button you scored a point. Eventually there were flash screens and sound effects and a leader board. Then the challenge was announced and we had to go back to boring old FLL programming.


                        • #13
                          Okay, so why stop at just visual cues?


                          Learning EV3 coding has been really therapeutic for me. It gives me a way to engage my mind in solving problems. It evolved from a way to do robotics with kids into a time consuming hobby for me. I'm an elementary school teacher, and I think I'm pretty smart, but this is something that I never learned how to do in HS/college/career prep, so the smallest discoveries are really rewarding for me. Things are starting to make sense, which means I can start helping my kids make sense of it too. My first year of coaching, it was truly a "Our coaches don't have all the answers, we learn together" year. I remember telling them when we started, "We're just going to stick to these green blocks. Maybe we can use some of the orange ones too. Just ignore the red ones -- I don't know why anyone would need a math block to move a robot around." Now, I think I'm in a position where I can help other coaches in my area with things. Pretty exciting for me.


                          • #14
                            Audible queues cannot be heard in a noisy FLL environment and haptic is probably a bad idea.

                            Keep discovering together. It results in a richer experience for all. My experience is that "teaching" FLL doesn't work. The kids get so much more out of FLL if you let them muck about and make mistakes and try some really dumb ideas. I've always thought technical literacy is a hindrance to being a good coach. It gets in the way of teaching what we really want to teach, problem solving and core values, by replacing it with teaching fairly worthless technical skills such as building and programming robots. I find myself biting my tongue and not expressing my opinions, and I think that can come across as being secretive or insincere. What I would give to return to blissful ignorance at the start of each season. These days I tell teams up front that I've been doing this longer than they have been alive but I'm not going to tell them what to do because they are supposed to solve the problems and their solutions may be better than what I would come up with.
                            Last edited by Dean Hystad; 01-31-2018, 02:08 PM.


                            • #15
                              Tried my program today and worked beautifully. Everything switched really quickly and easily. Loading my own pictures was easy too.

                              Three of the kids on my first team (the one where I said let's just use the green blocks) have moved on and are on a team at the middle school now. I was talking to one of their parents and the kids had finished last in the robot game at our qualifier this year and are getting dejected because they've had rookie coaches (including me) who didn't know how to support them.

                              I don't want to let kids get so frustrated that they can't feel some success and end up giving up on themselves.