Bug in GP player speed when using PO. -FIXED!

Hi,

I wanted to start a new thread about some findings when using GP player combined with PO registers. In my T-Hex thread I posted about adding speed control on the GP player.
I’ve done some testing lately using the PO registers for calibrating. Like Mike said the PO affect the sequences, so I had to reprogram the EEPROM with new sequences by setting the SSC-32 configuration to default (0 deg = 1500).
So far so good. The sequences seem to work ok, but I noticed that the speed was slower. At first I thought there was a bug in the BAP code, but the same bug occur when using the SSC-32 alone connected to a PC.

I’m using LynxTerm to set the PO register. These are the values I’m using (values are from the Phoenix cfg file):

[code];[SSC PIN NUMBERS]
cRRCoxaPin con P0 ;Rear Right leg Hip Horizontal
cRRFemurPin con P1 ;Rear Right leg Hip Vertical
cRRTibiaPin con P2 ;Rear Right leg Knee

cRMCoxaPin con P4 ;Middle Right leg Hip Horizontal
cRMFemurPin con P5 ;Middle Right leg Hip Vertical
cRMTibiaPin con P6 ;Middle Right leg Knee

cRFCoxaPin con P8 ;Front Right leg Hip Horizontal
cRFFemurPin con P9 ;Front Right leg Hip Vertical
cRFTibiaPin con P10 ;Front Right leg Knee

cLRCoxaPin con P16 ;Rear Left leg Hip Horizontal
cLRFemurPin con P17 ;Rear Left leg Hip Vertical
cLRTibiaPin con P18 ;Rear Left leg Knee

cLMCoxaPin con P20 ;Middle Left leg Hip Horizontal
cLMFemurPin con P21 ;Middle Left leg Hip Vertical
cLMTibiaPin con P22 ;Middle Left leg Knee

cLFCoxaPin con P24 ;Front Left leg Hip Horizontal
cLFFemurPin con P25 ;Front Left leg Hip Vertical
cLFTibiaPin con P26 ;Front Left leg Knee
;--------------------------------------------------------------------
#IFDEF UseCodeOffsets
;[SERVO Offsets]
cRFCoxaOffset con 83 ;Front Right leg Hip Horizontal
cRFFemurOffset con -60 ;Front Right leg Hip Vertical
cRFTibiaOffset con 70 ;Front Right leg Knee

cRMCoxaOffset con -27 ;Middle Right leg Hip Horizontal
cRMFemurOffset con -21 ;Middle Right leg Hip Vertical
cRMTibiaOffset con 46 ;Middle Right leg Knee

cRRCoxaOffset con -1 ;Rear Right leg Hip Horizontal
cRRFemurOffset con -27 ;Rear Right leg Hip Vertical
cRRTibiaOffset con 81 ;Rear Right leg Knee

cLFCoxaOffset con 49 ;Front Left leg Hip Horizontal
cLFFemurOffset con 23 ;Front Left leg Hip Vertical
cLFTibiaOffset con 5 ;Front Left leg Knee

cLMCoxaOffset con -11 ;Middle Left leg Hip Horizontal
cLMFemurOffset con -51 ;Middle Left leg Hip Vertical
cLMTibiaOffset con -16 ;Middle Left leg Knee

cLRCoxaOffset con -57 ;Rear Left leg Hip Horizontal
cLRFemurOffset con -37 ;Rear Left leg Hip Vertical
cLRTibiaOffset con -36 ;Rear Left leg Knee [/code]

The EEPROM are programmed with these sequences (.EEP file):
PhoenixLM02_270311.zip (14 KB)

I’m using the GP player in Visual Sequencer to test the sequences. When the PO registers are set the sequences run at a much slower speed. When reseting the PO registers (set to default) the sequences run at normal speed again.

I’ve tried this several times and its pretty clear that there is something that affect the GP speed when the PO are set.
Any idea whats causing this?

Hi Zenta,

Are these sequences for 3DOF T-Hex? If so I will have to try them later this week :slight_smile: (When the new T-Hex arrives :smiley: )

This sounds like something for Mike

Kurt

No, sorry. I don’t have the 3 DOF T-Hex. So far I’m only using the GP part for Phoenix.

I think so too.

This is strange behavior. I want to make sure I understand what is happening. Is this correct?

  • When registers R32-R63 are all 0, the sequence plays normally;
  • When registers R32-R63 are non-zero, the sequence plays at an incorrect speed (too slow).

Some questions to which you may or may not know the answers:

  • If R32-R63 are all 0, if you use the PO command to set the offset, does that also affect the play speed?
  • Does the specific value in the registers matter? i.e. if you set them all to 1 does that have a different effect than if you set them all to 100?
  • Do all of the registers involved in the sequence have to be non-zero in order to affect the play speed?

Thanks,
Mike

Hi Mike,

First, I’m using LynxTerm to set the registers so when you talk about R32-R63 I’m not really sure what you mean since the LynxTerm reg part are referring to P0 - P32. :blush:

Anyway, I did some more testing today.
At first I set the registers to default (all = 0). Testing GP speed to OK using the GP player in Visual Sequencer.
Then I set register P0-P2 to 100 (all the rest to default). Testing GP speed, much slower result.
Then I set register P0-P2 to 1. Testing GP speed, and the result was a bit surprising. The speed appear to be normal again!? :unamused:

So it looks like the amount affect the speed. I tried other values between 40 -70 and that also gave slower speed.

I hope these result was helpful for you.
Thanks for looking into it! :smiley:

Hi Mike,

I’m just wondering if my last post made any sense to you. Do you need me to do some more testing?

Hi Kåre,

Mike and James spent some time working on this yesterday. It looks like it has something to do with the pauses. When sequences are used that do not contain pauses it appears the moves are not slowed down. But when pauses are used and the PO are used (both register or software) the sequences run slower. We are working on it. Sorry for not keeping you in the loop. :blush:

Thanks for letting me know Jim!

Its kinda good to hear that you where able to replicate the bug. :wink:

Replicating the bug most of the time is halve the work!
Great work guys!

So you apparently have found a work around for the bug? :wink:

If you are referring to the video i posted, the answer is no.
I’m still using the code offsets until this bug is dead.

I was able to track down the problem tonight, and expect to have a fix out in a couple of days. Sorry this took so long. I hate pulse offsets! Jim will probably agree that most of the bugs in the SSC-32 have been related to PO in one form or another. It all seems to come down to having the pulse width hanging around in 2 different forms, with and without the offset. When I forget and mix them, that causes subtle problems. In this case, the problem was with calculating the total time to perform each step of the sequence. Part of that involves subtracting the current pulse width for each channel from the target pulse width from the sequence in order to determine how far each servo needs to move. The current pulse width has the offset factored in already, but the target pulse width does not. As a result, the move times are not correct if POs are not zero. Some steps are too slow, some are too fast, some just right; but on average they are too slow.

Thanks for catching this Kåre.

Mike

Hi Mike,

I just saw Zenta’s new video and Live changing the speed of the GP player really rocks! I understand that the servo offsets are hard to work with but I hope that WE telling you that “it rules” makes it word it. :slight_smile: Having the offsets in the SSC works great!

Thanks! Xan

Sounds like you’ve been busy. :wink:
I’m looking forward to it, and good luck with the fix!
Even if you hate PO’s they are very convenient, especially when it comes to GP sequences:

1. You don’t have to update all sequences after replacing one servo.
2. Much easier to share .eep files/projects in the forum.

Your welcome. I’m just happy that you are able to do something with it, highly appreciated! :smiley:

I should have put a smiley after my comment about hating PO. I just get annoyed at myself for stupid mistakes, and PO code seems to be a magnet for stupid mistakes. But this is the last one, I promise. (You can’t see that my figers are crossed.)

Mike

Don’t worry Mike, I can tell you I’ve got a bunch of those “magnets” lying around here as well. :wink:
We appreciate the work you put in there.

Thanks, Xan

:laughing:
Its hard to see from here… I might try google maps or something…

Hello,
I’ve an idea for a sequencer by the remote,
press a key to record seq, playing something with the remote, press another key to replay it, then press first key to store it.

Kåre,

Here is the update. It seems to have fixed the problem, but if you could check it on your end that would be great.

ssc32-V2.06Alpha1B-EGP.abl (43.2 KB)

Thanks,
Mike

Thanks Mike! :smiley:

I’ll check it out after my Easter vacation, so i won’t be able to test it before in the middle of next week.