Hi, Andy Ross wrote,: > Maik Justus wrote: > >> I would be very thankful for any review of this version. And I like >> to ask Andy, to review if this version could go into cvs. >> > > This looks much, much better to me. Here's one spot that I'd like to > see changed, in Model.cpp: > > + if (_rotorgear) > + _rotorgear->calcForces(&_rotors,&_rotorparts,&_body); //it adds > several torques to the body. Therfore it needs the _body as > + //a parameter > > Yes, that's a 131 character line you wrote; I have a 1920x1200 screen > and it takes of 2/3 of my horizontal real estate to read. There are a > few other much-longer-than-80-column lines in there too. Oh, just use a smaller font ;-) (No, I will change this. Should not be to much work)
> But that's > the not actual complaint: > > The various calcForces() routines are idempotent by design. They > should *only* calculate forces, never change state. The solver and > various test code I've written actually relies on that property so it > can (for example) get forces for a Surface in isolation, etc... > > The proper mechanism here is to fill in two 3-vectors for force and a > torque which are added to the RigidBody object in the top-level > Model::calcForces(). If you want to use the two-argument version of > RigidBody::addForce() (for at a position), then you will need to > return a slightly more complicated data structure. > > Also (and this is really a question about you design than a > requirement to go into CVS) why do the pointers to _rotors and > _rotorparts need to be passed to a method on _rotorgear? Shouldn't > one of these objects contain the other ones? Yes, that is possible and that is exactly what I am working on. Short history why I am now using rotor objects and rotorpart objects (in the "old" version there were also rotorblade objects): My idea was, to implement two models: One, which uses only analytical results/ calculations and one, which uses numerical methods where possible. The second one was only to test the analytical first model. For the numerical model, each blade is simulated independently from the others. In contrary to the surfaces this model has some inner paramters, the position of the blade (two angles) and two angular rates. This model took place in rotorblade.cpp This model only works with a very high computation rate and do not fit the Runge Kutta integration due to the inner parameters. But this can be compensated by a even higher computation rate (this model was not designed, to be used in flightgear, it is only to check the analytical model). But due to complex air flow at rotors, it still needs some empirical corrections. But these correction, which I had to guess, had huge an influence to the results. (This is why this model is removed with this patch. Finally the model did not produce predicts for the analytical modell). The analytical model simulates the rotorblades at four different positions. Therefore I called the file rotorpart.cpp. In rotor.cpp is anything, what is needed for all blades/ parts (e.g. the rotation angle and the interface to the contorl input). The analytic model is quasi-static. The main results are static. Only a few dynamic corrections are added. (one, which could simulate the gyro-like stabilizer of the UH1, and one, which took into account the delay due to the fact, that the rotorblades move with finite speed. Both are so simple, that no complex integration is necessary. The rotorpart (and therfore the actual) simulation is idempotent and compatible to the YASim Runge Kutta integration. The model is not 100% analytical. For influence of the airflow it uses empirical results, mostly based on NACA publications. The interface to YASim is like the surface implementation. Every rotorblade has it's own contact point to the fuselage and therefore class Model has a vector _rotorparts. And (e. g. to handle the control input) it has also a vector _rotors. But in the actual version, I changed to add several forces/torques in one "calculate" function instead of returning each summand. Which this approach, it is not necessary to have the two vector _rotorparts and _rotors in class model. But this is still in progress. The results of the model will not be influenced by this change. Therefore I would like to put the code with the actual state to the cvs. > See PropEngine for an > example: it's a Thruster object that presents a unified interface, but > contains a Propeller and Engine so that they don't have to be visible > to most of the Model code. My aim is to add the Engines to the rotorgear class. Therefore I plan to derive it from the propeller class. > Maybe the real question is: what exactly > is the difference between a "rotor part" a "rotor" and a "rotor gear"? > Shouldn't there just be one object? What is the abstraction here? > > Andy > Maik ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
