[FTC]: Tetrix motor controller weirdness with 4 motors

[F Elliott]

I believe I am seeing the same problem. I think the new v2 motors are the root cause.

CONFIGURATION:

#pragma config(Motor,  mtr_S1_C1_1,     LeftMotor,     tmotorTetrix, openLoop, encoder)
#pragma config(Motor,  mtr_S1_C1_2,     RightMotor,    tmotorTetrix, openLoop, reversed)
#pragma config(Motor,  mtr_S2_C1_1,     FlagMotor,     tmotorTetrix, openLoop)
#pragma config(Motor,  mtr_S2_C1_2,     LiftMotor,     tmotorTetrix, openLoop)

Robot is up on blocks. FlagMotor and LiftMotor are DISENGAGED from the gear drives; i.e., no load.

TEST #1:
LeftMotor: v2 Tetrix DC motor
RightMotor: v2 Tetrix DC motor
FlagMotor: ORIGINAL Tetrix DC motor
LiftMotor: v2 Tetrix DC motor

Robot drives just fine, low to max power, forward and reverse. FlagMotor is also fine. No surprises.

However, whenever you run LiftMotor (the third v3 motor in the set) for more than a few seconds, the NXT "loses connection", the downstream servo controllers go ape, and everything freezes, requiring a hard boot of the NXT and usually ROBOTC.

I've tried various changes in pragma (daisy chain, parallel, swapped the controllers...) to no effect. I have not tried swapping the order of the motors in their sequence.

TEST #2:
LeftMotor: v2 Tetrix DC motor
RightMotor: v2 Tetrix DC motor
FlagMotor: Original Tetrix DC motor
LiftMotor: ORIGINAL Tetrix DC motor

NO CRASH! Everything seems to run just fine with one of the original motors as the fourth motor. In fact, I can run all four motors simultaneously at max power, forward and reverse like a madman.

Now my problem is this: As a rookie team, we were shipped four of the original motors with the plastic gears in our KOP. LEGO Education recently sent us 4 v2 motors as replacements. We have not received our "gear replacement" kits. Our LiftMotor probably cannot be relied on as a plastic gear motor. Should I swap the metal gears from one of our v2 motors into our original plastic gear motors?

WHAT A MESS. We've also been unable to get an encoder to work so we're having to run open loop in autonomous. Advice on that problem is we got a bad encoder. Our first competition is next Saturday and we can't even get past our basic motor usage due to problems created by the exclusive vendor's failure to manage their supply chain. I imagine you guys have been living with this for years but as a rookie coach I find this especially shocking.

I am in a near panic at this point. The team has worked so hard and mechanically our robot is finished. However, we'll be lucky at this point to show up with a robot that does little more than drive.

[aklego]

Originally Posted by F Elliott

I believe I am seeing the same problem. I think the new v2 motors are the root cause.
...

TEST #2:
LeftMotor: v2 Tetrix DC motor
RightMotor: v2 Tetrix DC motor
FlagMotor: Original Tetrix DC motor
LiftMotor: ORIGINAL Tetrix DC motor

NO CRASH! Everything seems to run just fine with one of the original motors as the fourth motor. In fact, I can run all four motors simultaneously at max power, forward and reverse like a madman.

This is extremely interesting. Anyone have any ideas? Our problem was remarkably similar. We "solved" it by adding a dedicated controller but still have no idea what the fundamental issue is.

[F Elliott]

I tried swapping order of the motors. Order doesn't seem to matter. Two total v2s on two motor controllers (combined or split) works fine. Add a third v2 to either controller and kaput.

We do not have a third motor controller or I would try it. We are going to use a plastic gear original motor and hope for the best. Sigh.

[Al Skierkiewicz]

F,
Everything you describe makes me think the fourth motor is drawing tons of current when used with the lift. If the old motor works and does the job, I think that is your fix. Of course you can swap the flag motor for a V2 motor and that should be ok if you are running low on motors. However, it is also possible your electrical layout is putting some electrical loss into the lines feeding from the battery out to the various other systems. My suggestion is to make the wires the largest gauge and the shortest possible run you can make. I am still confused as to why the NXT locks up during this event. I can only guess that the I2C data gets corrupted during the brownout.

[F Elliott]

During the test, all the motors are unloaded.They are free running. The motor leads are those supplied by Tetrix.

Our "old" motors were shipped to us with plastic gears. We wanted to use one v2 motor on the lift and two more as drive motors so we don't run the risk of stripping the plastic gears.

Any two v2 motors work in any combination or purpose. Add a third v2 anywhere and the controllers go wacko.

[Al Skierkiewicz]

