Pyra use #137


Well, not really.

Not enough controls, probably not as much transmission distance for what they call "2.4GHz wireless" which I guess is the same as WLAN at least on the physical level.
 
Well, not really.


Not enough controls, probably not as much transmission distance for what they call "2.4GHz wireless" which I guess is the same as WLAN at least on the physical level.
Really.  Though the purpose built hardware that the controller is based on will always be slightly 'better' for it's application.

Every key on the keyboard is a potential modifier (shift) for every key and nub on the game controls.  We have more than enough controls - likely too many.  The primary incompatibility that we would likely have is circling the square.  Otherwise known as the mapping a round nub to a square coordinate plane conundrum.

Transmission distance is easily overcome.  Drones like those this is meant to control operate on Cell networks, Bluetooth or 802.11g.  If there isn't enough eumph (non technical term) in the stock radios and antennas on the Pyra, then USB sticks can be stuck in.

The main point is that since they're developing THAT controller on Linux, likely on ARM, and making it open source, someone could port it over to the Pyra and it's controls with relatively minimal pain.

but shit that thing looks awesome!  xD
Yes - it does.  It also looks freekin' huge, cumbersome, delicate and expensive.
 
Well, not really.

Not enough controls, probably not as much transmission distance for what they call "2.4GHz wireless" which I guess is the same as WLAN at least on the physical level.
Really.  Though the purpose built hardware that the controller is based on will always be slightly 'better' for it's application.
Every key on the keyboard is a potential modifier (shift) for every key and nub on the game controls.  We have more than enough controls - likely too many.  The primary incompatibility that we would likely have is circling the square.  Otherwise known as the mapping a round nub to a square coordinate plane conundrum.

Transmission distance is easily overcome.  Drones like those this is meant to control operate on Cell networks, Bluetooth or 802.11g.  If there isn't enough eumph (non technical term) in the stock radios and antennas on the Pyra, then USB sticks can be stuck in.

The main point is that since they're developing THAT controller on Linux, likely on ARM, and making it open source, someone could port it over to the Pyra and it's controls with relatively minimal pain.
I would just emphasize the "Though the purpose built hardware that the controller is based on will always be slightly 'better' for it's application." much more.I didn't want to deny you can use Pyra for the same purpose, but I'm still denying it will be at least as good at it as the dedicated controller. And as long as that's not the case you can't really speak of "replacing" such a controller. It's maybe an alternative, but I assume it's very likely someone who does a lot of flying will still prefer the dedicated controls. Signal strength can be fixed, sure, but then you need additional hardware.

Mapping round to square certainly won't be an issue. I could do the maths for that off the top of my head. Someone else also described them in another thread.

What will be a problem is if the nubs actually have their maximum movement in a circle. Because probably you'll want "left down" to be -1|-1, while you can only move the pad to something like -0.7|-0.7, so while mapping -0.7|-0.7 to -1|-1 is easy the actual hardware could be a problem because that doesn't make a lot of sense. On the other hand, if you leave it at -0.7|-0.7 you won't be able to steer as much in both directions at the same time as you actually could, so that doesn't make sense either.
 
Mapping round to square certainly won't be an issue. I could do the maths for that off the top of my head. Someone else also described them in another thread.

What will be a problem is if the nubs actually have their maximum movement in a circle. Because probably you'll want "left down" to be -1|-1, while you can only move the pad to something like -0.7|-0.7, so while mapping -0.7|-0.7 to -1|-1 is easy the actual hardware could be a problem because that doesn't make a lot of sense. On the other hand, if you leave it at -0.7|-0.7 you won't be able to steer as much in both directions at the same time as you actually could, so that doesn't make sense either.
Then please fix the Pandora's controls so that I can go down & left at the same rate as I can go down OR left in XFCE.

That seems to have eluded us all for many years.
 
Mapping round to square certainly won't be an issue. I could do the maths for that off the top of my head. Someone else also described them in another thread.What will be a problem is if the nubs actually have their maximum movement in a circle. Because probably you'll want "left down" to be -1|-1, while you can only move the pad to something like -0.7|-0.7, so while mapping -0.7|-0.7 to -1|-1 is easy the actual hardware could be a problem because that doesn't make a lot of sense. On the other hand, if you leave it at -0.7|-0.7 you won't be able to steer as much in both directions at the same time as you actually could, so that doesn't make sense either.
Then please fix the Pandora's controls so that I can go down & left at the same rate as I can go down OR left in XFCE.


That seems to have eluded us all for many years.
I'll do the math and you do the hacking around in driver code?

(or emulator code, I think the problem is actually with a specific emulator, isn't? Link me the source and I'll try to take a look at some point)
 
Back
Top