Looking for some advice for planetary gearbox modelling in A/Car

Hi,

seems you are trying to achieve something like this, this is done in AVIEW although I also have an ACAR model:

To help you through statics and get the initial conditions sorted I added inplane joint primitives between each different gear pair (4 in total). you can deactivate these during dynamics otherwise they won't allow the gears to rotate.

good luck

Thanks,

 

Alexis

Alexis,

 

Thank you for your answer. Did I get it right that 4 gear pairs are 3 sun-planet pairs and 1 planet-ring pair?

 

I've started working on it and see that it really makes sense (tried in the model with a single planetary set).

But when it comes to a gearbox with a number of planetary sets, the issue of gears locking for a chosen gear number still remains. I will try to think it up and then let you know the result.

Hi Viktor,

I did it like this and fixed the carrier to achieve a 5:1 ratio. The amount of planets, teeth number on each gear pair is up to you within the following limitations:

sun_teeth_no + 2*planet_teeth_no = ring_teeth_no

(sun_teeth_no + ring_teeth_no)/ amount_of_planets = integer

have a look at www.thecatalystis.com/gears/

 

thanks,

Alexis

Alexis,

 

I've worked your advice out, so I linked all the gear pairs with inplane joint primitives, and also added some couplers in order to remove degrees of freedom between the planetary sets for sake of static equilibrium. It was quite easy to check it in A/View and in A/Driveline because of simplicity of the code in ACFs. But there is a different approach of commanding events in A/Car, as there are routines, like abgVDM::EventRunAll, which contain the commands for static, IC and dynamic events at once. And I guess I need to intervene in this routine somehow to disable temporary joints.

 

As you said you had used this approach in A/Car, could you please give an advice how to deal with it?

Hi Viktor,

 

Glad to know that things are working now in AView although I didn't need the couplers in my system to make it work.

 

You are right about ACar things are a bit more complex there and the joint primitives won't deactivate. The way around this is to add 'ic_joint' to all the ic joints names you want to disable during dynamic simulation and switch on the ADriveline plugin. the reason for this is that a subroutine that lives there will search for 'ic_joint' statements and disable them before dynamic simulation, you can see this in the msg file afterwards. Currently this method requires you to manually check that the plugin is on. Adams adds to the top of the asy file the list of plugins you are using only if you use one or more features from the plugin, since we are not using any the plugin won't be saved in the list unless you add something specific from the ADriveline plugin. There is an enhancement request to circunvent this with PD, in the meantime you need to check the ADrivelie plugin is on.

 

Maybe other users have other ideas.

Alexis,

 

Well, I consider these couplers as a temporary solution, maybe I'll find another way of coupling multiple planetary sets. Now I'm focused on making the model operable at a fixed mode (gear number).

 

Yes, you're absolutely right about the 'ic_joint' trick, I just forgot it. Actually, when I had struggles with Machinery previously, I found out that, for example, the steering system template with Machinery-built rack-pinion gear includes IC_COUPLER for the parts of rack and pinion, aimed for initial condition analysis, so that helped me a bit to understand how to make Machinery Gears work in A/Car.

 

Thank you a lot for this remainder.

You have to keep in mind that A/Car has to "transfer" the initial wheel rotation to all rotating parts along the driveline.

This works fine as long as the parts are connected with constraints (i.e. JOINT, JPRIM, GCON, COUPLER).

 

Problems start when using a force coupling like a clutch. This needs to be iterated by the static solver.

Now imagine you have an engine with an elastic driveshaft.

The wheels rotate with vehicle speed, but the engine is not yet "synchronized". So at time = 0 you have a massive mismatch between rotation left and right of your shaft elasticity.

As the solver is kind of stupid it tries to "match" the forces to get an equillibrium that matches the error criteria.

In this case foe example a "preloaded" state with a huge torque in the elasticity would equal the "resistance" introduced throgh a high angular acceleration of the shaft.

Formally that'd be a possible solution so if the solver managed to find an equillibrium at all, there are huge gradients at the beginning when your vehicle speed is not zero.

 

Now for your next question: How to avoid that ?