F,
As I understood your statements, the lift motor is not unloaded but being used for the lift. Is this an incorrect assumption? A picture of the wiring would be a great help.

[mikets]

Our team has very similar problems. This actually started last year where the motor controllers would freeze when the robot ran into things hard and we would be dead in the water until we power cycled the main battery. We tried everything from swapping motor controllers to tracing through wiring, swapping and bypassing ports. Nothing worked then the season ended. Then this year with a new game and new robot design (but reusing old controllers), we started okay but then the problem started to appear again. Eventually, we swapped the NXT brick with my personal brick and the problem has disappeared so far. But not knowing why and the real root cause, it may be a time bomb. We took apart one of the Tetrix controllers and ohm check the two RJ12-like connectors and found that 5 out of 6 pins are tied from one port to the other. My understanding is that the port contains an analog pin. So the 1 pin that's not tied to the adjacent port must be the analog pin. But this means the I2C bus is a passive pass-through. If that's the case, the theory on one controller froze causing all the down stream controllers to malfunction is now questionable. Don't know if it's related but our robot suffered serious electro-static discharge issue this season. Every time there is a discharge, our brick would hang causing us to lose half of our matches. That was a terrible day apparently because the weather was too good and too dry. It might explain why when we swapped the brick to use my personal brick, our motor controller problem also went away (at least for now). My personal brick was never used in competition so it never suffered any electro-static discharge as the team bricks have suffered for so many years. I would really like to get to the bottom of this issue so I don't have to worry about the time bomb blowing up on us (especially during competition).

[F Elliott]

Thanks Al for your suggestions. I wasn't clear earlier. In the test the lift motor's gear was removed from the drive shaft so there was no load on he motor when it was ran.

We ran out of time and went with a plastic gear motor last Saturday. We didn't have a problem with that. whew! I plan to look into this whole issue more carefully when the season is over.

Static electricity history of the NXT... Hadn't thought of that as a possibility. We only have our one NXT so can't test that but maybe I can borrow one.

[Al Skierkiewicz]

I was wondering what battery you are using for the NXT and what version brick do you have? years ago we would fight loose battery terminals that would break open with a robot hit. Just that small interruption would halt instruction execution. A little tender loving care (stretching the battery springs) and some alcohol on a Q tip did wonders for the reliability.

[F Elliott]

It's a new NXT that came in this year's competition kit with the rechargeable battery pack. We put the battery pack in it the first day and it's never been removed.

We are going to relocate the NXT for regionals so we'll have it pulled out within the next week. I will look carefully at this as a possibility.

See my new post today concerning losing control during the match.
http://www.chiefdelphi.com/forums/sh...d.php?t=124628

We've got a gremlin somewhere in our robot and it may indeed be unstable NXT power. It's one of the few things we haven't seriously looked at by now.

[Al Skierkiewicz]

OK,
The other really common issue is the Samantha module losing USB connectivity. You can usually tell if you can see the tally lights. Power is critical for the Samantha module and is often the problem with connectivity issues. The USB cable is also an issue if it vibrates during game play. It should be secure at both ends. It is not designed for vibration.

[F Elliott]

I just got through watching some videos of our matches trying to watch the lights. The all seem to be going crazy off and on but I can't really tell since there is so much camera movement and people jumping up and down. These parents really need to be more calm at these things LOL

[mikets]

In our case, we used Bluetooth and have verified at the time of the freeze Bluetooth was still connecting. We verified by turning on the "audible feedback" of the communication. So when it is still connected, the brick beeps. Also, we have two motor controller chains, one on sensor port 1 and one on sensor port 2. It was the chain in sensor port 1 that was frozen, the motors off the chain of sensor port 2 were still functional so we can raise the arm and slider etc. The chain off sensor port 1 is the drive train. That prompted us to replace the brick, thinking sensor port 1 somehow is damaged.

[aklego]

I came across another team's robot with the same problem today--4 V2 motors on single controller. They would randomly cut out while unloaded and the controller would need to be power-cycled to force a reset. There were no shorts. I do not have an explanation but the V2 motors seem to be the common denominator.

[VashonRobotics]

We ran into this very problem at our last competition. Two of the DC motors on the bot are the new style. Symptom: Sam module lights on, LEDS to motor controllers on. No control from game controllers EXCEPT the one NXT motor that the bot has, it still worked normally. All wiring was gone through - no tinned wire ends in motor controllers just bare copper, Anderson Power Pole connectors at battery, short USB cable with ferrite core. I think this tells us that the game controller, FCS, Sam module, and NXT were all working, the problem had to be in the Motor Controller(s). A power off and on again and it worked fine.