X axis of WPI Arcade Drive

I was working with WPI_JoystickArcadeMapping.vi tonight and realized it is exactly backwards of what I was expecting. I expected that moving the joystick to the right (a positive value) would correspond with a turn to the right (clockwise). You can see in the attached screenshot that the VI above does the exact opposite supplying forward power to the right side motors and backwards to the left turning the robot counter-clockwise.

I know I can just invert this, but I was at a loss to explain to the kids why WPI does this?

Arcade Drive.png


Arcade Drive.png

On the robot it behaves properly, so it’s probably just a matter of two approaches to invert motion-left side or right side.
The default code chose to invert the left side.
If the default chose to invert the right side instead, then the Arcade mapping would be inverted into what you expected to see.

Using the default Arcade project…
If I press to the left, then the left motor goes forward (the left motor is inverted in the default project).
The right motor is opposite, so it also goes “forward” which is mechanically backwards on the robot.

Or is this the old legacy of the flightstick orientation where forward in a plane is down (-1) and back (1) is up?

In some cases this is true but it is not my point. I am not talking about the default code or the default robot operation out of the example. Everyone has the motors hooked up differently so discussing how the robot actually operates is just a matter of how you set it up.

This is extremely non-intutive! Seems everyone would be saved a lot of trouble by not doing it that way. Furthermore this screws up the motor outputs you see coming out of arcade so plotting that to the dashboard creates some really “unexplainable” outputs

I would believe and understand that for the Y axis as a lot of flight controllers have the Y axis inverted or not but it seems silly to invert the X axis!

I am strictly speaking about this VI. I input X axis values and the left/right motor output values it gives are backwards. Am I wrong?

Sorry, I didn’t mean to impinge. I didn’t understand you were just filing a complaint.

Mark you are fine, thank you for the help! I was really hoping I was wrong and that there was some logic here that I wasn’t seeing.

Not even sure who I would file that complaint to, but I think that there is a good deal that we could do to make the basic setup / motor inverted or not process a lot easier. I know teams I work with spend way to much time figuring out if motors are inverted or not each time we get a new robot and configuring this in software. Then with everything “figured out” we set up our auto routine and this specific VI commands the opposite with no documentation or anything to explain why.

Maybe I can help more when this library is being developed?

The library was primarily developed in 2008 with revisions and additions taking place over the first few years of it’s existence.
I remember complaining about the arcade choice myself in 2009.
(Our drivers never use arcade style so it’s never been of much importance to them.)

It’s now been pretty static for a few years now (and personally I like it to remain mostly unchanging).

The best time to bring up proposed changes is in the Fall during the Beta testing phase. Suggestions can be sent directly to FIRST (not likely to accomplish much without a champion) or through a Beta test team near you (a champion) if you aren’t on one yourself (the list is published).
Early Fall is when the appeal for Beta teams goes out (FRC Blog post was on Sept 13, 2017 for this season), so sign up when you see it. FIRST then selects from the pool of those applying to get a balanced group.](https://www.firstinspires.org/robotics/frc/blog/2018-beta-teams-brushless-game-specific-data)

Sorry I didn’t see this earlier – lots of work and family stuff this year.

As Mark pointed out, this is really just a matter of convention. If you run the VI with X set to 0, and Y set to -1 (joystick throttle forward), the motor outputs are (-1,-1). Therefore -1 power value drives the robot forward and 1 drives it in reverse.

With that observation, the joystick values with Y set to 0 noted above should also make sense.

Is this a good convention? ??? It is arbitrary and based on the HID conventions. It has been in place for about 10 years in FRC and longer in HID.

Perhaps ten years ago we should have shunned HID and defined a custom convention, with internal mapping. We decided to expose HID as-is and let teams learn the standard or map it in their own layer.

Either way, I don’t think it makes sense to flip everything for 2019. Agreed?

Greg McKaskle

I agree it is all a matter of convention. That being said I think it is highly unintuitive and simply leads to confusion and mistakes.

I know you are describing how it is, but if you handed this to someone and asked them to program things how many of them do you think would get it right? Even if you handed this to an “expert” programmer I doubt they would get it right because the not only is it counter intuitive it is undocumented. So you literally have to either know from prior experience how it works or run it just to find out.

I am personally opposed to keeping conventions just because that is how people did it in the past. Especially when those conventions were initially developed around a different use case (planes).

Maybe I am the only one that feels this way I don’t know. I don’t think the change necessarily has to be this year, but if not this year when?

At a bare minimum I think we need to put something there documenting this similar to what text based has “y - The speed that the robot should drive in the Y direction. This input is inverted to match the forward == -1.0 that joysticks produce. -1.0…1.0]”

I prefer sticking to the HID standards to stay compatible with other controller implementations.
For instance, for one of our robot years we are able to swap between a single joystick arcade controller and a steering wheel style controller with no code changes.
During the time the robot was in competition the drivers swapped a few times during the competition on the fly.

It also makes it easy for drivers to try the different style controller.

I don’t understand why you think my suggestions would preclude what you are talking about? We aren’t just changing one controller we are changing the interface layer between all controllers to the motors.

The only change the users would experience is seeing more easily understandable results on the dashboard and not having to treat all -1 motor values as forward.

I in turn don’t understand why you think my comments preclude your suggestions.

In this example it looks like you are suggesting that this is an advantage that the current implementation has over what I am suggesting. What I am pointing out is that I believe this example would be the exact same no matter if we make the change or not.

No I am not suggesting what you seem to infer.
I’m supporting Greg’s mention of HID.

I completely agree that all conventions need to be documented.

The coveted right-hand-rule is not helpful until you know what the thumb, index finger, and curved fingers actually mean. And then you just look like a wack-job whenever you are mumbling to yourself and gesturing your right hand about.

And of course if you see someone doing this with their left-hand … what is that person doing?

Greg McKaskle

Maybe doing it for motors?

Here is your TIL for the day.

Fleming’s left-hand rule for motors

To be honest I didn’t know it existed either as I just program the robot. :smiley:

Intrinsically adjusting for the negative charge of electrons, of course :smiley: