Programming the planetary (Taiwan) drive

Now that planetary drives are suddenly becoming popular I thought it worth getting feedback on the best way to control them from a programming perspective. For this discussion the choice of tank or arcade style control is not important so lets just consider tank style. Normally this is done as follows (pseudocode)

LeftMotorSpeed  = LeftJoyStickValue;
RightMotorSpeed = RightJoyStickValue;

With the Taiwan drive we now have the choice of running in torque mode with an effective gear ratio of 1:1 (ignoring any other external motor to planetary drive gearing) or speed mode with an effective gear ratio of 1:4.33

So whats the best way of choosing between these two, I see a couple of choices.

  1. Have a “turbo” button. The drive is usually in torque mode and when more speed is needed the “turbo” button is pressed. This could also be in reverse, ie. the button is a “power” button with the drive normally in speed mode and the button pressed when pushing power is needed. Suddenly changing the direction of one motor will need thought and perhaps use of slew rate control to reduce damage.

  2. Create a CVT style of control. Based on the formula we came up with in this thread, a graph of output speed vs the two motor speeds is as follows. (this graph ignores the fact that due to gearing one motor may in fact already be reversed)

[ATTACH]5911[/ATTACH]

For speeds below the maximum torque mode speed the drive can remain in torque mode, as more speed is needed start to reverse the direction of the ring gear motor (the chain on the Taiwan drive) to give additional speed.

This is free running speed and does not take into account additional speed loss due to load on the driven wheel, however, it is a good starting point.

So what are the programmer’s thoughts? Any other clever ways of controlling this drive?
planetary_speed_graph.jpg

1 Like

More of a something-to-think-about reply than an actual answer, but how about using the accelerometer in the joystick? Its a pretty terrible instrument to use to drive, as it won’t get you precise results, but what about using it to control how much torque you’re putting in?

I would just have a high-speed setting and a high-torque setting where the magnitudes of the motor powers are always the same (but one motor is reversed). Your mechanical lock will keep the motors going at the same speed, so there’s no reason to vary the magnitude of the power between the input motors.

All,

In 2002, the FRC team I mentor created what we called a crazy chicken transmission using the principle of rotating the ring gear to change the speed ratio. We actually still have a pending patent application for this design as it applies to dc motors and mobile robotics. In any case, as a teaching tool for my students, I went through all of the engineering mathematics that governs this design and published a paper that can be found here: http://www.chiefdelphi.com/media/papers/1361

Some words of advice using this design:

  1. The gear ratio as we know it does not change, only the speed ratio changes. Basically, the torque you get when the ring gear is not spinning is the same output torque you get when it is spinning IF the ring gear motor gear train is appropriately sized for the reaction torque. In a traditional ring gear implementation the housing takes all the reaction load from the planet gears, but in this implementation the ring gear motor must take all of that load.

  2. If the speed of the ring gear is properly selected, then you can get a “crawl” speed by spinning the ring gear motor in the opposite direction of the main motor. This is a really cool thing to see. You can also get it to sit still while running the motors at full speed. This is advantageous since it will prevent your motors from stalling if you are in a position and want to sit still without stalling motors.

To reiterate, you get the same output torque in both conditions as long as the ring gear motor is geared appropriately, but to get the speed ratios described above I suspect the ring gear motor will be the limiting factor in torque.

As far as control, I would no doubt use motor encoders on both motors and utilize speed control to get different speed ratios so you can keep the motors spinning as fast as possible the duration of the match. In our implementation in 2002 we just had on and off in each direction.

One last note: I have not looked at this in almost 10 years so I am sure it can use some updating. If I can convince some of our interns, I may have them recreate the CCT in VEX using the motor encoders and some of the design ideas from the recent VEX robots. I may have just found a good enough reason to make a VEX planetary gear set, although the chain implementation is pretty awesome.

Paul

2 Likes

I hav been thinking of the exact same ideas about programming the drive system this whole week.

Another option would be to turn the torque drive as the drive shaft is closest in velocity to 0, and once the torque (ring/carrier, depending on how you gear it) reaches maximum power, turn on the other drive.

Both options seem [in theory] effective in lessening of motor load. I shall experiment with this as soon as my implementation of a simple planetary transmission bot is completed.

Errrr… a few of us MAY have spent some time this evening running through the math on this. We MAY have also been playing with some 3D printed ring-gear sets. :slight_smile:

We MAY have a few fun ideas of our own, boss. :smiley:

-John

1 Like

:cool:

A little off topic, but that would be a great new product!

ears perk up
http://dramaticchipmunk.org/chipmunks/xMj9z5bX6913361046400ytK7o0w636M2S8w352.gif

1 Like

This is how I would program the “Taiwan - Planetary” Drive:

pseudo code


Right_Drive = Ch2
Left_Drive = Ch3
IF ( Ch7u == Pressed ) // Channel 7 Up Button
{
     Drive_Style = Speed // Assignment, "Drive_Style" is a variable which controls the motor directions
}
IF ( Ch7d == Pressed ) // Channel 7 Down Button
{
     Drive_Style = Torque
}
IF ( Ch7r == Pressed ) // Channel 7 Right Button
{
     Drive_Style = 1_to_1 
}

^^ This would be inside the “Operator_Control” function.
Below would be a function titled “Motor_Controls” and would run inside of “Operator_Control”


IF ( Drive_Style == Speed )
{
     motor1 = ( -Right_Drive )
     motor2 = ( Right_Drive )
}

//I'm sure that by now you guys get the point.

This would allow for manual control of the modes, but the whole point of this planetary transmission is that you can smoothly change the speed of the system by turning another motor. Your code would suddenly add another motor to the system with the current power. The code jpearman posted would ramp motors the motors up/down depending on their current states to ramp up/down the speed without putting too much strain on the motors at once.

Upon attempt to import the SolidWorks files into Autodesk Inventor to get a 3D view of the mechanism, I encountered errors. What version of SolidWorks was used to create these models? I am using Inventor Professional 2012. I have an installation of Inventor Professional 2013 installed at home, which I will attempt to use later, but I would like to know what version these models are to know beforehand if it is simply a version issue or simply won’t work, period.

Thanks!

I think it was SW 2002. There should also be STEP files that should work. I will try to bring them in to a newer version of SW and export to Inventor.

I actually noticed the STEP file today, which opened fine in Inventor, though there were no physical gear teeth in the file. Do the SW files’ gears have textured teeth that would export differently to Inventor? If it doesn’t work out, then the STEP file would work just as well.

Thanks!

(sorry for getting a bit off-topic, jpearman)

For those who just want to view Paul’s design, you can open the solidworks assembly in eDrawings, a free 3D viewer for PC, Mac and iPad.

[ATTACH]5914[/ATTACH]

No problem, it’s all very relevant.
chicken_drive.jpg

1 Like

There’s another patent here that would probably be infringing on yours had the patent been granted, same basic principle.

http://www.google.com/patents?id=gwPfAQAAEBAJ&printsec=abstract#v=onepage&q&f=false

1 Like

Well since we went public with our design, I can tell you that at least claim 1 of the patent you referenced could be defeated since it has been public knowledge since 2002. That still looks like an application and has not been awarded. I am sure they will run into the same obstacles we did when trying to get the patent approved.

1 Like