Space Navigator PE Driver Development Thread

[cherrybomb]

Quote: Originally Posted by sama

I've tried to create a girder scipt with this knowledge, but strangely it's only returning 6 bytes. I took off all the splitting code and did a simple string.length on the incoming data directly, it's 6 bytes for sure. Which means it's impossible to distinguish between interleaved lines. If the Poximis guys can sort that out, then I'm sure we can get a girder script to work also.

I've been posting a lot of my findings and such on the Promixis message board, and evidently Girder 5 is going to have much more robust support for HID. I've been offered to join the beta, which I think I will, and use developing for this device to test.

Quote: Originally Posted by sama

I have some ideas on how we can use this device:

I think we should ignore a small range at the begning of every axis otherwise there will be noise and overlap betwen functions.

In the configuration of the software, any axis can have different modes of operation.

MODE 1:
after a certain threshold, a thread starts a "pulsing" event. This would be slow with low values (little pressure), and as the pressure is increased, the pulse would get quicker. This will give a use for the analogue proerties of the device, and makes it possible to control the speed of for forwarding songs, cycling through playlists, volume change etc. The pulse/range mapping can easily be defined using a couple of arrays that can be defined in the config.

MODE 2:
just "presses" a single event per axis direction. pressure is not taken itno account. This is useful for switchign between different screens for example (GPS/Media/etc.)


I can think of antoher mode but I'm not sure what for!:

MODE 3:
segement the range to "press" a single event (not pulsing) at different threshholds.

*nod* the first two were pretty much the ones I'd expected to have for this device. I agree that there should be some threshold that it ignores to allow for it to be useful.

Quote: Originally Posted by sama

I've also found that combining axis (like pan and tilt) you can create more quick-functions. Like holding the hat and tilting left but panning right. These quick presses are easy to model and diffrentiate.

Yes, gestures. :-) It'd be cool to have some gestures that take you to specific places, or do specific things. Like a left tilt and zoom takes you to GPS, but a right title and zoom takes you to your media player etc. :-)

Quote: Originally Posted by sama

Thanks for all the help cherry, coudln't have done anythign at all without your magic app!

Can't really take a ton of credit for it, most of it was already written, I just massaged it to conform to our application. Glad it helped. :-)

[Mr_Civic]

Quote: Originally Posted by scott_fx

damn you guys...you just spent another $65 of my money!

You took the words rite out of my mouth!

[liquid_smoke]

my thoughts on usage:


im not sure if girder is the best way to go,
1 you have to pay for it or use the old version, and if you guys are doing it with the beta then theres a big change it will only work with the pay version of girder.
2 its super complicated and not intuitive at all. You can easily spend days trying to get something to work the way you want it to. Just trying to figure it all out takes a tremendous amount of time, most just give up, i know i did.
I would much rather see a scripting language embedded then girder, like autoit that would allow you to control pretty much anything on your computer and tons of other stuff girder cant begin to do.

I think some kind of app that lets you assign actions to the motions of the device and also have some kind of profile support so you can have a list of actions that apply to road runner and another list of actions that apply to another application and also a mouse mode that simply lets you use the device to move the mouse.

actions i would like to see

send keyboard shortcuts

move mouse

run application with support for parameters. This is the primary way i think it should control Road Runner, by running Exec.exe with parameters. For example
Exec.exe NEXT would send the NEXT command to RR. This will allow you assign any command you have listed in your ExecTBL.ini. You can ofcourse build in support to send command directly to RR but you would still need an option to run applications so might as well save some work.


this should satisfy most peoples needs.

Other cool stuff would be for the profile support to be context sensitive.
So i could assign different profiles based on the active window. So if im RR it would use profile i setup for RoadRunner, if load GoogleEarth it will automagically switch the profile to google_earth when i activate or focus its window. This would remove the need to assign one of the motions/device movements as a profile switcher and makes everything more fluid and natural.


super happy that you guys are working on a solution to use this device in the car. In the end it should wind up being better than the device thats in the bmw's

[cherrybomb]

Hey Liquid,

You're right about Girder, and I don't think we're particularly married to it. However, if it DOES work, it is technically "easier" to get that working initially, than to write a whole driver/software bundle to interface with the device, as Girder would already do most of the work.

With that said, a custom solution is probably the right one, and Sama and I tend to agree about that, though it's a considerably bigger project. :-)

I think our goal should be to get the minimum viable thing out there, probably just mouse control and either keyboard shortcuts or something similar, then see how people use it, and what works best.

Ideally, I'd like to create some tools that are more-or-less cross platform, so it can work on linux etc, to make this device even more useful outside of the bounds of a CarPC. :-)

[inh]

You have an app that displays the location of the hat, so obviously you have a way to capture and process the info.. Thats 2/3 things. THe last is just outputting it. maybe write up a quick front end (hell VB would work) to send keyboard shortcuts..

[sama]

liquid... fantastic comments there, and I don't think cherry could have answered for the both of us better there

I like the idea of exec NEXT etc as it would allow a very quick solution, and though I think of it as a hack, if it works.. .who cares!


cherrybomb, I'll post my java code here tommorow (after I do some cleaning) and I'm sure you'll understand it all the same (after all, c# was mostly copied from java )

inh... keep saving those pennies.. by the time you're done you'll have a working device

[inh]

buying one in a few hours when my patcheck hits the bank so

[cherrybomb]

Quote: Originally Posted by sama

liquid... fantastic comments there, and I don't think cherry could have answered for the both of us better there

I like the idea of exec NEXT etc as it would allow a very quick solution, and though I think of it as a hack, if it works.. .who cares!


cherrybomb, I'll post my java code here tommorow (after I do some cleaning) and I'm sure you'll understand it all the same (after all, c# was mostly copied from java )

inh... keep saving those pennies.. by the time you're done you'll have a working device

Cool, I look forward to looking at the code. I'll be honest that I wasn't real clear on the table you presented in your post above, but I'm sure the code will make sense. :-)

[turbocad6]

I don't know anything about coding, but the table looks to me like each axis outputs it's co-ordinances at a specific spot in the string, & each axis has a value that varies from 0 to 255, so I guess if everything is dead center the string would be either all 127's or all 128's... there is no actual center, as it would be 127.5....

I could be totally wrong though, but that's what it looks like to me

I'm really not trying to help, as I know nothing about this, just curious if my understanding is correct?

[liquid_smoke]

Quote: Originally Posted by sama

I like the idea of exec NEXT etc as it would allow a very quick solution, and though I think of it as a hack, if it works.. .who cares!

i wouldn't really look at it as a hack persay, i mean the Exec.exe was created specifically for this purpose by guino. Its super lightweight and fast too, in practice using it equal to actually clicking a button in Road Runner, no lag at all.



cant wait to see some pics of someone integrating this in there console.

[sama]

@turbocar & cherrybomb
I guess some more explanation is in order!

Turbo, that was a good and close guess!

I've copied some stuff from the top here to make it easier to see.

Code:

[0] [1] [2] [3] [4] [5] [6]
 1   8   0  161 255 251 255 

[0] [1] [2] [3] [4] [5] [6]
 2  245 255  0   0  238 255

[0] [1] [2] [3] [4] [5] [6]
 3   2   0   0   0   0   0

The 0'th element is the data descriptor, whcih describes the rest of the data. The data is actually interleaved.

So when the id is 1, the elements are:

1&2 are for pan left/right
3&4 for pan fwd/back
5&6 push/pull

and when the id is 2

1&2 tilt fwd/back
3&4 tilt left/right
5&6 twist left/right


and when the id is 3

the second element is either 1, 2 or 3 to repspecively indicate left button, right button, or both.


Now we can see that each axis is described by two values. The first always gives the value, and the second gives the sign (+/-)

So taking an example from the table:

Code:

pan left/right axis
value from 1[1]
right: 2[1] = 0
left : 2[1] = 255

this means the value for the axis is extracted from element 1 (0-255).
if going right, then element 2, which is the sign would be 0, and if going left, element 2 would be 255.
Finally, if the sign is 0, the the value would increase from 0-255. If the sign is 255, then the value would decrease from 255-0.



