Quote:
Originally Posted by jhersh
It really needs to include the reversal so that it is consistent with the Arcade and Tank Drive VIs.
|
Completely dissagree. Doing it just to be consistant with a bad convention makes little sense to me. The more you do it, the harder it is when you reach a critical mass of confusion. We got rid of 0-255 for joystick values and moved to +/-1. Hooray!!! Is it so hard to also adopt a logical orientation convention as well?
Having consitant conventions is essential for being able to do sensor fusion and hybrid controls. When it comes to mixing automated functions with Joystick input, you shouldn't have to be constantly inverting and uninverting.
I've worked through many of the NI Drive internals, and I'm constantly confused as to when the negative Y is and isn't included in the calculations. If nothing else, the Context help should document that a specific joystick input is assumed to be inverted.
The fact that the Drive Arcade and Drive Holomonic need different motor inversion flags just makes my case for the general confusion.
Quote:
|
We considered flipping the Y axis in the Joystick API, but we ran into a showstopper problem with that approach... with game pads and any random joystick, we don't have any way to know what axes are "Y" axes and which are not. I think it would be worse to have a game pad where one stick is positive forward and the other is negative forward. Because we couldn't know that it would compensate for all axes that needed it, we left it out.
|
OK, If it's a joystick configuration issue, put the inversion option in the Open Joystick Vi, just like you have in the Open Drive VI. Problem solved....
Here's my read... and then I'll get off my soapbox.
I've been doing this (remotely operated vehicles) for 20 years BUT I still have a heck of a time explaining the inner working of these VI's to my budding programmers. It's not that the concept is hard (I love geometry and vector math), it's just that there aren't any consistent conventions. I get half way through the math, and realize that an input was assumed to be negative forward.
My recommendation to the NI FIRST programmers.
Please decide: Is "forward" positive, or negative? Pick one and STICK WITH IT. eg: In your NI Robotics module, Positive drive on motors run Forward.
If a senor or actuator need to be pulled into conformance... do it in that device's VI's. Preferably during the "Open".
It's not a matter of convenience, it's a matter of good embedded programming.
Loud thump as I step down
Sorry for being a pain... it's just one of my pet programming peves