Hello. My team is currently building a robot in which each side of the drivetrain consists of one 393 motor and two 269’s. In the diagram below you can see a very, very crude diagram of the drivetrain. The motors that have a green cable connected in the back have a motor controller connected, whereas the motors with a brown cable have no motor controller connected. The number at the end of each cable represents the port in which each motor is connected.
The problem arises in the programming of the drivetrain, completed with EasyCV4. The programming intended for the robot is an arcade control so as that forward on channel 3 = robot moves forward, backwards on channel 4 = robot moves backwards, and left on channel 4 = robot turns left, right on channel 4 = robot turns right. In the programming seen below the robot moves forward and backwards correctly but the turn is inverted. It’s as if only channel 4 was inverted.
First I would suggest putting the 393s into ports 1 and 10, it just seems to work better that way. you are going to need an Arcade 4 motor for the 4 269 motors and an arcade 2 motor to power the 393’s. the 269’s should be in ports 2,3,8,9
Thanks for the reply, but I don’t seem to understand how it would work better (it seems a better placement of ports for the sake of parity, though). Also this does not solve the programming issue.
The picture is good actually, except it is missing details like
which way is front,
chain wrap.
Your description of channels 3,4 is garbled.
Your Arcade programming popup pics do not match the filedropper code exactly.
Cortex ports 1,10 are reported to be “more powerful” than other ports, which is why devinc recommends the more powerful 393s to be there.
4port arcade merges two 2ports into one call, and has all the same flexibility,
so that would be recommended, but it doesn’t matter much.
Your code shows motors 3,5 as invert0, but that doesn’t match the drawing;
Note that, for each side, the outer motors (eg 1,3) should be same as each other, but opposite of the center motor(eg 2), because of the gearing shown. Hopefully you have mislabeled the picture wires, or have otherwise plugged the 2 wire motors in to the MC inverted so that all the motors on one side are working toward a common goal instead of fighting each other.
The details are good, but getting them right would be helpful too.
All that nitpicking aside, your description boils down to “turns the wrong way”;
This is a common problem on Arcade.
It seems like you have confused the front and back of the robot.
This probably means you should do both 1 and 2:
swap motor positions between left and right motors.
swap the invert on all the motors,
You can debug it yourself if you just write down a table of which way you want each motor to spin under all 4 joystick conditions (f,r,l,r), then change programming to get that.
This is interesting, something I had not considered before. This is what we know about these ports.
Max current available is 4A (shared with four 3 wire ports), motor controller 29 has a 3A limit (so I read in a post by JVN recently).
The power into the H-Bridge does not have to travel through several inches of wire so the voltage may be a little higher (there will be a small voltage drop down the wires due to resistance).
In both cases the internal PTC for the motor will trip with a continuous current of 1.8A for several seconds.
I see some experiments being done over the holidays.
Check to see if the Hbridge chips are the same.
The internal ports in Cortex have better heatsinking because of larger PCB,
than the little blob-on-a-wire #29MC.
the above is correct, however, since this is a drive motor and will be used extensively (depending on how you drive), if you burn out the H-bridge in the cortex, its almost irreparable. however, if you just burn out the motor controller, its just a $10 fix
neither has happened to me before but if you search around, you will find this happening to other members
I’ve never opened up a motor controller, need one to die to justify the $10. I did look at the cortex a few months back, some photos of a Rev1 board here, I have a newer one around so will take a better look if there’s time over the holidays. I wish VEX would release schematics but guess there’s no need for them to do that. Hard to see part numbers on the H-Bridge chips but I think it’s done with discreet FET’s rather than an integrated chip. I was more interested in the micro-controllers at the time so was not paying much attention to them.
Actually, if the parts were available then they are real easy to change, assuming some skill with a soldering iron or course.
Some deconstruction report of MC#29 shows
Q1: Zetx FMMT491 NPN SOT23
U2: MicroChip PIC 12f615 8psoic
U5: Fairchild FDS4935BZ 8psoic -30V 7A Dual P-Chan MOSFET, ~30mOhm
U6: Alpha&Omega AO4818B 8psoic 30V 8.5A Dual N-chan MOSFET, ~20mOhm
peak pulse current on these up to 50A at 300us pulse 2% duty cycle.
(wow)
When a MC#29 dies, it may not be the chips.
Crushing the case width-wise in a vise, with a triangular file in series with the seam, may pop the plastic case rivets without damaging the circuit.
The Cortex pictures on Jpearman’s page show 8psoic chips at port1,10, on both sides. The one number I can read on chip U6 is same as U6 on MC#29. Likely all 4 chips are the same as MC#29, so any additional power capacity of ports 1,10 is likely due to : closer to battery, bigger PCB for heatsinking.
Vex guy said he has more luck repairing them soon after they break, than later.
