Holonomic drive angle?

[dwodrich]

What direction will the robot travel if the holonomic vi is fed 0 for degrees and some number for mag and 0 for rotation. I am assuming straight ahead, but don't have the robot in front of me to try it out.

I am tring to understand how the vi works. It looks like the joystick x and y when converted to degrees produces 90 degrees when pushed straight up, so I am questioning my assumption.

Thanks in advance!

[Green2]

In our testing, 0 degree input to the holo VI is straight forward.

[jhersh]

Originally Posted by dwodrich

What direction will the robot travel if the holonomic vi is fed 0 for degrees and some number for mag and 0 for rotation. I am assuming straight ahead, but don't have the robot in front of me to try it out.

I am tring to understand how the vi works. It looks like the joystick x and y when converted to degrees produces 90 degrees when pushed straight up, so I am questioning my assumption.

Thanks in advance!

The real question is how are you converting the joysticks?

[dwodrich]

Here how, got the code from another post.

[PhilBot]

You may want to display the output that that code provides.

Our testing indicated that when you connect joystick outputs into the "obvious" inputs of the rectangular to polar conversion, it produces a zero angle when the joystick was moved to the right (logical for a normal math chart) and of course, forward and backwards was reversed because of the stupid forward = -ve orientation of the joysticks.

So I suggest normalizing you joystic outputs to generate +/-1 with propper cartesian (rectangular) orientation first...

It's too bad that the holomonic function doesn't adopt a more mathematically correct (standard) input... eg orientation and units.

[jhersh]

Originally Posted by PhilBot

It's too bad that the holomonic function doesn't adopt a more mathematically correct (standard) input... eg orientation and units.

Funny you should ask... the forthcoming update will include a Cartesian version of the VI that even inverts Y for you.

-Joe

[jhersh]

Originally Posted by dwodrich

Here how, got the code from another post.

You are going to want to wire (-y) into x and x into y to get the behavior you want. You also will want to remove the "+ 180" after the conversion to degrees.

[PhilBot]

Originally Posted by jhersh

Funny you should ask... the forthcoming update will include a Cartesian version of the VI that even inverts Y for you.
-Joe

Sweeeet!

One of these days, the software community will rebel, and overthrow that -Y convention that probably came about because some EE wired the joystick in reverse on the first ever analog joystick.

I can hear the conference room meeting now:

SE: Darn..... the Y axis is reversed....
EE: It will cost to much money to fix the circuit.
SE: I guess we can fix it in software.
EE: Sure, no-one will ever know......

[Abrakadabra]

Originally Posted by PhilBot

Sweeeet!

One of these days, the software community will rebel, and overthrow that -Y convention that probably came about because some EE wired the joystick in reverse on the first ever analog joystick.

I can hear the conference room meeting now:

SE: Darn..... the Y axis is reversed....
EE: It will cost to much money to fix the circuit.
SE: I guess we can fix it in software.
EE: Sure, no-one will ever know......

