Closed stevenj closed 1 year ago
Interesting news! It would be great to support the Max. Rokid has a maven repository, so that's where I'd start. Looking at their docs, the Max should be supported, but I never found their docs to be all that reliable, so YMMV.
The actual native SDK seems to be this package.
Can confirm it. 3d switching also works with me on Rokid Max but I can not read sensor data.
Which place in the SDK would be interesting to make this possible for the Max? @badicsalex
@rewasa
It depends on how different the protocol is. If it's similar (likely), I'd just rename the RokidAir
struct to Rokid
, and let it handle both kinds of IMU streams. Have a private enum field (Air or Max) that's determined at initialization time (probably from description string, that's what the official SDK does), and a match
on that enum in read_event
. display_fov
, tilt
and name
should probably be dynamic based on the model too.
If it's not similar, RokidAir could be copied into a class named RokidMax, modified and wired in like all the others.
@badicsalex very good, now I could use eprintln!("{result:?}"); to get the following result:
[17, 128, 156, 213, 164, 71, 3, 0, 0, 116, 154, 191, 188, 208, 193, 26, 65, 230, 90, 44, 190, 28, 111, 30, 188, 218, 184, 208, 59, 80, 77, 34, 188, 51, 51, 83, 192, 0, 0, 34, 194, 102, 102, 254, 193, 0, 0, 0, 64, 244, 167, 140, 52, 3, 0, 0, 0, 0, 3, 80, 60, 0, 0, 0]
How can I read them correctly to get x, y and z?
@rewasa
It's hard to say. How did you get the result
array?
@badicsalex I took the following line outside the if to get these logs. On a line between 54 and 55. //eprintln!("{result:?}");
Ah, I see. I looked at the SDK, and this should be the packet layout for packet type 17:
Offset Size Name
0 1 packet type
1 8 timestamp
9 3x4 Accelerometer vector (3x f32)
21 3x4 Gyroscope vector (3x f32)
33 3x4 Magnetometer vector (3x f32)
45 1 Key statuses
46 1 Proxymity sensor status
48 8 Vsync timestamp
Unpacking the packet you posted with the layout above yields this:
type: 17
Timestamp: 3606243024000
Accelerometer: -0.023389078676700592, 9.672317504882812, -0.16831550002098083,
Gyroscope: -0.009670045226812363, 0.006369692273437977, -0.00990612804889679,
Magnetometer: -3.299999952316284, -40.5, -31.799999237060547,
Keys pressed: 0
Proxy sensor: 0
Vsync timestamp: 3524233000000
Unknown padding data: 259040411648
It looks about right.
But this means that some 2-4 events need to be generated from this single packet. The read_event
function needs to be refactored so that it can return multiple events (by having something like a pending events array, like the nreal driver).
With this extension, the RokidAir struct will be universal and handle both the Air and the Max.
Unfortunately I don't have a Rokid Max to test with, so I'm going to leave writing the code for this to someone who does.
Would you be into making a monado driver with 3dof for the max if I ordered you one? :o
@RangerMauve Sure, why not.
@badicsalex Would you be down to send me an email at contact@mauve.moe so we can scope stuff out and write up a contract of some sort?
For those interested we're just finalizing the contract. :)
@stevenj, I put in the 3840x1200#90 mode too.
Just got my Rokid MAX yesterday, and some quick tests show it is detected by your driver as a Rokid AIR. The 3d switching example app seems to work.
The Max has a few more options though, like changing screen modes to 1920x1200 120hz or 3840x1200.
The IMU example didn't seem to work, but I didn't spend long testing so that's not conclusive.
I guess the Rokid Air driver is going to need to detect which is which and change its behaviour accordingly, because USB PID/VID detection can't tell the difference. (I don't have an Air). In your blog you say the native SDK is easy to get, I spent hours searching and couldn't find it, where does one get it?
I am hoping to contribute enhancements to support the Maxs extra features.