Space Navigator PE Driver Development Thread

[sama]

hehe. I really think you won't be sorry. If you use google earth, it's worth it for that alone. And soon you'll also be able to use it for volume, track control, switching between different screens, and that's three axis out of 6.

This is a great device with lots of potential.

[liquid_smoke]

sounds good, cant wait to test this out.

[sama]

proof tha it works!

video codec: xvid mpeg 4

[cherrybomb]

Brilliant!

Good work sama!

Seems to make sense. Can't wait to get my device so I can actually test it.

Suppose I should tweak my test app, or I guess we're really ready to start developing something useful now that you've cracked the code?

[sama]

definiltely.

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 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.


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.


I guess the best starting pont is getting this to work with RoadRunner, sending it simple messages, and then we can incorporate all these modes based on usage etc.

If anyone has any ideas, please post away.


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

[cherrybomb]

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.

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.

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. :-)

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]

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..