I love this design! I was wondering if you can make the gearing disengage from driving the wheels, so if you had driving wheels in the back and continue driving while the mobile goal lift is active, but with less power of course.
How does the concept of passive transmissions work?
@Vyx I can PM you.
@EthanT
The system can run both the mogo lift and drive at the same time, so you don’t need to disengage the systems. @technik3k 's team solved the math to get them to run at the same time. I don’t believe the math is too complicated.
oh okay, thanks
I wish they did. The math is actually very simple:
mogoPwr = ( upButtonPressed ? +60 :
downButtonPressed ? -60 : 0 );
leftFront = leftPwr; rightFront = rightPwr;
leftDiff1 = mogoPwr + leftPwr; rightDiff1 = mogoPwr + rightPwr;
leftDiff2 = mogoPwr - leftPwr; rightDiff2 = mogoPwr - rightPwr;
But you need to do something extra to use it on the real hardware. Somehow it takes my team at least one or two competitions each season to re-learn that we have real hardware with lots of quirks and non-lineriarities that are not obvious but shouldn’t be ignored.
We recently went to a competition with a 6 motor turbo drive sharing 4 of the motors with MoGo lift. Our 9.5 lbs robot could easily outrun everyone else on the field and we ended up being 1st seed and didn’t lose any games until the Final#2.
The effective gear ratio for the MoGo lift is 1:3.33(3) and with four motors it is a total overkill. It could lift the MoGo in under 0.5 sec and if you don’t set mogoPwr to 60 or lower it will fly off the intake.
However, 6 turbo motor power for the drive, while adequate for the light robot and roughly equivalent to 4 HS motors, is only as strong as 2.66(6) torque motors.
Does anyone want to guess what happened in Final#2 and what advice my team didn’t follow (for weeks) to improve reliability of their code?
that exact math works fine for us.
I would agree if your code would restrict the drive from moving when you lifting the mobile goal, but what would be the power level going to each of the motors if you try to lift and drive at the same time?
Let say you try to drive forward with power level 60.
I have seen @BottomNotch operate the lift while driving. I do not know anything about the code, but if he says that math is what he is using, then that math works.
Well, that is exactly what my team kept saying before the competition: “it works therefore everything is good” and I kept telling them that there are things that you cannot touch and feel but are measurable if you have an oscilloscope and are important… at which point they would stop listening. 
So, lets take a look at actual motor power levels sent to the motors if you are lifting MoGo and trying to drive with speed=60 at the same time:
leftFront = leftPwr; ==> 60
leftDiff1 = mogoPwr + leftPwr; ==> 60 + 60 = 120
leftDiff2 = mogoPwr - leftPwr; ==> 60 - 60 = 0
As you can see, while the Front wheel and Diff1 motor are working, Diff2 motor is slacking, so you end up with just two motors doing the double work of lifting and driving. So my team’s response was: “we are just going to drive slower - now it should be totally ok”
leftFront = leftPwr; ==> 45
leftDiff1 = mogoPwr + leftPwr; ==> 60 + 45 = 105
leftDiff2 = mogoPwr - leftPwr; ==> 60 - 45 = 15
Everything adds up and would work if we had perfectly linear speed controller, however for MC-29 it is not the case:
https://vexforum.com/index.php/attachment/56464d7f703af_MotorControlSpeed.jpg
Effective power level going to the motors will look more like this:
leftFront = leftPwr; ==> 45 ==> MC-29 ==> 95
leftDiff1 = mogoPwr + leftPwr; ==> 60 + 45 = 105 ==> MC-29 ==> 110
leftDiff2 = mogoPwr - leftPwr; ==> 60 - 45 = 15 ==> MC-29 ==> 30
Now the numbers, instead of being better, simply do not add up.
As a result of the nonlinear nature of MC-29, depending on requested drive power, one of the motors will carry additional load and will start overheating. You cannot see PTC beginning to overheat without special equipment but the problem is still real.
So the solution to avoid uneven motor load is, first of all, to map the control values going to the motors with True Speed array or polynomial. Then, for extra credit, you could use Smart Motor Library to estimate the state of your PTCs and then either slow down the drive if they are starting to heat up or, at least, warn the driver with flashing LED that they are getting close to the danger zone.
Why is it important?
Here is what happened in Finals #2 and #3:
The opposing alliance figured out that our 6m turbo drive is no match for their heavier robots and started to engage us in pushing. Our driver didn’t realize the danger and ended up with stalled drive train.
In the very end of Final#3 one of the diff motors must have died as our robot was trying to score in 10pt zone but couldn’t. We were able to place MoGo only in 5pt zone and lost the game (and title of Tournament Champions) by only 3 pts. Had the PTC survived few more seconds the result would have been different.
The takeaways from this competition are:
- Passive MoGo transmission works great (even though it is not passive)!
- Software is just as important as hardware and, in this case, even more so.
- Do not engage in pushing battles with heavier robots if you have only 6m turbo drive.
However, if you could build 8m turbo or 6m HS differential drive with the proper software support, that would be a different story…
Thanks for sharing.
Would like to know your opinion in this - since you mentioned that 4m mobile goal lift is overkill, then is there still any point in doing motor sharing ? Or will it make more sense to just have dedicated motors instead?
Let say you had 6 motors reserved for drive and MoGo lift. Your “regular” allocation would be 4m HS drive + 2 motor lift (or 5m drive and 1m lift).
With shared motors you could build 6m turbo drive that would have more speed with the same torque as 4m HS as well as have 4m powering the lift. You get plenty of additional speed and power without using any extra motors. It is a win-win for both subsystems.
It is slightly more complex build, that requires additional planning, but it is perfectly doable for a team with 2-3 years of experience.
However, the crucial deciding factor, if one should build it or not, would be the willingness of the team to really learn how and why this works, understand its limitations, and be prepared to invest some additional time into programming control software.
As you can see from my example, this setup could easily give you false sense of extra power without safeguards that ensure you can actually use this power reliably.
In any case, this a perfect learning opportunity to once again teach students about motor characteristics, PTCs, load balancing, differentials, mechanical basis of this setup, reliability considerations of linking two systems, etc…
I would not pass it, even if some teams decide to stick with more traditional setup at the end.
@technik3k we attempted to build a shared motor drive, but being new to vex, we were unsuccessful. I mean it worked, but the mogo lift didn’t have the range of motion we had hoped for. Because the gears would hit each other when it was up or down, so we had to make mechanical stops which limited the range of motion to where it had a very difficult time putting goals in the 20 point zone. When you built yours, did you use the sprocket and chain version that antochamber shared? Or was It the one with gears that antichamber also shared?
@technik3k I know our team that uses this does not use the smart motor library since they are using PROS but address these issues in other ways. I am not a programmer. I am the mentor which in my case, it means cat herder. I know that he has code that helps prevent motor burn out, but I simply do not understand it. It is hard to teach an old dog new tricks. The basic math for the lift/drive, though, are what he is using for that.
We use 84T gears and have arrangement similar to the one shared by @antichamber in OP. I actually envy his latest build, because he has almost no extra parts - only functionally necessary components. We have much more metal, but a lot of it is cross-bracing that is a must have to survive rough 2v2 play.
I agree, in majority of cases basic math works and there is no need to do anything else. I know @BottomNotch is building 8m drive which should be stronger than most of the robots he is going to face on the field, so it would not be as much of a concern as with our 6m turbo drive. Still I would encourage him to go beyond basic math and adapt Smart Motor Library not only for the sake of learning, but in case if his robot encounters very tough opponent where every bit of PTC resource will count.
@technik3k I do not think the smart motor library is written for PROS but he uses other libraries that accomplish much of the same things. I know, for example, he uses motor slewing. One of our other teams is using RobotC and he suggested that to that programmer. He does a lot of the same things but without JPearman’s smart motor library. Of course if you are using RobotC you should be using that, but if you are using PROS, there are other similar options.
so I use P control on the drive. this is the code I use to set the target based on the joystick.
fbcSetGoal(&driveLFBC, (int)getSensor(driveEncL) +
joystickGetAnalog(1, 3) + joystickGetAnalog(1,4));
fbcSetGoal(&driveRFBC, (int)getSensor(driveEncR) +
joystickGetAnalog(1, 3) - joystickGetAnalog(1,4));
though I don’t use trueSpeed this actually limits the the control value to 88 (with my current P term, if that were to change I would have to add a multiplier), which is probably a factor as to why it’s working so well for me. So I guess I do have a bit of extra math. Though I don’t limit the maximum power being sent for the mobile goal and I don’t have trouble intaking mogos at full speed (though putting them back down with cones on it is a different story :P.
Also, with the 8m drive, even though I’ll have more torque I’ll actually be more concerned because of a certain TSqStrat I plan on employing, but I’ve said too much already 
Yes, it is good that you use PID, then the “I” should be able to adapt to variable load dynamically, and limiting slew rate will help to protect motors from sudden current spikes.
Then, I assume, you will use PID of some sort to control desired movement of MoGo lift as well.
However, the final step before sending power level to the motors should be to remap control values with true speed to correct for MC-29 motor controller’s non-linear characteristics. I may sound like a broken record, but this is very important to distribute load properly between drivetrain differential motors.
If you don’t do this step, then one of the motors could be pulling up to 20-25% higher load than its siblings (green vs blue lines on the graph), resulting in its PTC getting hotter, while it could be easily avoided.
It is very easy to add TrueSpeed to your program - one global array and a function with a couple of if() statements to check for sign and upper array bound. Just make sure you follow this workaround or latest version of RobotC may have issues uploading the code: