View Single Post
  #12   Spotlight this post!  
Unread 03-02-2010, 16:39
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Holonomic drive angle?

Quote:
Originally Posted by PhilBot View Post
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.

Quote:
Originally Posted by PhilBot View Post
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.

Quote:
Originally Posted by PhilBot View Post
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
Reply With Quote