My theory is that it comes from the original purpose of these devices: "flight sticks", wherein if you push forward, you go down (i.e. in the negative direction), and if you pull back, you go up (i.e. in the positive direction. The trick is that when you are flying, the x-y plane cuts through your body from head to toe, and when driving a robot, we think of it as the floor.

This is all just speculation (i.e. I don't have any sources to quote), but it seems to make sense.

[PhilBot]

Originally Posted by Abrakadabra

My theory is that it comes from the original purpose of these devices: "flight sticks", wherein if you push forward, you go down (i.e. in the negative direction), and if you pull back, you go up (i.e. in the positive direction. The trick is that when you are flying, the x-y plane cuts through your body from head to toe, and when driving a robot, we think of it as the floor.

This is all just speculation (i.e. I don't have any sources to quote), but it seems to make sense.

OK, I might buy that

Imagine the arguments I had when writing code for an underwater robot:

Vertical convention... Positive control value = increased depth.... or increased altitude?

[PhilBot]

Originally Posted by jhersh

Funny you should ask... the forthcoming update will include a Cartesian version of the VI that even inverts Y for you.
-Joe

Not sure how you are implementing this, but can I request that you DON'T include the Joystick reversal in the drive VI. (or at least make it an option "Reverse Y Axis")

I know the reversal is needed, but if we intend to use the same VI in Auto, having to use negative numbers to go forwards is real annoying (eg when target tracking).

I can't tell you how annoying it was writing the code last year to track the target, and having to continually reverse the sign of the forward motion to get the robot to "approach" the target. Flipping the sign is easy, but debugging the control loop was no fun.

I still say ground based robot joysticks MUST output +ve numbers when pushed forward. There would be SOOOOOO much less confusion if the Get Joystick just flipped the Y axis, and ALL the controls that currently accept JS inputs were corrected to match. Then they'd work the same in auto and teleop.

I'll give you another example.

Our robot has it's 4 drive wheels on pivots, so they can be configured to be in-line (90 deg) or at 45 Deg. So at the press of a button, the robot can flip from Skid steer to Holomonic. The trouble is, it turns out that the "default" + direction for the Arcade Drive, and the Holomonic drives are flipped... mainly because the Arcade VI assumes -ve input is forward, and the holomonic assumes 0 Deg is forward (eg: holomonic is logical, Joystick is convenient.)

So if the wheel "Invert" bits are set correctly for Arcade drive (as in the sample template), they are incorrect for holomonic. This caused me no end of trouble during debugging. In the end I just had to invert the joystick values going to the Arcade drive. Now stick forward works for both arcade and holomonic.

The alternative was to make JoyStick back action request a 0 degree vector for holomonic..... No Thanks.

Phil.

[jhersh]

Originally Posted by PhilBot

Not sure how you are implementing this, but can I request that you DON'T include the Joystick reversal in the drive VI. (or at least make it an option "Reverse Y Axis")

I know the reversal is needed, but if we intend to use the same VI in Auto, having to use negative numbers to go forwards is real annoying (eg when target tracking).

It really needs to include the reversal so that it is consistent with the Arcade and Tank Drive VIs. Also, the Polar version is more likely to be used in autonomous.

Originally Posted by PhilBot

I can't tell you how annoying it was writing the code last year to track the target, and having to continually reverse the sign of the forward motion to get the robot to "approach" the target. Flipping the sign is easy, but debugging the control loop was no fun.

This can be done very easily and not interfere with your control loop design if you simply put the negation immediately before the Y input to the arcade drive VI. Then you controller acts normally. Just treat the drive VI and the negat on it's Y input as a single package, or even stick it in a subVI.

Originally Posted by PhilBot

I still say ground based robot joysticks MUST output +ve numbers when pushed forward. There would be SOOOOOO much less confusion if the Get Joystick just flipped the Y axis, and ALL the controls that currently accept JS inputs were corrected to match. Then they'd work the same in auto and teleop.

I completely agree. Stupid airplane people.

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

Just think of it as yet another problem to overcome and a tool to teach the kids about the real world of software engineering... "fixing it in software".

-Joe

[PhilBot]

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.

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

[jhersh]

Originally Posted by PhilBot

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.

Originally Posted by PhilBot

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.

I don't understand... These two statements appear to be conflicting. I was simply stating that since I can't address the underlying issue (forward != positive) that the next best thing I could do is be consistent. Since I can't choose forward == positive, I'm forced to choose forward == negative. "Sticking with it" is precisely what I'm trying to do.

In the future we can try to flip everything around and solve the issues that creates, but for now, is consistency not the best option?

-Joe

[PhilBot]

Originally Posted by jhersh

I don't understand... These two statements appear to be conflicting. I was simply stating that since I can't address the underlying issue (forward != positive) that the next best thing I could do is be consistent. Since I can't choose forward == positive, I'm forced to choose forward == negative. "Sticking with it" is precisely what I'm trying to do.

In the future we can try to flip everything around and solve the issues that creates, but for now, is consistency not the best option?

-Joe

Point taken....

If you only look at the Fore/Aft Joystick values for the external signals going into FRC Drive VI's then yes.... it's consistent. But that's a small subset of NI Robotics.

If you look at the bigger picture of "What is the positive Y axis for the robot" , or at the smaller picture of "how to set the inversion flag for the wheels", or maybe "what does +Y means to the inverse kinematics of a manipulator", there isn't a convention in FRC, and there could be...

If I've got you even considering flipping everything around in the future, then I've done my job

Phil.