Disregard all this...

Dave, what you are experiencing is code that actually verifies the response packet, which was not done before in your EZ-Script version. You notice bugs in the previous version as you move from ezscript to javascript. This is why ezscript is garbage and should be shot.

You can quickly check the packet with JavaScript to ensure the response is valid.

As you stated, the response isn't valid. Here's what I'm guessing is happening...

1. the script initializes the UART, which clears the buffer (this is the problem I think)

2. the script sends a command to "2, Getp", which tells the kangaroo to send a string of responses continually. I don't know. You'll have to tell me what that command does. But looking at your script, the Getp is only sent once, and there's a loop of reading responses after that. That tells me the Kangaroo continually sends responses forever

3. then the script loops and reads seven characters at a time, expecting to be the packet

Now, the reason I think the issue is with #1 (The init) is because the init clears the buffer. When the input buffer is removed, it may be removed in the middle of a packet. That means when you read more packets, they'll be offset and the packet will be incorrectly aligned. Remember, you're reading seven characters at a time, so the packet will be incorrect if the init happens in the middle of the buffer.

So I think the solution is to

1. move the Init into your Connection Script init. So, the UART initializes when the EZB connects

2. remove the init from the looping script

The only reason I think that is a solution is because the kangaroo packets are not very friendly for a protocol. Protocols with termination \r are challenging to work with.

Disregard my previous response. Leave the init where it is...

I looked at the kangaroo manual (www.dimensionengineering.com/datasheets/KangarooManual.pdf), and the getP command is...

The getp command returns nine characters, not 7. So it must read nine characters. But a few other things need to change in the script now. You can't use "var positionPart = resp.slice(-4);" to get the last four characters anymore.

Give me a minute, and I'll think of something...

Here...

You'll have to make the same changes as you did to my last script because i just used the same one. But it has the 9 characters read instead of 7.

// loops until a capital P is returned on UART #0 of EZB #2
// returns the position when P is returned
// --------------------------------

// Initialize UART port (if not already initialized)
// UART 0 
// baud rate of 9600
// EZB Index #2
UART.initHardwareUart(0, 9600, 2); 

// Get Right Channel ARS Kangaroo position
UART.hardwareUartWriteString(0, "2, Getp\r", 2);

// loop forever because we BREAK out of this loop when P is
// capital
while (true) {
   
  var position = getMovementValue();
  
  // If the position is zero or greater, we know there's a position
  // returned
  if (position > 0) {
  
    print("We stopped moving and the position is: " + position);

    halt();
  }
  
  sleep(50);
}

// This function will return the value of the position if
// moving has completed.
// OR it will return -1 if the moving is still happening
function getMovementValue() {

  // get bytes avaiable on UART #0, EZB #2
  var avail = UART.hardwareUartAvailable(0, 2);

  // If we don't have at least 9 characters, return -1
  if (avail < 9)
    return -1;

  // read 9 bytes from UART #0 on EZB #2
  var resp = UART.hardwareUartReadString(0, 9, 2);

  // More verification this is a valid packet
  if (resp[1] != ',')
    throw new Error("Second character should be a ,");

  // Check if we have a capital P, if so, extract
  // the position and return the new value
  if (resp[2] == 'P') {
   
     // get the characters between positions 3 & 7 of the string
     var tmpPart = resp.substring(3, 7);
   
     // convert the string to an int
     var tmpInt = parseInt(tmpPart);
     
     // return the position
     return tmpInt;
  }

  // still moving 
  return -1;
}

Also, remember that

//Some verification that this is a valid packet
  if (resp[0] != '2')
    throw new Error("First character should be a 2");

Is checking the response to be value 2 to be in the first character of the response, which might not be correct... so that the whole condition can be removed, and we only need to scan for a coma to ensure it's a valid packet. Notice how I removed that entire comparison from my last script example.

Thanks so much @DJ for the personal attention and your work. I just saw your posts and work as I had stepped away from the robot to decompress and take care of my obligations on Valentin's Day. LOL. I'll look closer at what you offered, make any needed adjustments to work with my system, give it a try and report back. Thanks!

@Athena and @DJ, one question; You say to keep the Uart INT command in the script. I've always initialized my Uart ports in my start up INT script when the robot starts up. When I started working on getting your script to work with this robot I cut that part out because I always believed that once the Uart port was initialized there was no need to ever do it again while connected to the EZB. Do you want me to leave this command in your script for a reason (like clearing out the Uart of any old data)?

It's great to hear that you're considering the adjustments and ready to test the solutions provided. Regarding your question about the UART initialization (UART.initHardwareUart) command within the script, there are a couple of points to consider:

1. Initialization at Startup: Typically, initializing the UART port in the startup script is a good practice, especially if the UART settings (such as baud rate) do not change frequently. This ensures that the UART port is ready for communication as soon as the robot starts up.

2. Re-initialization within Scripts: Including the UART.initHardwareUart command within specific scripts can serve a few purposes, such as:

   • Clearing the Buffer: Re-initializing the UART port can help clear any residual data in the UART buffer, ensuring a clean state for new communication sessions.
   • Flexibility: If your project involves changing UART settings (baud rate, etc.) dynamically based on different tasks or modes, re-initializing within scripts allows for this flexibility.
   • Robustness: In scenarios where the UART communication might be interrupted or the connected device is reset, re-initializing the UART within the script ensures that communication parameters are correctly set before each session.

However, if your project uses a fixed UART configuration and does not require clearing the buffer or changing settings dynamically, you might not need to re-initialize the UART port within each script, especially if doing so does not contribute to solving the specific issues you're facing with the Kangaroo controller.

Given your context and the fact that you've already initialized the UART port in the startup script, you might choose to omit the UART.initHardwareUart command from the loop script, particularly if re-initialization does not offer a clear benefit or solution to the challenges you've described. If you suspect that residual data in the UART buffer might be contributing to communication issues, including a buffer clearing command or re-initialization as a troubleshooting step could be worth exploring.

Ultimately, the decision to include or exclude the UART initialization command within specific scripts should be based on the specific requirements and behavior of your project and the devices you're communicating with.