GP Player pause problems

Lynxmotion Electronics & Software
1

Hi All,

I’ve been playing around with the GP player and bumped in some strange issues.

I’ve made a project with 2 sequences.
Seq 0 has got 28 steps and works perfect with the GP Player
Seq 1 has got 35 steps but starts with a really long pause.

When I use the Sequencer Control Panel in SEQ Sequencer and start sequence 1 at 100% speed the status box is giving me the following information:
Status (QPl0) from 34 to 0, 25500mSec.
The time stays the same for a couple of seconds and then it starts to drop down. When it hits 0 the step will change to 1 to 2 and the sequence starts at normal speed.

This problem doesn’t occur in sequence 0. When the player starts the box shows:
Status (QPl0) from 27 to 0, 0mSec.
The sequence starts right away!

I’ve checked all timers to see if I overlooked a timer but all timers are between 300 and 500 mSec.

I’ve also tried starting at the 2nd step (step 1). The sequence starts right away but the pause is moved to the end of the sequence.

No idea what I’m doing wrong…

All suggestions are welcome!

Xan

2

Hi Xan,

I have not played much with the sequencer, but if you send me the sequence I can try it out and see if I notice anything. I have my 2nd SSC-32 free now as I am no longer using it in the rover…

Kurt

P.S. - How is the free time coming? :laughing:

3

Hi Xan,

Do you have the same trouble when playing the same sequence directly from Visual SEQ?

I would also like to see the project files.
BTW, did you made the sequences with PEP? :wink:

4

Hi Guys,

Since V2.0 is fully bug free at the moment. Thanks to you Zenta! I’ve started adding the GP Player and made some fun sequences using the PEP. The Tool is truly awesome! I love it how I can step back and forward trough each of the steps and fine-tune them when needed! 8)

Ok, back to the problem; I’m having the same problems when I start the sequence from the BAP and from Visual SEQ. I proberbly messed something up because I’ve been copy pasting stuff around… LOL

I’ll send both of you guys a copy when I get home. I’ll be online this evening. (afternoon for you Kurt :wink:)

Thanks for the help!

Xan

5

Yesterday, Zenta and I did some tests concerning this issue. I gave Zenta a copy of my PEP and to check what happens on his setup. This is what we did:

  1. We playing the sequence directly from the PEP. Everything was fine.
  2. The next thing we did is made a export to the Visual Sequencer. All ok when playing the sequence using the sequencer module in Visual Sequencer.
  3. We’ve opened the GP Sequencer menu and wrote the sequence to the SSC EEPROM. While using the GP Sequencer control panel to start the sequence the pause occurred. We’ve tried different speed settings but without any success.
  4. When starting from the 2nd step the pause was gone. Even looping was ok at this point.
  5. We’ve connected the SSC to the botboard and send the command “PL0SQ1ONCEâ€
6

I just checked what version I used, my SSC32 board are updated with the v2.02GP :wink:

7
8

Hi Xan,

I know that Mike is the best person to look at this. I took some quick looks, but did not see anything obvious. I may play around more with reexporting the stuff from PEP. The CSV file I looked at did not match what was in the PEP excel export section…

From your debugging sessions, it sounds to me like it might be some boundary condition or timing issue.

When you run seq and load the stuff from the EEPROM, what is the starting address for sequence 1, when it is not working properly? If you use the Hex/Ascii editor in seq if you look up at the time value at the start does it match the time value that was in PEP?

Sorry I am not much more help here.

Kurt

9

We (I) tried that too and it didn’t make any difference.

I’ve also been thinking of just making another sequence in Visual SEQ with 35 steps to see if that is a “magic” number. The only thing we did to make the bug disappear was to add a step (append a copy of the last step).

We’ve to see if I or Xan get any time next week to test out your other suggestions.

10

Hi Mike,

Thanks for jumping in to this. We really appreciate it and make sure we do the given tests as soon as we’ve got some free time.

I did noticed something else while uploading it last week. It seems that the problems is ONLY solved when a new step is added at the end in Visual Sequencer. If the extra step is added in the middle (insert step) or if the step is added in the PEP the problem isn’t solved…

Hi Kurt,

The Visual Sequencer makes it possible to read the EEPROM to check if the values are ok. They where exactly the same.

Thanks guys!

Xan

11

Great trouble shooting. I wonder if this problem is due to large sequences only? 34 steps is rather long. The largest sequence I ever created was 12 steps. I wonder if the issue is cause by large number of seq steps?

Anyway good work so far.

12

Hi Xan,

Sorry I don’t have any good clues yet. What I was wondering before is if the Time value that was stored at the beginning happened to be positioned at some boundary condition. For example the GP sequencer document mentions about 16 byte boundaries. Sometimes with problems like this the memory dumpers don’t show it up as they are written to read in the EEPROM in an optimal way (I have been bitten on another project) by something like this… But from your last post I don’t think so.

It sounds more like some form of overflow or the like as Mike mentioned. You mentioned that if you add a step at the end with PEP it still shows the problem, but if you add it with SEQ it fixes it. Does this work the same if you turn off the board, turn it back on, and then start up SEQ again to try the sequence? If this is true it semi implies that something is written differently to the EEPROM. Would be interesting to get a dump of both cases and see if there are any differences.

Again sorry I have not come up with anything concrete.

Kurt

13

Hi Guys,

