GP player, how should the ONCE command work?

[zenta]

Hi

I’m quoting from my Phoenix thread:

@Robot Dude

@zenta

The GP player are pretty useful to make your hexapod do more than just walking.

BTW, the GP player seem to have a bug in the ONCE command. When it play one sequence (ex. 0 -> 13 steps) it start with step 0 but it seem to end the player by sending step 0 one more time after playing step 13.

I solved it by always making sequences that start and end seqences with the same pose/data.

Ok I have confirmation that it’s not a GP firmware bug, but rather how Mike thought it should work. He is open to input on this and make changes if needed. I suggested the possibility of creating another ONCE command, calling it ONCES to mean play the steps (S)hort one. Or not play the first step again. Input… we need input…

Since Jim needs input about this I thought it would be better to start a new thread about this.

IMHO I think that the ONCE command should work like this: Start with the first step and end with the last step.

Jim’s suggestion about a new ONCES command was also a good idea.

What are your opinion about this?

[robotdude]

I talked to Mike and we both agree the best way to fix this is to change the command to stop at the last position. He will make the firmware change and get me the files soon. 8)

[zenta]

@Robot Dude

I talked to Mike and we both agree the best way to fix this is to change the command to stop at the last position. He will make the firmware change and get me the files soon. 8)

Thanks Jim.

And especially thanks to Mike!
Looking forward to try it.

[miked-6]

My mantra: nothing is ever as easy as it should be.

I am working on the ONCE update and have a question. First, I think I understand what is desired in the simple case. If the sequence starts at step 3, for example, then

• if it is moving forward (i.e. SM > 0), then it should play to step 2 and stop.
• if it is moving in reverse, then it should play to step 4 and stop.

Correct?

My question is what should it do if the direction is reversed while it is playing? I would prefer to set the final step number at the time the command is issued and not change it if the direction changes. What I mean is, if the sequence starts at step 3 with the ONCE option and SM>0, then it will stop at step 2. Even if you change direction in the middle of the sequence.

Is this OK?

Mike

[zenta]

Hi Mike,

@miked

My mantra: nothing is ever as easy as it should be.

I am working on the ONCE update and have a question. First, I think I understand what is desired in the simple case. If the sequence starts at step 3, for example, then

• if it is moving forward (i.e. SM > 0), then it should play to step 2 and stop.
• if it is moving in reverse, then it should play to step 4 and stop.

Correct?

Hmm With the IX set to 3 in a ONCE command I thought that the sequence still would stop at the last step (not step 2). I’ve probably misunderstood the meaning with the IX command . So the IX command is a sort of start offset for the sequence? IX set to 3 makes step #3 acting like its step #0? Then I think you are correct.

@miked

My question is what should it do if the direction is reversed while it is playing? I would prefer to set the final step number at the time the command is issued and not change it if the direction changes. What I mean is, if the sequence starts at step 3 with the ONCE option and SM>0, then it will stop at step 2. Even if you change direction in the middle of the sequence.

Is this OK?

Ah, I see your problem now. So it is hard to set the final step number while it’s playing?
Maybe it shouldn’t be possible to reverse the direction of a playing ONCE command? Or it should just be possible to define the direction at start (when initiating the ONCE command)?

[miked-6]

The IX command allows you to start a sequence in the middle if desired. I probably made my question more confusing by using a non-zero starting position in my example.

My intent for the ONCE command was that it would visit each step in the sequence one time, ending on the same step it started on. This modification will have it end one step away from the step it started on.

If somebody changes direction while playing a sequence ONCE, the results will be confusing regardless of how I handle it. I really don’t want the firmware to impose a restriction on changing the direction during a ONCE because that introduces a whole new set of issues.

Here is the behavior I propose. The final step number for a ONCE command will be set based on the direction at the start of the command, and will not be changed even if the direction changes. For example, if IX=0 and SM>=0 the final step will be the last step of the sequence. If IX=0 and SM<0 the final step will be step #1.

Mike

[zenta]

@miked

Here is the behavior I propose. The final step number for a ONCE command will be set based on the direction at the start of the command, and will not be changed even if the direction changes. For example, if IX=0 and SM>=0 the final step will be the last step of the sequence. If IX=0 and SM<0 the final step will be step #1.

Mike

Excellent, that sounds perfect for me!

Thank you Mike!

[snailkeeper]

The new SSC-32 GP firmware v2.02 is available for download:

lynxmotion.com/Product.aspx? … #downloads

This includes the improved ONCE command behavior.

[zenta]

@Snailkeeper (Admin)

The new SSC-32 GP firmware v2.02 is available for download:

lynxmotion.com/Product.aspx? … #downloads

This includes the improved ONCE command behavior.

Ah! Thanks to Mike (and Beth)

I’ve tested it and it works perfect. I’ll post a little video when I find time for it to demonstrate a new feature using the GP Once command to change pose of the hexapod. Very cool! 8)

Thanks again!

[zenta]

Hi,

I posted a little video to demonstrate the GP ONCE. More info in my Phoenix thread.