And now for the problem I've found . I've noticed that pushing beyond 255, actually starts the value again! It gets to 255, then starts at 0 again (the other way if the sign value is 255). It's like it has two lungs!

And the peculiar thing is, there are 7 bytes that come back, and the bytes do not change at all to indicate that the axis is on it's "second lung". I'm going to look deeper, and see perhaps if I'm missing anything, which I hope is the case. Otherwise, the only other thing I can think of is to keep track of climbs and falls (per axis) and to detect "second lungs" based on climbs and falls. This will be difficult since if you let go of the knob, it will return to 0 in a flash and probably bounce a bit too. It's a dirty solution basically and I can't imagine this is how they've done it.


@cherrybomb
I think I'll take this chance to finally learn C#. I'll get Visual Studio installed on here ASAP


@liquid
Ah, I didn't know that Exec was specific to RR. That sounds like a really good solution and would make things a lot easier to code. I guess Exec is a small bit of code that fires off a COM message and terminates.

[sama]

ok, that was a false alarm. After looking again, it seems that the "sign" value not only switches between 0 and 255, but it also goes to 254 and to 1 (to indicate second lung).

This means that the actual range of the device is more than +/- 255. I expected to see it go to The max I've seen it get to on the "second lung" (that term is just too catchy to stop using!) is 190. So that's a total range of +/- 445.

@cherrybomb
At the moment, I've got code that checks for 255/254/0/1 etc, and act accordingly. However this is not the way to do it. It seems that this is not an 8 bit number after all, but actually a 10-bit, which is odd!

Using some bitwise operations, I think a much more elegant solution can be obtained. I'm having to go back to my elementary s/w engineering notes (5 years old, but still have them )

Since we have 2 x 8 bit numbers, I'm thinking somethign along these lines:

The value for each axis in each direction ranges from:

00000000 (0)
11111111 (255)

and the "sign"/second lung figure is one of these four:

00000000 (0)
00000001 (1)
11111110 (254)
11111111 (255)

if we take just the last two bits from the sign:

00 (0)
01 (1)
10 (254)
11 (255)

and append that to the first 8 bits, to get a 10 bit number, then we look at the values, this would make things a much much more efficient, perofrmance and code wise. To test the theory, here are some values to see how it would work:

using 00000111 for the value (7), then we should be able to get the following figures.

0000000111 = 7
0100000111 = 263
1000000111 = -7 (if the first bit is read as a sign)
1100000111 = -263 (if the first bit is read as a sign)

and at this stage, we can check the MSB (most significant bit, far left) and that tells us the sign, then we shift everything to the left, and we'll have a value which we can multiply by -1 based on the MSB.

whaddaya think?

[sama]

ok, I was on my lunch break and it just hit me! It's a lot easier than I thought...

the number coming back is not an 8 bit, nor is it a 10 bit. It's 16bit! and we don't need to do anything to it. just need to read it as a 16 bit short integer!

so:

assume the sign byte is 254 and the value byte is 0. We know that 254 means the second-lung and negative. So this should be -255

now we create a short (initialised to 0)
0000 0000 0000 0000

assign the first number (the one that is 0, 1, 254 or 255 - 254 is used as an example):
0000 0000 1111 1110

shift it by 8 bits to the left
1111 1110 0000 0000

do a bitwise xorOR (EDIT:xor would be totally wrong!) with the value (assume 1)

Code:

1111 1110 0000 0000
OR
          0000 0001
--------------------
1111 1110 0000 0001 = -255 (assuming singed short)

Bob's your uncle!

[turbocad6]

I think your a rocket scientist

I wish I could help here... when you mentioned the second lung, the first thought I had was limiting the travel..... I mean we have way more resolution than we need already, so that might have been a possibility I thought... now I guess that's not an issue though...

[sama]

hehe, I love decoding what someone else has done stuff. I once decoded the Lego Mindstorms brick, but I was paid to do that one

Would have been a good idea about limiting the travel, though when you see the device you'll think twice about that! It's one of those "sealed shut and I don't think i have the balls to dismantle it'cos it'll break" devices I mean seriously, it looks like you have to crack something to find out how it opens up. And it's just too damn nice and compact and sleek to scratch etc.