Thanks for the suggestions! I’ve spent my evening testing the GP player to see if we can get some aswers. I’m referring to the questions posted by Mike.

  1. Adding or removing a step in the middle of the sequence doesn’t make a difference. Adding a step at the END of the sequence does solve the problem.
  2. Excel makes it pretty easy to reverse the sequence. The end result is still the same though.
  3. Starting the sequence with another speed then 100% does effect the time. It looks like it just takes longer but it’s hard to see since it stays at the max value of a byte for long (255(00)). The pause doesn’t occure if the sequence is started in reverse!
  4. If I start from step > 0 everything seems to be fine now. It’s a bit strange because I thought we’ve tried that but without any success. I’ve written it down in step 6. Can you fill me in Zenta? I’m beginning to doubt myself… :wink:
  5. Only the first time! Good point!
  6. It’s been at sequence 1 and 6 already (starting from seq 0). Same problem. It has always been the last seq though. So I swapped sequence 5 and 6. The problem moves with the sequence and is located in seq 5 now. Seq 6 is fine.
  7. The pause doesn’t occur when the speed is changed from -100 to 100 when prev step is 34 and next step is 0.

Although I can’t find what it is I think it has something to do with the last step. The problem stays when there is a additional step added in the PEP. But when there is a extra step added to the END of the sequence using the Visual Sequencer everything is solved. So I duplicated the last step by pushing the “+â€

14
15

Hi Mike,

I totally agree that reproducing the problem is mostly a hell of a deal. So I’m happy to hear that part is done :wink:

I’m really exited about what is causing this. Again, thanks for looking in to this! I really appreciate it!

Xan

16

All fingers crossed for you finding the “bug”. :wink:

Good luck!

17

OK, I think I know what the problem is. It is related to the algorithm for making the first move when a sequence is started. I tried to be clever and ended up causing this issue.

In the sequence with the problem, step 35 and step 0 have almost exactly the same servo positions. In moving from step 35 to step 0, only 6 servos move and they only move by 1us each. In other words, the total move “distance” is 6 (the sum of the move distance of all the servos). The move time is 300ms. This tells the SSC-32 that the intention is for this step to proceed slowly in terms of servo speed.

When the sequence is started, the SSC-32 adds up the total move distance from the current servo positions to the target position. It then uses this number, combined with the total move distance and move time from the sequence, to determine the move time to the start position. The equation for move time is
==> t = seq_move_time * actual_distance / seq_distance
where
==> t = move time
==> seq_move_time = total move time from the sequence
==> seq_distance = total move distance from the sequence
==> actual_distance = total move distance from current position to start position

For example, suppose the servos are at the positions of step 35, except that servo 0 is at 1620 (the sequence has #0 at 1500 in step 35). Then we would have
==> seq_move_time = 300
==> seq_distance = 6 (6 servos move 1us each)
==> actual_distance = 126 (#0 needs to move 120, 6 other servos need to move 1 each)
and the calculated move time would be
==> t = 300 * 126 / 6 = 6300ms = 6.3 seconds

Thus, there would be a 6.3 second move at the start of the sequence as the servos got to their initial position. Now suppose that several servos are away from the step 0 position. The startup move time would be very large. The SSC-32 limits the startup move time to 60 seconds, and the QPL command can only return up to 25.5 seconds.

To illustrate this, try the following commands:
SQ6 IX35 (goto step 35)
PL0 SQ6 (start the sequence, plays with no pause)

SQ6 IX35
#0 P1620 (move servo 0 to 120 away from start position)
PL0 SQ6 (approx 6 second delay as servo 0 slowly moves to position)

SQ6 IX35
#0 P2000 (move servo 0 to 2000 away from start position)
PL0 SQ6 (approx 25 second delay as servo 0 slowly moves to position)

(In the last example, 300 * 2006 / 6 = 25300ms = 25.3 seconds.)

The calculation that is causing trouble when starting sequences is actually very useful during a sequence, when changing the speed. It does a good job of estimating the time to complete a move at the new speed. But I shouldn’t have used it for starting a sequence.

So, in summary, I think I know what the problem is. But I am not sure of the best way to resolve it. This post is getting long, so I will follow up with another post asking about how the time should be calculated for the initial move when starting a sequence.

Mike

18

So the question raised in my previous post is, what move time should be used when starting a sequence, to move the servos to the first step? Here are some possibilities:

  1. As fast as possible, limited by the max speeds from the sequence
  2. Use the move time from the sequence, adjusted by the speed multiplier
  3. Use a fixed time, say 100ms, 500ms, etc.

I like option 1 above. If the user wants a controlled move to the starting position, then he can use
SQ6 IX0 T1000
or something like that before starting the player.

Opinions please.

Thanks,
Mike

19

I like the way it is now where it moves all servos as fast as possible. So I guess option #1 is my pick.

20

Hi Mike,

I’m happy to hear you found the issue!

I’m in for option #1 as well. I’m always making my code move to the start position as close as possible so full speed would be fine. Making a controlled move to the start position is also possible with the command you posted. Great!

Just an idea: Is it also possible to make a optional time argument in the player start command?

PL0 SQ6 IX0 T1000

The reason I’m asking this is because the BAP need to send 2 commands and have to time/wait between sending the 2 commands. Having this in one command should be easier on the BAP side. I’ve no idea how hard it is on the SSC side but I’m sure you know. Your option #1 will perfectly, this is just nice to have. :wink:

Thanks!

Xan