Well, A/Engine had the same issue for example for engines on testrigs. Their solutiona was so called IC_JOINTS that were only active during static.

By this approach you could overlay the SFORCE for a clutch with a fixed joint that was locking the clutch rotation at static and thus the testrig roatation would be transferred to the engine.

Nowadays I prefer CGONS for doing this.

 

 

 

Alexis,

 

Despite the trick with IC_JPRIM works well with gear pairs, there is still an issue with a planet carrier which I've found out.

Imagine I made a vehicle drivetrain with a single planetary set, where the driver is the sun gear and the driven is the carrier (the ring gear is fixed). Initial velocities of the driver and the driven are known (from the engine and from wheels respectively). I added 4 inplane primitives for all gear pairs with the sun gear in order to find initial conditions for them. The full vehicle assembly with this drivetrain is simulated according to Maintain analysis. When is simulation has finished, it turns out that initial velocity of the carrier was 0, so the carrier somehow locked the remaining part of the drivetrain up to wheels.

I have tried to make different combinations of driver/driven/fixed gears, and the carrier always locks the driveline part it's connected to (IC velocity is 0, even when it isn't 0 actually). Also, I have tried some options of using inplane primitives for the carrier with some gears, but there wasn't any improvement as well.

Maybe I have some misunderstanding about the concept of finding initial conditions for the Machinery planetary set. Moreover, the carrier in your example is fixed, so probably you didn't get across this issue with your model.

 

Martin,

 

Thank you for your explanation, you made the issue clear for me. Yeah, I also try to use GCONs, when it's challenging to choose the proper joint. Not always, but it's helpful

Hi Viktor,

 

In my design above, the carrier was fixed to the casing and the output was the ring gear.

What happens if you do a maintain simulation at a reasonable speed, something like 30kmh and 3-4s? Does the vehicle eventually stops because the wheels are lock and stays there for the reminder of the simulation time?

If this is the case check that the ADriveline plugin is on, otherwise the CONSUB won't fire up and switch off the ic joints

Alexis,

 

Let me give you more detailed description of my model.

The full vehicle assembly has subsystems of detailed engine, gearbox and driveline. So, it looks like a mix of subcompact_detailed_engine and sedan_AWD assemblies from the acar_concept database. The _simple_gearbox template, where the output torque is calculated analytically (with state variable) is used in the model. The model works well in this configuration.

As I've got across with numerous issues regarding planetary gearbox, I decided to restart the gearbox template development from the scratch with adding elements to the _simple_gearbox template step-by-step. For now input and output shafts as well as one planetary set have been built. For the sake of checking how the planetary set operates and how initial conditions for it are found, the set is not involved in the driveline (it doesn't transmit torque), but its parts are fixed to the input and the output. For example, I decided to fix the sun gear to the input and the carrier to the output. The ring gear is left free, because two DOF of the planetary set out of 3 have been locked. So, now gears can just rotate according to crankshaft and driveshaft. Like in your example, inplane prmitives were added to all gear pairs (4 sun-planet pairs and 1 planet-ring pair), they all have "ic_joint" in their names. A/Driveline plugin is on for making simulations, so these primitives are correctly disabled when it's needed.

I have used a maintain simulation at a speed 20 km/h with 1 second and 1000 steps. This is enough to track down the transient process in the beginnig of the dynamic analysis.

So, for example, when I simulate the model without the planetary set, the results for the first steps are adequate:

But when I turn on the planetary set, the carrier, fixed to the output shaft, shows the absence of rotation at the point of t = 0 s (see the table below), so the whole driveline (from the output gearbox shaft to driving shafts of wheels) is locked (angular velocity is 0). In addition, initial conditions for the gears of the planetary set were found like if ring gear is almost fixed and planet gears are performing separately from the carrier. When the dynamic simulation begins, driveline shafts turn into rotation abruptly, which leads to hard impact on the driving axle suspension (rear in this case). For example, it's easy to see this impact in comparison between graphs of rear wheel normal force for these two simulations

Now I'm looking for a solution to ensure non-zero initial conditions for the carrier, but I haven't succeeded in it yet.