Invert Motors Physically or in Code?

[Zaque]

Hi all,
I was wondering if there is a "preferred" or "correct" method of inverting motors. Specifically, should it be done in code or by switching the wires, or by some other third method of which I am not aware?

Thanks,
Zaque

[Pratik Kunapuli]

I believe that the "correct" practice is to have all of the motors red-to-red and black-to-black, and then invert the direction in code.

[MichaelBick]

The only time we invert wires physically is if we are in a rush, but we always switch it back later. Otherwise we try to always change motors in code so that if we ever have to switch the motor nobody gets confused.

[markgryzwa]

It really doesn't matter.

[Tom Line]

Never invert wires. Because the very first time someone has to trouble shoot something, replace a broken component, or unplug the motor, it WILL get plugged back together with colors matching (backwards).

Always invert the code.

[Pault]

I'm not sure if "correct" is the right word. But, I think it is worthwhile to set a standard that positive always means forward/up/right (or forward/up/left if you prefer, just choose 1 and stick to it). If the wiring is the one not following that standard, change the wiring. If the code is the one not following that standard, change the code. The key here is consistency.

Another tip is to never swap the wires leading out of the motor. Always swap the ones in between the speed controller and the motor. On top of this, make sure all of your motors are wired the same way. This way, if a motor breaks, you can swap it out and not have to worry if it is wired the same

[Gregor]

I'm not sure if "correct" is the right word. But, I think it is worthwhile to set a standard that positive always means forward/up/right (or forward/up/left if you prefer, just choose 1 and stick to it). If the wiring is the one not following that standard, change the wiring. If the code is the one not following that standard, change the code. The key here is consistency.

Or you could just?

Never invert wires. Because the very first time someone has to trouble shoot something, replace a broken component, or unplug the motor, it WILL get plugged back together with colors matching (backwards).

Always invert the code.

[yash101]

I do not think that there is a correct or standard way of reversing a motor. Do it the way how you will find it easiest. If you are better at programming, use the code method. If you are good at electrical, rewire it.

Even though I am good at coding, I would prefer the rewiring method. On my VEX OmniBot, Heels, I rewired two motors backwards to allow me to use standard mecanum code for control!

Hopefully, this helps! :D

[Mr V]

I agree with Tom, always "invert" in code as the wiring and terminals are marked so that you can always connect them consistently no matter who replaces the motor or motor controller. In theory there is a much larger pool of people who might replace those items vs the pool of people who might change the code.

Much safer to comment the code that L drive motors are "inverted" than to make sure that everyone who could ever possibly change a motor, including people on other teams who may be lending a hand in the heat of the moment between finals rounds that the L drive motors are to be hooked red to (-) and black to (+). It could be particularly disastrous should you have a dual motor system and to wire one of the motors backwards so that they are fighting each other. Best case secnario your robot doesn't function, worst case you let the magic smoke out of both motors or motor controllers and now you've got two to change before the next round.

[Tristan Lall]

One more vote for "invert in code". This is the more robust design practice for the many reasons enumerated above.

There are very rare exceptions like having multiple motors which need to operate on a single motor controller, but in opposite directions. Or perhaps there's nobody who knows how to manipulate code available at the moment. Absent that kind of very special situation, invert the motors in the code.

[orangemoore]

I think that it can really depend on the situation. For instance my FTC team 3507 has built a mecanum drive train this year. And as the programmer for it accounting for one side of the motors being reversed is easy in code. But it becomes very complicated to understand what the values sent to the motors should be. It that case I would have voted for reversing the wires.

A side note

If you swap the wires you shouldn't just make a mental note. You should have something visible that says they are swapped. In competition any knowledge like that will most likely be forgotten.

[BBray_T1296]

I believe in our code we have "invert" variables, one for each motor. When the code gets to the "output/write" section, all values to be output are multiplied by their "inversion" variable, which is assigned as either 1 or -1. That way if we are doing weird things such as mecanum, only a single number must be changed to guarantee an error-less inversion.

[DampRobot]

We use Anderson connectors, so we cannot physically insert the connectors together the wrong way. If we've assembled it to connect red to red wires, you cannot physically connect the Anderson connectors so black goes to red without intentionally disassembling and reassembling the connector. This means that if we change the order of the wires to change the direction of the motor, it cannot get accidentally reassembled incorrectly at a later time.

If we're at the point where were actually testing a mechanism for the first time (where this type of thing tends to be an issue), I'd much rather just take 30 seconds to break the Anderson connector apart and switch the leads than spend ten minutes changing the code, recompiling, and rebooting the robot. It may not be the "right" way, but it's a lot faster.

[MichaelBick]

Another good reason to switch it in code is that it copies over to our practice bot.

[Richard Wallace]

Programmers are generally the last ones to touch ANY system that depends on embedded software to function correctly -- and the more time they get to play with and perfect the code, the better the system will function. There will be plenty of challenges for programmers to overcome as they get the system ready to function correctly -- there is just no excuse for making arbitrary design choices in other aspects of system design that add to the challenge by creating extra factors for programmers to keep track of.

Wiring, on the other hand, can and should be standardized, and its configuration 'frozen', as early as possible in system development. Allowing those who wire the robot to adopt any convention other than "always connect red with red, and black with black, in every power circuit" is simply creating an unnecessary opportunity to lose a match.

[theawesome1730]

Code! Down the line someone is going to wonder "hey, why is this black wire connected to this red wire?" and switch them which could lead to devastating results if the component has the potential to be destructive

edit: hey, why is this black wire concocted to this red wire? oops.

[Oblarg]

It's worth noting that the color coding on the outputs of all motor controllers I've seen are green/white, not black/red, because they're meant to be reversible. If you ever see red->black on a properly wired robot, something is terribly wrong and you better not turn it on. Wiring the inputs of a motor controller backwards is a guaranteed way to ruin both the motor controller and your day.

That's not to say that you should not be consistent with your wiring and handle motor reversals in code; on your final robot, you definitely should plan for that, but it's not an issue of red->black (or, rather, it most definitely shouldn't be). I agree with the earlier poster who mentioned that swapping the wiring is the way to go in early testing phases; with the time it takes to compile/upload code with the cRIO (especially if you're using LabView), you will save much time this way.

[joelg236]

Just a quick additional reason to invert in code only - it forces you to program well. If you program in a way where one boolean can determine the "reversed" position, your code is well made. It forces you to code in a way where you can implement new features, functions, etc. quickly. Especially with OO languages (use polymorphism!).

Example (details omitted) in Java:

The bad way:

talon.setSpeed(-0.3)


The good way:

class ReversedTalon extends Talon {
@Override
public void setSpeed(double s) {
super.setSpeed(-s)
}
}

...

talon.speedSpeed(0.3)

[Zaque]

Is it acceptable to use the .setInvertedMotor method in Java?

[Pratik Kunapuli]

Is it acceptable to use the .setInvertedMotor method in Java?

I think that like mentioned preciously in this thread, it is better to use inheritance to your advantage and make a "reversed" esc class, whether it be a victor, talon or jaguar. That way, the code becomes much easier to diagnose because there aren't a bunch of .setInvertedMotor() lines that you need to keep track of, and it would instead be:

ReversedTalon leftDrive = new ReversedTalon(1);
leftDrive.set(1);

[MamaSpoldi]

Code! Down the line someone is going to wonder "hey, why is this black wire connected to this red wire?" and switch them which could lead to devastating results if the component has the potential to be destructive

edit: hey, why is this black wire concocted to this red wire? oops.

Absolutely agree! I have seen this happen many, many times. Also why would you want to train students to do things in a non-standard way.

I think that like mentioned preciously in this thread, it is better to use inheritance to your advantage and make a "reversed" esc class, whether it be a victor, talon or jaguar. That way, the code becomes much easier to diagnose because there aren't a bunch of .setInvertedMotor() lines that you need to keep track of, and it would instead be:

ReversedTalon leftDrive = new ReversedTalon(1);
leftDrive.set(1);

I strongly disagree with this statement. The purpose of the setInvertedMotor() method is to handle motors which should be logically reversed because they are on the other side of the robot (ie. in the case of the drive train). This method only needs to be called once for each motor controller object (eg. Talon or Victor or Jaguar) when it is created. There would be no need to call it multiple times or to keep track of anything related to it. Using this method is the correct way to implement this. It is part of the programmers task to understand how the robot was built and what accommodations need to be made to properly interface to the parts.

[joelg236]

I strongly disagree with this statement. The purpose of the setInvertedMotor() method is to handle motors which should be logically reversed because they are on the other side of the robot (ie. in the case of the drive train). This method only needs to be called once for each motor controller object (eg. Talon or Victor or Jaguar) when it is created. There would be no need to call it multiple times or to keep track of anything related to it. Using this method is the correct way to implement this. It is part of the programmers task to understand how the robot was built and what accommodations need to be made to properly interface to the parts.

