Bug #346
closedsupport for newer versions of Motive and Natnet
Added by Youssef Aboudorra over 2 years ago. Updated almost 2 years ago.
Description
Hello Anthony
For performing demos in another partner's lab we would like to use optitrack-genom3 with the following setup:
- Motive Version: 2.2.0
- NatNet Version: 3.1.0.0
Could the component be updated to support the aforementioned versions ?
It is not of a high priority at the moment, as the intended dates of use are around mid June.
Appreciate your support.
Regards,
Youssef
Files
screenshot.png (100 KB) screenshot.png | Davide Bicego, 2022-11-30 19:24 |
Updated by Anthony Mallet over 2 years ago
- Status changed from New to Feedback
It seems to me that there is no protocol change since natnet 3.0. At least
according to this mirror of the natnet sdk:
https://github.com/mje-nz/natnet-sdk-mirror/commit/5a8a379f0472f5aef74aa828ecbcbcb04ec93339#diff-3accc2cad0598ca5e9d4205a4b548adc199f742452e07d37dcd681023160fa37
So except if you did experience some issues during a test, I'd say
it's already supported!
Updated by Youssef Aboudorra over 2 years ago
Hi
Great, I haven't tested it yet.
We will install the required version on our opti-track machine and test in the coming weeks.
I will create an issue if required then.
Thanks for your prompt reply and support.
Regards,
Youssef
Updated by Davide Bicego almost 2 years ago
- File screenshot.png screenshot.png added
- Priority changed from Low to Normal
Hello,
Ayham Alharbat from Saxion did this test and was able to retrieve the body list with proper names, however, all the fields of each body are empty.
You can find a screenshot of the performed test in the attached picture.
Appreciate your support; in the coming weeks, we plan to perform experiments with that setup.
Best,
Davide
Updated by Anthony Mallet almost 2 years ago
What kind of streaming did you configure in Motive?
If multicast, is there any network equipment in between the Motive
host and the receiving side?
If unicast, did you check that the local interface setting is correct?
Updated by Ayham Alharbat almost 2 years ago
Anthony Mallet wrote in #note-5:
If multicast, is there any network equipment in between the Motive
host and the receiving side?
Thanks Anthony!
It was indeed a problem of communication, when it was connected directly to a local router, the problem has been solved and we can read the data.
One thing that is still not working properly is that the data that I receive from optitrack-genom3 is rotated -90 degrees around the z-axis:- When I move the robot 0.5m in the positive x-axis, I read it as 0.5m in positive y-axis
- When I move the robot 0.5m in the positive y-axis, I read it as 0.5m in negative x-axis
- While z-axis is working properly
- When I rotate the robot 90 deg around x-axis, I read it as 90 deg around y-axis
- When I rotate the robot 90 deg around y-axis, I read it as -90 deg around x-axis
- While rotation around z-axis is working properly
In Motive Version 2.2.0 the default setting is that the y-axis is up (which can be changed to Z-up), and I noticed that optitrack-genom3 already rotates it such that the z-axis is pointing up, and when I change it to Z-up (just to see what will happen), the data is even more confusing.
Do you have any pointers that can help me?
Thanks again for your support!
Updated by Anthony Mallet almost 2 years ago
On Friday 2 Dec 2022, at 13:34, Ayham Alharbat wrote:
One thing that is still not working properly is that the data that I
receive from optitrack-genom3 is rotated -90 degrees around the
z-axis:• When I move the robot 0.5m in the positive x-axis, I read it
as 0.5m in positive
y-axis
• When I move the robot 0.5m in the positive y-axis, I read it
as 0.5m in negative
x-axis
• While z-axis is working properly
How do you read this? Did you change the default optitrack-genom3 frame
with set_transform()? (it should work out-of-the-box without any
particular configuration).
The values displayed in Motive are in a different frame (Y-up). In
particular, the L frame used for setting the origin should be
interpreted as follow : the printed Z label indicates the "X" axis of
optitrack-genom3. So if you move along the Z axis of the L frame,
optitrack-genom3 will show motion on the X axis (same direction).
In Motive Version 2.2.0 the default setting is that the y-axis is up
(which can be changed to Z-up), and I noticed that optitrack-genom3
already rotates it such that the z-axis is pointing up, and when I
change it to Z-up (just to see what will happen), the data is even
more confusing.
Yes, the setting should be Y-up in Motive. (this is because this
setting did not exist in previous versions: it was always Y-up. The
optitrack-genom3 software is by default configured like this).
Updated by Ayham Alharbat almost 2 years ago
Anthony Mallet wrote in #note-7:
The values displayed in Motive are in a different frame (Y-up). In
particular, the L frame used for setting the origin should be
interpreted as follow : the printed Z label indicates the "X" axis of
optitrack-genom3. So if you move along the Z axis of the L frame,
optitrack-genom3 will show motion on the X axis (same direction).
The problem was that the way we configured the coordinates in motive was a bit different. After following this comment from you, I rotated the 'volume' in motive 90 degrees around y-axis, and that solved the problem.
Thanks a lot Anthony!
Updated by Anthony Mallet almost 2 years ago
- Status changed from Feedback to Closed
Good!
Regarding this, what we do usually is to put the tracked object at the
desired 0 orientation in the real-world and then do a "reset body
orientation" in Motive, so that the model is properly aligned with the
world frame.
Thanks for the feedback, I'm closing this.