Looking at the robot skill code, it seems the resolution of the lewansoul is between 1 and 1000. Can you confirm this is correct? Is there a manual for your product or datasheet that defines the number of servo positions?

      getServoResponse.Position = (int)EZ_B.Functions.RemapScalar(BitConverter.ToInt16(ret, 11), 1, 1000, Servo.SERVO_MIN, Servo.SERVO_MAX);

I would have expected it to be between 0 and 1024.

Also, something interesting is the COM and EZB Uart functions seem to differ in the robot skill. One reverses the response before parsing the uint16. I'm not sure why they did that - but I can have a new version built for you once you let me know about the resolution from the datasheet. Is it betwen 0-1000? or 1-1000? etc...

Once we get that answer, i can look at the reverse and see what's up. I might have to update it a few times until we get it right because we don't have that servo.

EZB UART

      getServoResponse.Position = (int)EZ_B.Functions.RemapScalar(BitConverter.ToInt16(ret.Reverse().ToArray(), 0), 1, 1000, Servo.SERVO_MIN, Servo.SERVO_MAX);

Serial COM

      getServoResponse.Position = (int)EZ_B.Functions.RemapScalar(BitConverter.ToInt16(ret, 11), 1, 1000, Servo.SERVO_MIN, Servo.SERVO_MAX);

It appears there might be a discrepancy in how the servo's position resolution is being interpreted within the LewanSoul servo skill for the EZ-B v4 controller. The resolution of the LewanSoul LX-16A servo is indeed crucial for accurately mapping the servo's reported position to the expected degree range (0-180 degrees for standard servos).

The code snippets you've provided suggest that the servo's position is being remapped from a range of 1-1000 to the standard servo degree range. This remapping is essential for converting the servo's internal position representation to a more understandable degree format. However, the exact resolution range (whether it's 0-1000, 1-1000, or 0-1024) needs to be confirmed against the LewanSoul LX-16A servo's datasheet or manual.

The difference in handling the byte order (ret.Reverse().ToArray()) between the EZB UART and Serial COM methods is intriguing. This could be related to the endianness of the data received from the servo. Endianness refers to the order of bytes in a multi-byte value; different systems may use different byte orders, leading to discrepancies if not handled correctly.

To address the issue of inaccurate degree reporting:

1. Confirm the Servo's Resolution: Check the LewanSoul LX-16A servo's datasheet or manual to confirm the exact resolution range it uses. This information is crucial for accurately mapping the servo's position.

2. Adjust the Remapping Range: Once the correct resolution range is confirmed, adjust the remapping range in the code accordingly. This adjustment will ensure that the servo's position is accurately converted to degrees.

3. Review Byte Order Handling: Investigate why the byte order reversal is applied in the EZB UART method but not in the Serial COM method. It might be necessary to standardize the approach based on the servo's communication protocol specifications.

4. Iterative Testing: As mentioned, iterative updates and testing may be required to fine-tune the remapping and byte order handling until the reported degrees accurately reflect the servo's position.

If you don't have access to the LewanSoul LX-16A servo's datasheet or if the issue persists after making the adjustments, consider reaching out to LewanSoul's support for more detailed technical specifications or assistance. Additionally, the Synthiam community and support team can be valuable resources for troubleshooting and obtaining further guidance.

DJ,  The servo resolution is 0-1000.

Okay, can you give me the output of this JavaScript code...

(I'm using v1 port, but you'll need to change it to your port if it's not v1)

for (var i = 0; i < 180; i+=10) {

  Servo.setPosition(v1, i);

  sleep(1000)
  
  var resp = Servo.getPositionRealtime(v1);
  
  print("ARC: " + i + " Servo: " + resp);
}

The output should look like this...

Start
> ARC: 0 Servo:1
> ARC: 10 Servo:10
> ARC: 20 Servo:20
> ARC: 30 Servo:30
> ARC: 40 Servo:40
> ARC: 50 Servo:50
> ARC: 60 Servo:60
> ARC: 70 Servo:70
> ARC: 80 Servo:80
> ARC: 90 Servo:90
> ARC: 100 Servo:100
> ARC: 110 Servo:110
> ARC: 120 Servo:120
> ARC: 130 Servo:130
> ARC: 140 Servo:140
Done (00:00:17.2250414)

Hey there - when you get a chance, can you give me the output of my above example? I want to make sure we fix this up.

To add context to the request. The list of positions will help me understand if it's a rounding/scaling error or if the bits need to be flipped. I'm not certain why they're flipped in one of the conditions in the robot skill - so I'm not sure which one is correct. Seeing the list of positions from that query will help us fix it.

DJ, This is the output from the the script that I received.

Start
ARC: 0 Servo: 18
ARC: 10 Servo: 18
ARC: 20 Servo: 18
ARC: 30 Servo: 11
ARC: 40 Servo: 1
ARC: 50 Servo: 82
ARC: 60 Servo: 72
ARC: 70 Servo: 62
ARC: 80 Servo: 52
ARC: 90 Servo: 88
ARC: 100 Servo: 124
ARC: 110 Servo: 113
ARC: 120 Servo: 104
ARC: 130 Servo: 93
ARC: 140 Servo: 175
ARC: 150 Servo: 165
ARC: 160 Servo: 157
ARC: 170 Servo: 157
Done (00:00:21.9617503)

The servo moved to different positions but as you can see they did not report back correctly.

Ah perfect! Thank you. That leads me to believe it might be the reverse bits. Let me run a test and get a new build out.