Inheritance is the best way to do it. It's much clearer to say "ReversedMotor" than making a motor and reversing it later. What happens when one of your programmers wants normal motor behaviour (not reversed) later down the line? They call your inverse method. And if they neglect to switch back, you're in for some deadly consequences.

Another problem is the time between creating the object and reversing it. When is the correct time to initialize the reversed state? How can you guarantee that methods aren't called before that? (By accident or on purpose - think static initialization)

Always prefer inheritance and polymorphism to state. It'll help you in the long run. Settings for things should rarely be flags if you have better tools to use.

[apalrd]

I have always done the following:

-all motors are red-red and black-black in code (or + to red if its not colored)
-all analog sensors are wired the same between both robots (usually they are magnetic encoders or gyros which have polarity anyway but a potentiometer has no polarity)
-i haven't standardized on the digital sensors and digital actuators but I should probably set one as well.

-the 'application' code always reads the sensors using the forward/up/left standard and in engineering units and writes the motors using forward/up/left as well (with +-1 range)

-the boundary layer code handles negating and scaling (gain/offset or interpolation table) of sensors and actuators usually all in one file (well two, inputs and outputs)

-I have gravitated over the years to pulling the boundary layer code out of the application code for scaling, inversion, and selective disabling/override testing

[Brandon Zalinsky]

Do it the way how you will find it easiest.

I find it hard to concur with this opinion. If you have more than five minutes, get your programmer over, and do it right. As it has been brought up other times in this thread, if a motor breaks and needs to be replaced, there's a good chance that if you had the wires reversed, they won't be reversed when the motor is replaced. This can be catastrophic, especially if the motor in question is part of a 2-motor gearbox. I can see switching the wires if you have one minute until your next match, but if you have time, switch it in code.

[MamaSpoldi]

Inheritance is the best way to do it. It's much clearer to say "ReversedMotor" than making a motor and reversing it later. What happens when one of your programmers wants normal motor behaviour (not reversed) later down the line? They call your inverse method. And if they neglect to switch back, you're in for some deadly consequences.

Another problem is the time between creating the object and reversing it. When is the correct time to initialize the reversed state? How can you guarantee that methods aren't called before that? (By accident or on purpose - think static initialization)

Always prefer inheritance and polymorphism to state. It'll help you in the long run. Settings for things should rarely be flags if you have better tools to use.

In exactly the same way that your derived ReversedMotor class would always use the motor in that reversed "state", so too the SetMotorInverted() method can/should be called only once during it's instantiation (ie. in the constructor for the object it is part of) and therefore it would remain in that state during it's entire existence. It should not matter to the programmer after that initialization if the motor was inverted or not. That is the purpose of that method and that internal state. If that is not true (ie. if you might sometimes want to use it non-inverted and sometimes to use it inverted) then you should not be using that method you should design algorithms and coordinate systems to properly reflect the usage of that motor controller. If properly designed, the positive direction of the motor is consistent through out its usage.

My perspective would be that there is no need to derive additional classes when the functionality is already properly provided by the existing class.

[JesseK]

The only time to be lazy and invert the wiring is when the code you're dealing with is a 'black box' that is prohibitively expensive to change. Even then, there should be some sort of symbol on the wires that the wires are reversed intentionally.

This shouldn't be a factor in FRC because we're at least given enough time to do things correctly from the start.

For example, a legacy version of APM I used for my Quadrotor last year put all 4 propellers going the same way (i.e., no flight). The 'right' way to fix it was to dive into the firmware, find the bug and then spend a large quantity of hours learning something I wouldn't spend a second on after an official bug fix. Instead of wasting 20 hours, I reversed two motors' wiring so they spun to match the diagram and then put red/black zipties around the individual wires to signify which wire (even which side of the connection) was reversed.

[Pratik Kunapuli]

In exactly the same way that your derived ReversedMotor class would always use the motor in that reversed "state", so too the SetMotorInverted() method can/should be called only once during it's instantiation (ie. in the constructor for the object it is part of) and therefore it would remain in that state during it's entire existence. It should not matter to the programmer after that initialization if the motor was inverted or not. That is the purpose of that method and that internal state. If that is not true (ie. if you might sometimes want to use it non-inverted and sometimes to use it inverted) then you should not be using that method you should design algorithms and coordinate systems to properly reflect the usage of that motor controller. If properly designed, the positive direction of the motor is consistent through out its usage.

