Announcement

Collapse
No announcement yet.

Data wires control scheduling

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Data wires control scheduling

    This topic may be a little weak because most of my efforts are devoted to writing the Quick Sort algorithm in NXT-G.

    Everyone knows that data wires pass data, but many programmers don't realize that they also affect scheduling. A NXT-G block executes ONLY when data has been received on all its wired input plugs. For purposes of scheduling you can treat the sequence beam as a fat data wire.

    Attached file "Parallel Tasks" is a common use for parallel beams; controlling the attachment motor while simultaneously driving the robot. This works fine, but as pointed out in this thread (http://forums.usfirst.org/showthread.php?t=19458) it is very easy to mess up the attachment points for the parallel beams.

    In a post from last year I discussed various ways to synchronize parallel beams. The method I find the most elegant is to use the scheduling power of data wires. In the attached file "Data Wire Scheduling", the arm motions are synchronized with the robot base motion not by the relative position of the blocks, but by the data wire running from the constant blocks in the main beam to the motor blocks in the parallel beam.

    image_3011.jpgimage_3012.jpg
    Last edited by Dean Hystad; 02-14-2018, 11:43 AM.

  • #2
    Re: Data wires control scheduling

    Thanks for the parallel beams pic! This is going to solve a lot of problems for us. I didn't know you could do that. Now...how did you do that? . Do you just click where you'd like a parallel beam to drop down and drag?

    I'm really showing my inexperience here, but we would pull down the parallel beam at the beginning of our program and insert a wait block on the parallel beam to wait a certain time period before moving an attachment.

    I like the second idea better. We have not yet learned data wires, but I've been researching some of the more advanced programming blocks and have been thinking about beginning to introduce them to my kids as things like this come up.
    Last edited by RVDHRobotics; 09-17-2012, 10:03 PM.

    Comment


    • #3
      Re: Data wires control scheduling

      Originally posted by RVDHRobotics View Post
      Thanks for the parallel beams pic! This is going to solve a lot of problems for us. I didn't know you could do that. Now...how did you do that? . Do you just click where you'd like a parallel beam to drop down and drag?

      I'm really showing my inexperience here, but we would pull down the parallel beam at the beginning of our program and insert a wait block on the parallel beam to wait a certain time period before moving an attachment.

      I like the second idea better. We have not yet learned data wires, but I've been researching some of the more advanced programming blocks and have been thinking about beginning to introduce them to my kids as things like this come up.
      You can branch anywhere off a sequence beam by placing the cusor over the sequence beam and pressing the shift key. When the cursor changes to the wiring tool you can draw a branch.

      I do not think the first way is a good way to do parallel tasks. It is very common, but it is not a good idea. The NXT editor does not move the branches when you add or remove blocks and it is really easy to get things messed up. Branching from the start point and synchronizing with wires is MUCH better. Even if you change the relative position of blocks between the two beams the sequencing of the moves remain correct.
      Last edited by Dean Hystad; 09-18-2012, 12:50 AM.

      Comment


      • #4
        Re: Data wires control scheduling

        Originally posted by Dean Hystad View Post
        This topic may be a little weak because most of my efforts are devoted to writing the Quick Sort algorithm in NXT-G.
        You are my hero

        Originally posted by Dean Hystad View Post
        In the attached file "Data Wire Scheduling", the arm motions are synchronized with the robot base motion not by the relative position of the blocks, but by the data wire running from the constant blocks in the main beam to the motor blocks in the parallel beam.
        This may mark the first time that I show my teams how parallel execution can be useful.
        Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

        Easy data-logging and graphing for NXT-G.

        Comment


        • #5
          Re: Data wires control scheduling

          Dean this tips and tricks you are putting up are awesome. I have learned a ton from you already this season. Thank you!
          Coaching the Flamingos since 2004!
          Team #79 - The Blue Cheesy Flamingos
          https://www.facebook.com/KalamazooFLL
          http://www.KalamazooRobotics.org

          Comment


          • #6
            Re: Data wires control scheduling

            Originally posted by BlueCheesyFlamingos View Post
            Dean this tips and tricks you are putting up are awesome. I have learned a ton from you already this season. Thank you!
            The community definitely needs to make an effort to preserve this type of knowledge between seasons.
            Programming videos for FLL. (I don't like the videos that much and will be replacing them soon-ish)

            Easy data-logging and graphing for NXT-G.

            Comment


            • #7
              Re: Data wires control scheduling

              It would be great if after this season is over a "master" thread was started that basically just had the list of all these great posts in one place. Too bad you can edit the post at any time then it could be an ever growing list.
              Coaching the Flamingos since 2004!
              Team #79 - The Blue Cheesy Flamingos
              https://www.facebook.com/KalamazooFLL
              http://www.KalamazooRobotics.org

              Comment


              • #8
                Re: Data wires control scheduling

                Originally posted by BlueCheesyFlamingos View Post
                It would be great if after this season is over a "master" thread was started that basically just had the list of all these great posts in one place. Too bad you can edit the post at any time then it could be an ever growing list.
                I disagree. I see no value in building up a repository of NXT programming or robot building knowledge. Building and programming autonomous robots using a children's toy is hard, and being hard is what makes it so much fun. Building and programming are not problems I wish to solve, rather I hope they are problems that live in perpetuity.

                What I've been doing this last week is an experiment. I'm hoping that I'll write something that sparks an idea in somebody else. They refine and post their new idea that spark other ideas. By the end of the season I hope to be a minority contributor.

                A beauty of this forum is it's transient nature. Like the new challenge we (usually) get a new forum each year. New members, new ideas. What if I don't like how my sharing affects the community? What if my actions stifle creativity instead of fostering it. I find a lot of comfort in knowing that next year we start again with a clean slate.

                Comment


                • #9
                  Re: Data wires control scheduling

                  A question about line following brought up some issues I didn't cover very well in this thread. The data storage features of wires, and the way wires control scheduling can lead to unexpected, but completely predictable behaviors.

                  Take the attached program for example. In this program there are two loops running on two beams. One increments a variable and exports the value of the variable via a data wire. The other loop displays the value in the data wire five times, one value per display row. What would you expect to see on the display?

                  Wires Control Sequence.jpg

                  Quite a few people would say that the results are undefined. There is no synchronization between the two loops so there is no way to know what the value of the variable will be when the display block is called. Others might say the display will show:

                  1
                  2
                  3
                  4
                  5

                  Both these answers are wrong. The correct answer is:

                  5
                  5
                  5
                  5
                  5

                  The reason behind the answer is complex, but completely predictable.

                  The pretty orange rectangle surrounding loops or switches isn't just for looks. It defines a boundary to a NXT software module. That module has the same characteristics and behaviors as a MyBlock.

                  1. It has input plugs (wires coming in)
                  2. It has output plugs (wires going out)
                  3. It doesn't finish execution until all blocks in the enclosed sequence have finished
                  4. It doesn't run until all input data wires have been assigned values.
                  5. Input values are "frozen" at the point in time when the module begins execution.
                  6. Output values are not assigned until the module has completed execution.

                  Lets see how these rules control the sequence of execution in the example.

                  The display loop has an input data wire. It cannot execute until a value is assigned to the wire.
                  The data wire comes out of the increment loop. It is not assigned a value until the loop is done.
                  The loop is not done until the contents have finished. This includes waiting for the exit control. Here the loop is not done until it runs 5 times.
                  The value of the Count variable is 5 when the loop is finished. The output data wire value is set to 5.
                  The display loop can begin running now that the input wire's value was set to 5.
                  The display loop draws the number 5 on the top five rows of the display.

                  Complex, but completely predictable.
                  Attached Files
                  Last edited by Dean Hystad; 02-14-2018, 11:38 AM.

                  Comment


                  • #10
                    Re: Data wires control scheduling

                    Interesting. Now could this issue be worked around with reading/writing variables in each loop with the values?
                    Coaching the Flamingos since 2004!
                    Team #79 - The Blue Cheesy Flamingos
                    https://www.facebook.com/KalamazooFLL
                    http://www.KalamazooRobotics.org

                    Comment


                    • #11
                      Re: Data wires control scheduling

                      Originally posted by BlueCheesyFlamingos View Post
                      Interesting. Now could this issue be worked around with reading/writing variables in each loop with the values?
                      I don't know that this is an "issue" in the typical sense, but it can be very confusing. Unfortunately any other behavior I can think of isn't deterministic and would be confusing to the point of uselessness. If I replaced the data wire with a "Count" variable block in the Display loop the result is undefined and possibly different each time the program is run.

                      If you want access to dynamic data from inside a MyBlock, loop or switch a variable is the way to go. If you don't want to worry about inputs changing while a block executes, data wires are the way to go. Each has its uses.
                      Last edited by Dean Hystad; 10-03-2012, 12:47 AM.

                      Comment


                      • #12
                        Re: Data wires control scheduling

                        Data wires work fine for synchronizing parallel beams, but they don't work for synchronizing the interior sequences of loops, switches or MyBlocks. For that variables are the only choice.

                        To use a variable for synchronization you'll have to write code to initialize the variable, code to wait for the variable to be set to some value, and code to set the variable's value. A variable that has these behaviors is called a semaphore, and the behaviors are usually called Clear, Wait and Set. If you want to use variables for synchronization it makes sense to encapsulate these behaviors with the variable and provide an easy to use interface.

                        The attached file Semaphore is a binary (two value) semaphore written in NXT-G. It uses a variable to hold the semaphore value and a switch to implement the semaphore actions. I added a forth action, Wait and Clear, because I noticed a common use pattern was a Wait semaphore block followed immediately by a Clear semaphore block. The semaphore block is a template (http://forums.usfirst.org/showthread.php?t=19540) meaning that if you need three semaphores you'll have to make three different versions of this MyBlock, each using a unique variable.

                        Using the semaphore blocks I rewrote a code example from earlier in this thread that pointed out an interesting behavior of data wires passing in/out of loops. The semaphore allows synchronizing the sequences inside the loops and produces the output:

                        1
                        2
                        3
                        4
                        5

                        image_3077.jpgimage_3078.jpg
                        Last edited by Dean Hystad; 02-14-2018, 11:39 AM.

                        Comment


                        • #13
                          Re: Data wires control scheduling

                          A big advantage to the upcoming EV3 software is that the input data plug values are visible all the time. Users of NXT-G won't have that feature and end up having to make trade-offs. In my previous post I designed a semaphore block. Programs may have multiple semaphores, so I created multiple copies of the MyBlock with different names for each semaphore. Sem A, Sem B and so on. Each block implement all semaphore behaviors (set, clear, wait) for a particular semaphore. This is shown in attached Semaphore Example.jpg.

                          A problem with this approach is the block's behaviour is defined by an input plug, and because of that you cannot tell what any individual semaphore block is doing without selecting the block and looking at the input values. I decided to rewrite the semaphore as a group of blocks that implement actions instead of represent a semaphore. In the new block the semaphore used is set via an input plug. I wrote the block to support up to 4 different semaphores. This example is shown in attached Semaphore Example 2.jpg.

                          The question is, which is easier to read? Is it better if the graphic represents the object or the action? Or should I go all the way and create special MyBlocks Sem Set A, Sem Set B, Sem Wait A, Sem Wait B? The last results in programs that are really easy to read but creates a maintenance nightmare.

                          I'm really looking forward to arrays in EV3.

                          image_3078.jpgimage_3195.jpg
                          Last edited by Dean Hystad; 02-14-2018, 11:39 AM.

                          Comment


                          • #14
                            Re: Data wires control scheduling

                            Originally posted by Dean Hystad View Post
                            The question is, which is easier to read? Is it better if the graphic represents the object or the action?
                            I think it is clearer at first glance if the graphic represents the action instead of the object.
                            Originally posted by Dean Hystad View Post
                            Or should I go all the way and create special MyBlocks Sem Set A, Sem Set B, Sem Wait A, Sem Wait B? The last results in programs that are really easy to read but creates a maintenance nightmare.
                            If an FLL team ends up needing a multitude of semaphores in their programs, they may wish to rethink their programming approach. I'm sure you have a good example where they are needed, but for my experience in FLL, when I started to see the need for semaphores in a program, I encouraged the kids to approach the program in a different way.
                            Originally posted by Dean Hystad View Post
                            I'm really looking forward to arrays in EV3.
                            Arrays will let you implement that Quicksort routine we've been anxiously waiting for. ;-)
                            What other places in programs for FLL do you envision a good use for arrays?

                            Comment


                            • #15
                              Re: Data wires control scheduling

                              Originally posted by timdavid View Post
                              What other places in programs for FLL do you envision a good use for arrays?
                              Filters, storing calibration information for multiple sensors, storing mission names for a mission sequencer. Once I have them I'm sure I'll find ways to use them.

                              As for multiple semaphores, the only way to guarantee multiple sequences or threads don't run at the same time is for each to be blocked by a semaphore. For two beams that means two semaphores.

                              Comment

                              Working...
                              X