My perspective would be that there is no need to derive additional classes when the functionality is already properly provided by the existing class.
However, the thing that Joel was saying earlier in this thread is that by using inheritance, you can use polymorphism to your advantage and then have the code only execute the reversed state at run time. Also, like Joel mentioned, the cleanest way to do it is do have the inverted state handled in the constructor of the reversedMotor class. This reduces the amount of code you have, which makes the code cleaner and much, much easier to diagnose if there is something wrong.

[MamaSpoldi]

However, the thing that Joel was saying earlier in this thread is that by using inheritance, you can use polymorphism to your advantage and then have the code only execute the reversed state at run time. Also, like Joel mentioned, the cleanest way to do it is do have the inverted state handled in the constructor of the reversedMotor class. This reduces the amount of code you have, which makes the code cleaner and much, much easier to diagnose if there is something wrong.

I see your perspective and understand how inheritance and polymorphism work, it is just a difference of opinion as to which is cleanest. In my experience it is cleaner, especially since it is a single function call, to execute the setMotorInverted explicitly rather than hide it inside a derived class which does nothing more than that. In particular, if someone outside of your team were to look at your code (perhaps an FTA trying to help you look at a problem), they would need to look at the ReversedMotor class to determine what else might be encapsulated inside it and how that effected your code.

[joelg236]

I see your perspective and understand how inheritance and polymorphism work, it is just a difference of opinion as to which is cleanest. In my experience it is cleaner, especially since it is a single function call, to execute the setMotorInverted explicitly rather than hide it inside a derived class which does nothing more than that. In particular, if someone outside of your team were to look at your code (perhaps an FTA trying to help you look at a problem), they would need to look at the ReversedMotor class to determine what else might be encapsulated inside it and how that effected your code.

But the same applies to using setMotorInverted. You need to be able to find where that function is called, and when it happens. The motor is no long defined as inverted, but rather is set as inverted somewhere along the line. Sure, in practicality it probably won't cause problems. But it's much clearer to OO programmers to see


Talon t = new ReversedSpeedController(new Talon(1))


VS


Talon t = new Talon(1)

...

t.setInverted(true)

[Joe Ross]

Lets say you now want to make a speed controller that limits the maximum output. Do you define a LimitedTalon, ReversedTalon, and a LimitedReversedTalon?

This discussions is a little bit academic since Talon or SpeedController doesn't have an inverted method. RobotDrive does, however.

[BigJ]

Lets say you now want to make a speed controller that limits the maximum output. Do you define a LimitedTalon, ReversedTalon, and a LimitedReversedTalon?

Assuming the ReversedTalon extends Talon, you'd make a LimitedTalon that wraps a ReversedTalon (that wraps a Talon)

(I believe this is kind of an implementation of the Decorator pattern http://en.wikipedia.org/wiki/Decorator_pattern)

[MamaSpoldi]

Lets say you now want to make a speed controller that limits the maximum output. Do you define a LimitedTalon, ReversedTalon, and a LimitedReversedTalon?
Agreed.

This discussions is a little bit academic since Talon or SpeedController doesn't have an inverted method. RobotDrive does, however.
Point noted... I didn't take the time to look at the specifics. LOL That was definitely my mistake.

[Jared Russell]

I like to have one class per mechanism or subsystem, and these classes then have private instances of WPIlib primitives (Victors, Talons, encoders, etc.)

The rationale is as follows. The mechanism-level class knows "how" to do something. No other part of the code should know or care about the details (are we using Victors or Talons, what sensors, what PWM ports, what PID gains, are motors inverted...) If I need to look at how something works, there is one place and one place only that I ever need to look for any particular function of the robot. The benefits of this approach are numerable.

Within this framework, the scope is narrow enough that whether I use a ReversedSpeedController, call setInverted, or just multiply all the inputs by -1 it really doesn't matter. The point is that ALL the code that ever touches that speed controller is co-located in one cohesive package.

[Jared Russell]

Lets say you now want to make a speed controller that limits the maximum output. Do you define a LimitedTalon, ReversedTalon, and a LimitedReversedTalon?

Clearly we need a TalonFactory.

No, that's not generic enough. SpeedControllerFactory.

No, RobotDeviceFactoryFactory.

No, a FactoryFactoryFactory (http://discuss.joelonsoftware.com/?joel.3.219431.12)!

[BBray_T1296]

FactoryFactoryFactory (http://discuss.joelonsoftware.com/?joel.3.219431.12)!

This post

[joelg236]

Clearly we need a TalonFactory.

No, that's not generic enough. SpeedControllerFactory.

No, RobotDeviceFactoryFactory.

No, a FactoryFactoryFactory (http://discuss.joelonsoftware.com/?joel.3.219431.12)!


SpeedControllerLimitStrategyFactoryStateObserverAd apter

[Pratik Kunapuli]

Assuming the ReversedTalon extends Talon, you'd make a LimitedTalon that wraps a ReversedTalon (that wraps a Talon)


Agreed. This is how I would do it and since child classes in Java only have single inheritance (inherent only the immediate parent's methods), this would be fine as long as you don't make a hierarchy with more than 4 levels (although I don't really see a situation in which you would).

[yash101]

I do not see why motor wires are even color coded. They should be solid white, because a motor controller will anyways switch the polarity on demand.
They should add a jumper to the motor controllers for whether the motor is reversed or not. The sad thing is that you cannot just flip the motor over :(

[Oblarg]

I do not see why motor wires are even color coded. They should be solid white, because a motor controller will anyways switch the polarity on demand.

Because if something breaks and you have no easy way of knowing whether you've wired up the replacement with the proper polarity without turning on the robot and moving the mechanism, that's bad.

[Pratik Kunapuli]

I do not see why motor wires are even color coded. They should be solid white, because a motor controller will anyways switch the polarity on demand.
They should add a jumper to the motor controllers for whether the motor is reversed or not. The sad thing is that you cannot just flip the motor over :(

There is a distinct flow of electricity through the motor, which is why the negative and positive leads are marked by black and red wires respectively.

[yash101]

Yeah, but in many cases, that isn't followed. I guess that helps in finding the motor direction!

[MichaelBick]

Yeah, but in many cases, that isn't followed. I guess that helps in finding the motor direction!

If you always wire stuff in the same way, then you will never have a problem, so there is no need for a jumper. Just because your team doesn't always wire things the same way doesn't mean other teams don't.

[yash101]

Well, actually, our team is quite good at wiring things together and we rarely have any wiring failures. The only failures we had this year were toasted victors, a dead cRIO and a bunch of dead BAGs! :D. Otherwise, our wiring was flawless and we never encountered any problems!

[Gregor]

Well, actually, our team is quite good at wiring things together and we rarely have any wiring failures. The only failures we had this year were toasted victors, a dead cRIO and a bunch of dead BAGs! :D. Otherwise, our wiring was flawless and we never encountered any problems!

Why did you use smiley faces and exclamation points after talking about how you killed electronics? While quite often the release of magic smoke can't be helped, it's still not something to be happy(!) about.

Oftentimes the ! and :D and ::ouch:: and :rolleyes: and :yikes: (ect.) distract from the overall message you're trying to convey.

[yash101]

Well, it is just the irony. The list is long if you think of everything we blew, but if you account what we blew accidentally by bad wiring/other reasons, the list is null!

Sorry about the distracting smileys!

[MichaelBick]

Yeah, but in many cases, that isn't followed.

Sorry, I didn't mean to insult your electrical. I was responding to this quoted post because I don't think there needs to be a jumper, just because teams aren't setting a standard.

[yash101]

Well, that was just an idea. I think it was a good one because it would be standardized so anyone could understand it, even if they were from a different team!

[MichaelBick]

I can't think of a reason that someone from a different team would need to know if our motors are inverted. More likely it would be an unneeded waste of space because you can invert motors farther up.

[yash101]

Well, if you need a helping hand, or if someone is just looking at your robot's electrical! Also, this would be cleaner and easier to work with than negated values in code or wires connected backwards!

[MichaelBick]

I find that inverting in code is actually a lot cleaner for the reasons mentioned above. Even if somebody is helping you they don't NEED to know the polarity of the motors. Worse comes to worse it can easily be fixed in code.

[BBray_T1296]

When we help other teams (generally rookies), it is hard enough for them to troubleshoot why half of their motors are set to coast and half are brake. Usually the motor-controllers ended up the way they were because they were in their stock placement (with some jumpers arbitrarily set to C and some to B). Some teams had no idea what that jumper did until we explained it.

While a polarity jumper issue could be corrected in code instead of being strictly a hardware problem, I can still foresee a similar issue

[MamaSpoldi]

I like to have one class per mechanism or subsystem, and these classes then have private instances of WPIlib primitives (Victors, Talons, encoders, etc.)

The rationale is as follows. The mechanism-level class knows "how" to do something. No other part of the code should know or care about the details (are we using Victors or Talons, what sensors, what PWM ports, what PID gains, are motors inverted...) If I need to look at how something works, there is one place and one place only that I ever need to look for any particular function of the robot. The benefits of this approach are numerable.

Within this framework, the scope is narrow enough that whether I use a ReversedSpeedController, call setInverted, or just multiply all the inputs by -1 it really doesn't matter. The point is that ALL the code that ever touches that speed controller is co-located in one cohesive package.

YES, this is exactly the way we structure our code as well. Thanks for explaining it clearly.

[JesseK]

No, a FactoryFactoryFactory (http://discuss.joelonsoftware.com/?joel.3.219431.12)!

Or a HashMapMapMap !

[jlmcmchl]

YES, this is exactly the way we structure our code as well. Thanks for explaining it clearly.

I'm going to have to second this as well. Even though you may think "Nah, we can just flip the wires and we're good" or something along those lines, it makes for terribly confusing documentation. When conventionally, object A does action B, but in this instance it doesn't because of some odd reason, you've probably done something wrong.

So sure, flipping it via a couple of wires is easy on the short run. But in the long run, you code's only going to get messier as time goes on.

Source: I work at a company whose product is comprised of 15+web pages and is served to more then 20k companies. Standardizing everything that is done in a clear and adaptable way is really the only way.

[brennonbrimhall]

Never, ever, ever swap the motor leads. If your code becomes too complicated to accommodate the extra complexity of a minus sign, it's flawed architecturally.

I'm going to have to second this as well. Even though you may think "Nah, we can just flip the wires and we're good" or something along those lines, it makes for terribly confusing documentation. When conventionally, object A does action B, but in this instance it doesn't because of some odd reason, you've probably done something wrong.

So sure, flipping it via a couple of wires is easy on the short run. But in the long run, you code's only going to get messier as time goes on.

Source: I work at a company whose product is comprised of 15+web pages and is served to more then 20k companies. Standardizing everything that is done in a clear and adaptable way is really the only way.

Third. Not only does this paradigm have the benefit of keeping your organized, but it separates the logic well. The Talon class shouldn't care what way the motor's oriented. The subsystem definition should.

For a Java/C++ solution, if you have a discrete set of PWM values, just define them as constants with a negative sign. Otherwise, define a custom function in the class that swaps the sign.


public class Flywheel extends Subsystem {

private Talon flywheel = new Talon(1);

public final double flywheelOnSpeed = -.75;

public void flywheelOn(){
flywheel.set(flywheelOnSpeed);
}

public void setCustomFlywheelSpeed(double speed){
flywheel.set(-speed);
}
}


EDIT: A set of videos on the Command-Based Robot Paradigm by Brad is found here (http://www.youtube.com/watch?v=v0vt9yKLxUQ&list=PL8FF26A88C6D16C8F), should the OP be using Java/C++.

[yash101]

I do not want to confuse anyone with this, but this is some nice feature in RobotC. It doesn't have too much to do with FRC, but a system like this could be very nice:

#pragma config(Motor, port4, frontRight, tmotorNormal, openLoop)
#pragma config(Motor, port5, backRight, tmotorNormal, openLoop)
#pragma config(Motor, port2, frontLeft, tmotorNormal, openLoop, reversed)
#pragma config(Motor, port3, backLeft, tmotorNormal, openLoop, reversed)

Do you notice that the motor definitions have 'reversed' at the end if they are reversed? This cleans up code quite a bit. Those are my motor definitions for Heels, my OmniBot.

I hope this helped.

------------------------------------------
I really think that vex is amazing for prototyping and developing ideas and things for an FRC robot. Even better, if you wanted to, you could make a working model of your robot using VEX!

Please do not try this code on an FRC robot because it will just reject it as a syntax error! This is to just get a point.

Also, yes. I do agree! If code is hard to read, you messed up while writing it! It does take some effort, but it is completely possible to 'craft' your code so that it is readable. The same thing is to pertain with electrical, however, the dangers of not doing it right are a lot more harmful. Wire something in a way that you have a spiderweb of wires, and don't expect to get good results.