Re: [Flightgear-devel] Aircraft frames and reference points
Jon Berndt wrote: Jon Berndt wrote: Model Reference Point (MRP): This is the reference point that is agreed upon by both the aircraft modeler and the 3D model builder. I'd vote for calling it the Visual Model Reference Point because the term model can still be used for the 3d model and he flight model. Erik True. Note this fact. If you have the CG point as the reference, then scale matters very little to the motions of flying. Only the point reference makes the models match reasonably well. You still need a distance measurement to know the scale and work out CG shifts, where the nose, wheel, and tail really are, etc though. Even the control forces off. But the motion point is not, for both rotation and translation. You aren't just using the nose point. No matter how much you trick yourselves into saying that you're only using the nose, and just 'fixing it', you are really providing a distance reference back to another point. It takes one point with full orientation, and another point to completely match two reference frames. There is no way to get around that fact. What you are really doing is having the nose point and a difference reference, and then working everything out from that bringing everything into alignment. That includes most importantly for visual motion to FDM motion match the CG. If you look across all your models of all scales, you will see that your adjustments all bring the CG point of the visual model to the CG point of the FDM. The CG to nose distance will be different, but that's in the offset combined with whatever the FDM does with the offset to find the CG point. Take all of the models. Put all of the nose points at exactly the same spot. put the FDM nose point there. Note that you have a range of CG's based on how large the plane drawing is. And your 'nose fix adjustment' is the distance to some other point. Then your FDM works out the CG point of each size model from that other known adjustment and your CG is in the right place in both models. We already put all the nose points into one spot. If your alignment system only needs the nose point to match in the FDM and the visual model, then set the FDM nose to a known point, put all the visual nose points there, and your models will all work no matter what size. This doesn't work, even though all of your nose points are now correctly known. It doesn't work because you need a nose point known, plus another number to some other reference point. This other reference gives you scale, and then put all other points in their place. Most importantly to visual motion, it lets you put your CG where it goes on the visual model. That was my original point, it is impossible to have just the nose point on the visual model and not have anything else and have everything match regardless of scaling between the FDM and the visual. You have to have some other reference fix, that lets your FDM bring it's CG into alignment of where it should be on the visual model. That you are hiding it from the model creator so they don't have to find the CG of the visual model is a great idea. That you are hiding it from yourselves though by saying you're 'fixing the nose point' isn't as good. You're sliding everything around with this adjustment, not just the nose point. And while it brings everything into line, the single most important thing to how the model moves is getting the CG correct. You don't have some arbitrary fixed point on the nose of both models that makes everything line up. You have a fixed point on the visual model only. You then move it around on your FDM model with your adjustment, until the CG is where is should be for the visual model so the motion looks correct. If you double the scale of the picture, you have to adjust your nose to CG distance through your adjustment, even if that uses some other common reference point to get the CG in the FDM. Your adjustment is fixing where the nose should be, relative to some other point, so that that other point is where it should be, so that the CG is now also calculated in the right position in the visual model. You don't have a 'nose point does everything' system. That adjustment isn't some minor little tweak to your system. That 'adjustment' carries every bit as much weight in aligning the system as the nose point. Using the nose point first lets the model creator make the model without reference to scale, which is great. But it just means that someone on the FDM side is fixing the scale later through the adjustment, not that the nose point is the only thing and nothing else matters. That adjustment is just as critical to the alignment of the systems as the initial point. It takes both, the nose point isn't 'it' like some of you have tried to imply. There was something else to your system, which there had to be to bring the FDM and the visual model frames into full alignment. No single
Re: [Flightgear-devel] Aircraft frames and reference points
Jon Berndt wrote: We're not tricking ourselves into anything. Like we have mentioned numerous times before: We are providing the 3D model with a location in space where a known point should be co-located with. We still do (and always have) provide phi, theta, and psi, which are the same regardless of the point of reference. We know at all times the aircraft body-frame vector from the CG to the VRP (visual reference point). We know the body-to-local frame conversion matrix at any time. Thus, we know the real world location where the 3D model VRP should be placed so that the motion calculated by the FDM is properly reflected in the motion of the 3D model. Jon If you know everything about both frames all the time, then why is there ever a need for any adjustment figure? Everything was calculated, all needed reference points were known already from the VRM to the FDM, you didn't adjust anything there was no need. Some of these factors weren't known at first if people can draw planes of any relative size in the drawing program. You are figuring out the size relationship somehow, it is not set if they can just draw the model any size. If one person can draw it twice as large as another, and you can match the FDM to it, then you are matching more than just the nose point somehow. You are making your scale bigger somehow, or shrinking their drawing, if you can match the bigger model. If not then you have to move your nose around to match, then change every motion constant in the FDM to make a large drawn model act large, and a small model act small. And even then the modeler has to draw it the right size, they have to make the model 30 feet if it needs to be 30 feet. I know you're doing it correctly. The models, once adjusted, look and act properly. It is your explanation of how the two reference frames fully match is what's lacking. You say no no we only adjust the nose, when really you are doing other things too to match the visual and FDM frames with your adjustment figure, even if you don't see it. You are making every point match in scale in both frames, not just the nose. Your adjustment figure is from the nose in one frame to a reference in the other. Your scale is either known set or adjusted along with this adjustment through other factors. And when you get a new model, and move it around with your nose adjustment figure, and aligning your reference point, you are aligning your CG's even if you don't say you're aligning your CG's. Yes, they fall into alignment when you get your reference points matched and your nose was in the right place. But how is it you know when your reference point looks like it matches? By the CG. You may look at only your reference point. But when you move the plane, and you're saying 'hey it looks like we got the nose and reference point right', how do you tell? You judge it's motion relative the motion of the CG. You are matching the CG of the FDM to look in the right spot. Even if you say 'No, we are only looking at this other spot swinging around the way it should', you are really looking at it swinging around another point, the CG, when you check it visually. Like it or not that is how you are almost guaranteed to be aligning the visual model. There is very little else to accurately gague in a visual model in motion than 'is the model rotating correctly around the CG?' When you're aligning the visual with your number you're aligning the CG point, even if you do it through reference to some other reference point. Regardless, there is a 3 or 4 sentence explanation of exactly how every point in your FDM frame, and the entire visual model frame, match. This includes matching any model of any size. It can be said easily, without saying We only align the nose, you're not getting it. You are leaving something out of your objective explanation of how they match. You put it all in no doubt with the relative points match since it works in the program. But there is a simple overall description of how it matches that is much more accurate than 'we just align the nose'. No wonder you've discussed it to the point of being blue in the face if you haven't got the simple full reference match description to rattle off. Don't worry about writing more trying to explain. If you guys aren't seeing the simple objective explanation I was originally asking for, you could write all day and never say it. I will look at the FDM adjustments and adjust several models. And put a different model of a different size on one and change the numbers until it works and see how the visual to FDM scaling is done. I will then come back and give you a 3 or 4 sentence explanation of how all points in the visual model match up and are adjusted for size and position to the FDM. Maybe a picture or two if it's needed for clarity. I am not the one not getting it. There is a simple relationship between the
Re: [Flightgear-devel] 3D aircraft model origins
Jim Wilson wrote: That is mostly correct. There is also a visual effect that occurs when you render a 3D scene with the camera tracking an object. The point you are tracking always appears stationary. Examples of this in FlightGear are the helicopter view and the tower view. If the origin is the nose of the aircraft then the camera moves up and down with the nose. In the air or from a distance this makes it look like the airplane is wagging like a dog's tail from the nose, when it really is not. Take a look at the p51d as an example of an aircraft with 0,0,0 at the nose. In the file p51d-yasim-set.xml there are several target offset settings (one for each view) that represent the distance from the nose to a very approximate center of gravity. If you want to see the effect, then take those target offsets out. As you will see, this is a design weakness (my fault). The model configuration will always need to be updated whenever more views are configured. Note that this is a problem with the camera (the viewer code), and not the model. It only needs to be defined per model because of the different sizes aircraft come in. This does seem to have been an odd choice in how things are arranged. Take a basketball for a simple example. CG in the middle. Now hang it by a point on the sphere. Hang point is above, CG has a lever arm against it and makes it hang down. Now spin the basketball and balance it on a finger. The point of suspension is then below the CG, and gyroscopic effects keep things stable with the CG above the POS. Note that CG is not the reference point for what is holding the ball up. A plane 'hangs' on the wing. CG and control moment arms and everything else work around the point that it's hanging from in the air. CG is usually slightly forward, and a small down force on the tail. This makes a line from the CG to the tail through the POS that helps keep the plane more stablilized on the POS, like the fulcrum of a seesaw with some weight on each side. POS is the point all the calculations work around. It's also the point that the whole plane moves around when viewing. The 'nose' is a bad choice for either the viewing center or the FDM center. Everything works around the POS. The nose is just an arbitrary point how ever many feet ahead. That means there will be unneeded translations in all calculations since it's using a point that is not the actual 'center'. A point 27 miles to the right and 33 miles ahead of the POS could also be used, and the FDM calculate from that and the viewing model also translate it's view from that. The computer can do the calculations, it's just a pretty useless thing to do when both models actually center around the POS. Who cares about the point 5 or 10 feet ahead at the nose, any more than the point that's 27 miles right and 33 miles ahead? Until this thread it never would have occurred to me that another point was chosen as the basis for calculations or viewing. It can be done, but it adds extra calculations. POS end up being COL for a plane. It suspends itself by the aerodynamic forces it generates. But POS is a better general term for working out how things hang, it works on anything. Take a person. Your POS is through your hips. And your CG is roughly in your waist. We're slightly unbalanced, that's why we have to have feet and active correction to stand up. A planes nose pitches all over the place when flying level at different angles of attack. The forward vector of a plane in straight and level flight extends out from the POS regardless of angle of attack. While the POS of the plane changes slightly as the CG and and aerodynamic forces shift with attitude changes, it's mainly near COL of the wing. The nose and engine just pull the wing forward. The tail just gives leveraged control. The wing does almost all of the flying by itself in most planes, it takes some consideration and work to get any other part of the plane to help contribute to the flying of the plane and thus shift the POS a bit. I can sort of see the choice if this started from RC, since some people fly by the nose. But the best place of reference to fly a plane in 3D from outside is really the center of the wing, just where you'd expect from all the forces actually working around that point. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Andy Ross wrote: Alan King wrote: The 'nose' is a bad choice for either the viewing center or the FDM center. Except for the obvious fact that it's 100% unambiguous. It's not uncommon for the FDM definition and 3D model to be done by different authors. Take 21 people and ask them to identify the POS (or quarter chord point, or aerodynamic center, or even c.g.) and you'll get 21 different answers. Any child over six can find the tip of the nose on a photograph. If the visual model doesn't have EXACTLY the same distance from the nose to the POS as the FDM, then they are out of line, period. No common point of reference is going to make there be any LESS error if it's distance from the POS is not JUST as exact in visual and FDM models. And if you do have error from one model to the other, using the nose will actually exaggerate the error, the longer lever arm from center for the error will actually exaggerate things. It may be a bit easier see the nose visually but the internal models both best work from the POS. There isn't a CHOICE on whether it takes more calculations or not, it takes more to get out to that point of reference and back. Any amount of ambiguity between models is EXACTLY the same but worse from extra translating when using the nose. If we both didn't use EXACTLY 6 feet back from the nose as our centers, then there is just as much error as if we both didn't use the same EXACTLY 0 as the center. You can't have your visual distance 5 feet, your FDM distance 6 feet, and have the models match correctly. The nose is just an arbitrary reference point, that child over six won't be any more likely to match the things that really need matching from referencing the nose than by finding the center directly. Couldn't matter less if you found the nose correctly if you didn't find it's offset from the POS correctly. Physics doesn't worry much about what point is easy for you to match up when it's keeping a plane in the air. A plane flies from this central point both visually AND aerodynamically. And so should the models. If any other point is used then there is extra translating required or the models have errors. And it's easy to introduce other errors in all the extra translating. The centers need to match for no error. Using the nose REQUIRES that you have the visual distance from center exactly matched to what the flight model is calculating for distance to center. If it's not then you have a geometry error in the point about which your visual rotates on the axes. No way around it. Using the nose as a point of reference does not magically relieve you of the obligation of knowing exactly where the POS is to match them. You still have error if you don't. And it has worse effects since the error is geared by the distance from the origin. I was simply stating the fact that the best point of calculations for BOTH visual and FDM models is the POS. This has nothing to do at all with what is easier to line up. That point is the simplest for all calculations. Working from any other point for calculations adds translational offsets to the calculations, there isn't any way around it. If you line up by the nose point, then you have to make quite sure that the distance from the nose point to the POS for both models is exactly the same. You can fly an RC plane by looking at the nose for reference. But you can also bet that those who do can't fly 3D nearly as well as those who fly by looking into the center of the wing. That isn't my opinon, it's me relating my observation of the fact that it's much easier to fly a plane from the center point. It is the better reference point because it doesn't have all the translational offsets introduced by looking at the nose. When flying any plane at high angle of attack, the nose is a terrible place of reference compared to the POS. The wing moves straight forward in level flight at any angle of attack without changing height. The nose moves all over the map, changing its distance from and angle to the line of motion like mad. It's offset from the real center makes it a poor choice for calculations. It is FINE to use the nose to match for a point of reference, IF both then reference it to the POS correctly. Then just do the translation once and use POS for both models calculations. BUT, there is no 'extra' better matching from using the nose if it isn't matched to the POS. Take one of your models referenced by the nose. Now multiply it's visual size by 10, leave the FDM alone. It'll look silly flying. Now have the common reference be the POS. Any visual size scaling looks great without any adjustment to the FDM. It is the much better reference point to work from for matching the visual and FDM models. It is where they both agree with the least calculations and problems from any errors. Matching your nose just SHIFTS your error over if you don't have your visual
Re: [Flightgear-devel] 3D aircraft model origins
Lee Elliott wrote: Definitely - I don't think I could accurately position a model to an aerodynamic center. LeeE Then your model's relationship to how it flies is just as inaccurate. It isn't by your or my or anyone else's vote or choice. If the NOSE agrees in both, and you haven't gotten the distance from NOSE to POS correct and exactly the same in both models, then you have a GEOMETRY error between them when it moves. Try to show me how having the nose referenced relieves you of having to know and have the same distance from nose to center in both FDM and the visual. You can't. How would you expect the FDM model to magically get it's relationship from it's nose to where all the calculations are done matched to your model's visual distance from it's nose to where all the calculations should be? You can use the nose all you like. If your distance from your nose to the center isn't exactly the same as what the FDM thinks it is, then your models don't match and your visual is off by just as much as that inaccuracy you couldn't figure for the POS. There is no choice in the matter. The center of the aircraft is the center of the aircraft and is the simplest point of agreement between the visual and the FDM, and simplest point of calculations for both. You can use the nose as a reference point, but you still better make very sure your nose is the same distance visually from POS as it is calculated in the FDM if you want them to match. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: You are in an A-10 with a maverick on one side. You have an aircraft CG (which the FDM is reporting the position of) and an MRP, which the FDM is also supplying to FlightGear. The MRP is given to FlightGear in lat/lon/alt. The FDM calculates that position because it knows where the CG is absolutely, as well as where the MRP is relatively. Since the 3D model builder and the flight modeler for the aircraft agree on the MRP (we hope!) the aircraft can be placed properly in the scene. Now, say we are stationary on the runway and we drop the missile. The CG shifts instantaneously - however the FDM will not report a different position because no force has caused an acceleration which in turn could not have been integrated to produce ultimately a change in position. This is a flaw that may need to be addressed. In any case, let's assume that the FDM *did* shift the reported lat/lon/alt of the CG as reported to FlightGear by the equal and opposite amount that dropping the Maverick resulted in. The vector to the MRP would be shifted by an equal and opposite amount, and the end result would be that the model would not jump and the FDM and the model would agree. In the case of smooth flight where fuel burns off slowly, it's not so critical. It is hard to tell from what's said whether you're using the COL as the reference or the CG. COL is the real reference to use in the FDM, the CG is purposefully forward on most craft for stability. The CG swings around the COL pivot point noticably when you change pitch. Also all moment arms are from COL and you actually load the plane to put the CG where you want it, the COL is the real reference point. If you're not already using this, try a very high wing low CG plane. Pivot it around the CG. Then pivot it around the wing's COL. Which looks even close to the real pivot point? To model a bomb drop correctly you simply use the COL as the suspension point, and calculate all forces off of it on each pass, including the moment arms. With the Maverick gone and no longer having it's moment arm in the equation for CG the next calculation pass the CG will shift automatically, and the new distance between the CG and the COL will take care of any resulting motions on it's own and move the plane till things are back to balance. It would be built into the calculation pass, and move on it's own. Really you can just calculate total CG once or rarely and just move the CG when the bomb drops by subtracting it's moment arm. But the COL should be the motion and suspension point of the craft not the CG. The change in the CG relative to the COL should automatically introduce the forces to change the overall orientation around the COL. The COL can shift too as orientation changes but it's the point to calculate from, no one said an accurate model was easy. Just accurate. You can use any point as a point of reference as long as you make sure all translations are in all the calculations. You can start from the CG, and then calculate the COL is over here, and use that to move the craft. But the craft should swing around the COL either way, so you have to do extra translations to make the CG reference point move. COL and CG can both move, but COL is the real hang point of the aircraft so using it simplifies calculations for a truly accurate model. That's why weight and balance calculations are relative to it instead of where the starting CG was. The starting CG is used in the calculations, along with it's moment arm from COL. There are less translation adjustments if you reference everything from that point. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: structural frame. The 3D modeler has no clue about (and probably doesn't care to know about) where the CG is - and that's fine. The FDM and the 3D model, though, *do* need to agree on a common MRP (Model Reference Point) that the FDM can supply to the FlightGear scene code for proper placement of an aircraft. Once that point is agreed upon, it's not a big problem at all for the FDM to send to FlightGear the exact location in world space of the MRP. No matter what the orientation of the aircraft, the 3D model will always have its CG in the correct place if the FDM properly reports to FlightGear the real-world location of the MRP. We (FDM) can do this because, as I've said before, we know where the CG is, and we know where the MRP is in reference to the CG. I see what you're doing now. You are letting them just use the nose, and then shifting the FDM nose point until the FDM center is near the visual center. The nose reference point in the visual model isn't referenced and matched to the FDM. It is simply a given point, and then the FDM can be adjusted to it until it's COL matches the visual's approximate COL. That works easily but is different than the model's nose point being matched to the FDM. The 'Model Reference Point' terminology is what is actually ambiguous, it is really just a visual reference point that the FDM is adjusted for after the fact. Handy dandy way to match the visual to the FDM really, but I would have shied away from calling it 'Model Reference Point' without it being the best inertial reference point of the model. It can be considered the reference point of the visual model frame, but since it's going to be translated through by the FDM the actual visual point of motion center will be the same as in the FDM. It's an unusual naming for just the point of visual adjustment. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jim Wilson wrote: Maybe this will help: Unless you crash the plane, or you are flying a concored sst, the nose will _always_ have exactly the same relationship in 3D space to the furthest aft point of it's tail. The x, y, z distances between the two points will always always be the same no matter what orientation the aircraft takes. This applies to any two fixed points on the aircraft. Yes but any change in visual scale requires an adjustment in the FDM reference. It's not the overall reference point of the model or general calculations, it's just a known reference point and the FDM is adjusted through it until the real reference point of the FDM model is about where it should be on the visual model. The name Model Reference Point just had bigger implications than what this point is actually used for. More of 'a reference point between the visual and FDM models' than 'the model reference point' for the actual modeling of the airplane. It doesn't make the alignment happen magically by using it, it just lets someone else do the adjustment on the FDM side later. Still a good thing. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Tony Peden wrote: Once the wheels are off the ground, the center of gravity is the point about which the aircraft rotates. It does not rotate around the aero center or any other point. Yes, been a while since I'd used the POS. It is the other way around, with a fixed POS it's the best point to use. With no outside force fixing the point of suspension it will shift around the CG and the CG is the best to use as reference. Also, the c.g. does *not* change with pitch attitude. It's location is purely a function of the weight distribution within the vehicle. Wasn't saying it would actually change, only that it would translate. But it doesn't it's the other way around the CG is the reference point and the suspending point moves around when it's free to move. The motion's all the same relatively as always, but it's when the POS is fixed that it is the better point of reference to work from not when it's free to move. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D aircraft model origins
Jon Berndt wrote: I see what you're doing now. You are letting them just use the nose, and then shifting the FDM nose point until the FDM center is near the visual center. Not really. The FDM still calculates the position of the CG of the aircraft. It's just that we know exactly where the agreed-upon MRP is at all moments of time, so we calculate that and give it to FlightGear. We could just as easily agree that the wingtip was the common known point, calculate that, and have FlightGear place the 3D model in the view so that the wingtip was at the specified point. The only thing the FDM does as an auxiliary calculation to aid the 3D model placement is to additionally calculate the MRP position in world space and make that available to FlightGear. Or, at least, we will when I code it. Jon Ok that gets back to the same question then. What else besides the nose point does FlightGear use to place the visual model? Say your CG is at the origin. Your nose is 10 feet forward. FG puts the visual model's nose at the 10 foot position since that is the common reference point. What makes sure that where the CG is on the visual model is at 0? You do a 20 foot long plane FDM, with CG at 10 feet. I draw a 3000 foot long plane. The noses match. Does about 2980 feet of my plane sink into the ground? What makes sure that the CG is put at the right place in the visual model with the nose as the only reference? Does FG just scale the total model, the FDM also gave a length for the model, and FG assumes the visual model has the wing in the right place? Maybe FG uses your CG, matches the nose, then just guesses the CG of the visual model of the overall size? There just has to be some other piece of data that correlates. If not there is no telling if the real FDM CG is where it's supposed to be on the visual model. An off center reference point like the nose isn't enough if you have no other data to calculate back and match the center. If they're actually accurate together, there is something else matching. And if there isn't anything else matching in some accurate way, then there is no telling if the FDM CG and where it should be on the visual model are really matching. What else is FG doing to put them in the same place? Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
John Wojnaroski wrote: Define 'level', if the wings are level, REALLY level, the rudder will produce a torgue to turn the nose until the counter-acting moment produced by beta is equal and there she'll stay, in a skid, but no turning. In fact, as Dave noted, you have to cross control with the ailerons to keep the aircraft from banking and turning if you step on a rudder. The Wright Brothers got it right from teh get-go; else why bother with wing-warping if rudders would do the job? Try turning a plane that can fly knife edge level flight about 90 degrees and see if you don't get an approximately 1 G flat turn from rudder with the wings level. That you don't get much from most planes is just designed in control setups towards coordinated turns and low adverse yaw instead of good flat turns that are much less useful for GA. No physics rule there though other than how they're designed. Even then you can probably do it at least a little, the turn rate would just be low. For the Wrights it might have a little to do with having designed the wing-warping long before the rudder control was put in. They only thought of controlling the rudder after they slipped to the side from no control. A bird doesn't have rudders so hard to think of a rudder only turn when designing the plane, it was the last thing done. John Wojnaroski wrote: Very true, something like a Harrier will turn by virtue of thrust vectoring in hover and helicopters are a whole different breed. (In fact, watch a helicopter when it is in forward motion. It banks to make a turn) If a fixed wing aircraft can turn with rudder while maintaining wings level (i.e; phi = 0.0) then it should be possible to derive and demonstrate that from the kinematics and general EOMs. Try it and watch what happens to all the sin(phi) terms when the bank angle is zero and the forces and accelerations produced. True you can yaw the nose with rudder, but that is not the same as turning or generating a psi-dot in the inertial frame. To turn the aircraft in the inertial frame you need to produce a psi-dot. Uh guys, can you do a forward slip? As in bank one way, for turning rate one way, and rudder the other way for turning rate the other way, to go straight? Level the wings, and see if you don't get a noticable turn to the rudder side now that you've stopped the countering bank turn part the other way. Or just start a coordinated right turn. Now give a bit of left aileron to level the wings. Hmm more lift and drag needed on the right wing to raise it that's also helping it go even slower and need more lift and drag. You don't get one drop of left bank to counter the turn since you're just level, and you end up with a butt load of right adverse yaw to get an even better right turn. That is assuming you're in a real airplane and not some GA junk that has almost all the adverse yaw tuned out of it. Even then you can get an ok turn rate out of full right rudder and balancing left aileron on the 172 in FG. Actually as slow as a banked turn seems in the 172 I was a bit surprised the flat one turned around as quick as it did knowing it has most adverse yaw tuned out. Still would take a while to do a 360. It is just enough you can even do a slight left bank while still clearly turning right. I'll have to try a better plane but you don't really need the Harrier. And BTW a heli hangs from a rotor disc that forms a suspension plane (geometry plane that is). It has little if any fuse being yawed into the relative wind or nose thrust vector as you get in a normal plane. The rotor disc is a frisbee, and that is what does the flying. The tail rotor only points the nose and body, and the body alignment is really only a reference for orientation to fly the frisbee. I can put in tail rotor so the body rotates constantly, and still fly the frisbee around and do loops and rolls. You just rotate your right stick at the same rate as the spinning. More away from the center is forward, back through the center is back, advance a bit faster than the spin rate is one way left or right and retard a bit over the spin rate is the other way. Easy as pie. Does help to keep moving, if you bring it to hover and have the cyclic centered it can be hard to start back out in a controlled direction while still spinning. Might want to try some other things than just FG! :) And GA aircraft are simply not the thing to look to for what's possible or not for a plane. Pretty hard to think a plane can't do flat turns when you can hold an RC plane's wings level and zip it around at a significant rate in one. Even if it takes me a bit to recall the exact details for how and why it works and why normal aircraft stink at it, it was never in doubt in my head. At least download FMS and try some sim flying from outside the box, some good backgrounds from FMS for RC. Actually heck now that I think of it FMS stinks on rudder, they do not have the
Re: [Flightgear-devel] Oh dear....
David Megginson wrote: JD Fenech wrote: This is pretty sad. It's times like this when I start to consider relocating to Canadia to find a job and live there, much as I bash on it (jokingly, of course; it really wouldn't do to be bashing our 51st state). Here's a local (New England) version of the same story, with details: http://www.recorder.com/Headlines/tuesday_basic.htm Note that the Staples clerk actually told the servicewoman and her son that instructional flying software was illegal, before he reported them to the police. And from that article: But what saves us, is people are paying attention, she said. Might help if the people 'paying attention' weren't complete idiots! :) She gave that clerk far too much credit. And exactly where was the store manager I wonder? Seems like someone at least should be charged with criminally negligent stupidity. No doubt if they had it at Staples you could go in, give the same clerk a good excuse for how your smoke detector stopped working and needs a new radioactive source, walk out with a few million pounds of plutonium and a clerk thrilled with his commission, and then proceed to blow up the entire world. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Autocoordination
Alan King wrote: John Wojnaroski wrote: Define 'level', if the wings are level, REALLY level, the rudder will Also load up the J3 Cub, it gives a really good clip with full right rudder and no bank. And pretty high left bank to even stop the right turn. Nothing different over what I described before, just more noticable. Plus it's fun to view from behind and see the 'square' propeller. Might have to hunt one up to try out, found out this Christmas talking with my uncle that my grandfather had 350 hours his first year of flying in a J3. Sort of explains building the runway.. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Repeatable VASI light observations
Curtis L. Olson wrote: This is high on my todo list, but it will involve a substantial amount of effort to do correctly. There is no trivial fix to be had here. Actually there's little need for a real, perfect system. I thought about making my own crude VASI, a row of red then a row of white. A simple 3D shape like a piece of plywood coming out as a blind at 3 deg to seperate them. Then another, with the base at the same line between the lights, but the upper end 4 inches or so lower than the other blind. The 4 inches or so should block one set of lights as you see the other.. Other thought was 'glideslope'. Glideslope works. No reason not to put a glideslope at the end of the runway, and an instrument at the pilots head that changes the lights by what the pilot eye needle says. Could all use the same unused freq like 000.0, won't matter if the lights on the other end of the runway change too. Everything angular could use the same code. While VHF UHF and light are very different systems in the real world, they're all doing the same basic function in a sim and could easily be set up to use the same code. Sounds like you're already there though in a later post.. And my wife thinks she should be seeing progress on our basement remodeling project. Sounds like it's time for some retraining. Or maybe just bleach to cut down on the thinking part. :) Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
Martin Spott wrote: I'm not shure if the current configurable serial interface is capable to do bit-mangling and I'm quite confident that it lacks support for checksumming. But this may come in the future, Thanks actually that looks pretty good, and is really close to the register then data format that I normally use on my microcontroller comms. Only with a channel number and parity, really could just have a block number and send 4 or 8 channels at once then parity. With just parity it may get the occasional false positive to start, but once some controls are moved and it falls through to the correct spot it should stay locked on since always getting right parity. Not much need for NEMA for a direct controller so 8 bit values shouldn't be a problem either. With blocks of channels it would also be easy to prioritize the refresh rate, send the first block most of the time for the main controls and only send the buttons and switches a few times a second. Should work fairly well. I may have to even look at the PC side myself shortly. I've got the hardware mostly done, but am leaning away from having the yoke use the system mouse. Still want to use an optical mouse for yoke control pickup, just want it on a seperate controller so it doesn't interfere with the system mouse and normal button pushing and view selection. Then edit the system mouse so it never goes into the control mode and things should be pretty nice. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rudder pedals
http://home.nc.rr.com/alan69/FlightGear/Rudder3/ Nearing completion on the basic prototype, last pic shows the construction best. Angle was a bit steep for a desk chair, so added screws to set the angle. Will change the cuts instead later. There are eight 1' sections, may just use a single 2 x 6 x 8' instead of project boards. That will cut the cost by $6 or $8. Rails for $12 and board for $4, and only a few other odds and ends and a little cutting and drilling will be all that's required for the mechanics. Feel very good even without considering the low cost, and will be rearranged so wood is about the only thing showing and can be finished off if desired. Just a bit left to do and then get the electronics working. Then get the yoke finished too. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Serial device
Anyone up for making a serial device? I only do a little programming on the PC side of things, so am not currently up to the task I think. Needs sync bytes, something like this is common: FF FF 0 axis1 0 axis2 0 axis3 etc. Really just check the high bit, 2 set in a row is the sync, then a zero then axis etc. By just checking the high bit other things can be put in like this: F0 Fx 0y ax1 0y ax2 etc. Where the x can tell how many axes are coming, and button bits can be put in the 0 high bit bytes for y. It's not that this can't be gotten in the computer some other way, but development is a bit easier with a plain serial port, and everyone's got one plus they work in WinXP. Mainly looking for my rudder controller, but if someone does this I'll also put up a simple pic interface and code for RC transmitters. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
Andy Ross wrote: RS232 is an async protocol, there's no need for any synchronization in the application (that's what the start bit is for). Just send the data you want and it will come out the other side. If you saw an It's for byte sync not bit sync. application doing this in the past, it's probably one that was trying to do autobaud detection, which is a rats nest you don't need to worry about for custom hardware. Or maybe it was transmitting to broken hardware that wasn't fast enough to handle real RS232. You might want to put a magic number at the top of a packet to handle dropped bytes gracefully, but that's a slightly different problem. You certainly don't want to embed padding bytes in the message itself. Has nothing to do with dropped bytes, has to do with figuring where the start is in a repeating variable length data stream. If I send you a few thousand FF's how do you propose to tell which ones are starts and how many channels? Did it start at the beginning or was it already running when hooked up? You have to have repeating patterns and then change the patterns for sync if you have full value data, or have output data to start and synchronize the packets, which is more trouble over just reading a sync. Just a magic number at the top can easily fail with full range data. You don't have to have repeating spacers but a nice simple easily understood format is always a good idea, and it's only the high bit anyway, the lower bits can still be used. I do microcontroller code, so I could easily change it to be as terse as possible and still easily synced to, but the bandwidth is so low for a controller vs what else is going on in a 3D PC it's hardly worth worrying about. Overall it's no different than sending IR data streams, you require a reliable sync signal to get started if you want to know where you are. Yep you can autobaud to it if done correctly, but you still need it for general sync unless you limit your data value range in some way. And it was really just a simple generic example anyway. No doubt if someone is up for it we will discuss it a bit and take it down to a minimum but expandable data format. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial device
Manuel Bessler wrote: you mean for the microcontroller side ? Hmm that could have been read the other way from what I meant. Nope I do PICs that side is trivial for me. Just figured someone already working inside FG could add a serial driver and serial.XML far faster than I could. I have worked on a protocol for my own stuff... it includes analog axis and button state support. I've put up a picture of my protocol spec: http://cockpit.varxec.de/fgfs/PHCC2HostProtocol.xfig.png Can't get there through the link. At any rate I am working more towards a simple reindexing scheme and any data after that than a single specific protocol. With flexible configuration with a serial.xml type file I'd expect to define how many channels and the data types and formats on the fly anyway. Have a few other applications and some other hardware in mind in the longer run besides just FG, so want it to be truly open. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Cockpit Hardware Building
Rudder pedals. Been a while since I was at the controls in a Cessna etc, how much control throw is normal? With a one foot seperation between the pedals 4 seems like a lot, maybe too much. Currently have 2 in and 2 out for the 4 total, but can easily shorten it up, feels like I'd have a foot in the engine. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
David Megginson wrote: Matthew Law wrote: That sounds about right for a 152. Maybe David can tell you how much throw is available on his aircraft? This is going to sound stupid, but I'm not sure. I think of the rudder pedals in terms of pressure rather than movement -- to get that in a simulator cockpit, you'll need a servo motor attached. Just a spring return to give some general feedback is all I'm planning for now. Main use on a simulator is simply to seperate the controls to the correct actions, don't see much point in going beyond that short of doing a full cockpit simulation of a particular type, which is beyond what I'm planning for the moment. I do motor controllers so it really wouldn't be much for me to do it, just don't see a whole lot of extra value beyond a spring for a basic control setup. Thanks guys for the info though, figured it was around +-2, just seems really far in doing it. But I've also kept the width a bit narrow at a little under a foot on the rails to save space, may be a bit closer than usual and make the throw seem longer. Still rather have close to right distance even then. Also I'm assuming the yoke on most planes has a bit more throw than +-2, but that's about the limit of what's practical with my current hardware so it'll probably do ok. I could get 6 travel or so max, just gets a bit more trouble to do. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
David Megginson wrote: Alan King wrote: It depends on what you're doing. Control feedback is pretty critical for basic stick-and-rudder flying (that's one of the reasons that flying a plane in FlightGear is so much harder than in real life). For pure recreation, or for instrument training, it's not so critical. Yes it is. But the control feedback in the simulator EXACTLY matching real life is not critical. For that matter a Cessna rudder probably doesn't exactly match a P-51 rudder either, but I have no doubts that learning rudder on said Cessna prepares you for 80 or 90 percent of how to use a P-51 rudder. Exact matches aren't critical, simply having some feedback and learning that you must pay attention to the feedback and develop a feel for what is right for a particular plane is most of it. With the sim plane being a bit different from the real plane, you're simply learning two different planes. It's still quite useful to have the basic feedback even if it's not exact. And I'm not aware of any even $10 mil simulators that are more than approximately real, even with a driven motor proper G forces have a noticable effect on your legs, yet are incompletely modeled. There's only so much you can effectively do without getting in a real plane, I'm just going for the basic 80 percent of it and leaving the other 5 or 10 percent that could possibly be done on the ground alone. It should still be quite effective for the cost. Later, Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
Matthew Law wrote: On 14:52 Thu 18 Dec , Alan King wrote: Also I'm assuming the yoke on most planes has a bit more throw than +-2, but that's about the limit of what's practical with my current hardware so it'll probably do ok. I could get 6 travel or so max, just gets a bit more trouble to do. It's 16-18cm from full down to full up elevator on the couple of C152's I've measured and roughly +-90 degrees of roll axis. The 6 won't really be that hard to get, since that's closer may as well get it. I can do continuous roll axis with little trouble so the +-90 is easy enough. Actually takes a few extra parts to put in the stops. Rudder is the one that needs some serious stops though with your legs working against it. Feels good so far just have to link the pedals together now. BTW, I'm not anal. Honest! I'm just building a yoke of my own so I measured these recently. If you're in the right ball park for these figures IMHO you'll be just fine. As David quite rightly said, it's the feedback from the controls which varies according to many parameters that is by far the hardest thing to simulate. I'm going to use elastic cotton-covered 'bungee' cord to centre and resist on my yoke. Mainly because springs are quite difficult to come by and can be noisy to boot. Well the springs are plentiful enough at the local Ace, but do make a bit of noise. Won't matter much down at your feet on the rudder, but bungee may be the better choice, may need a pulley etc to shorten it up and keep it in my form factor for the yoke. I've got a thousand or two motors on hand of different types, so I could do some force. But my primary goal is to get control seperation and a general idea of feel, beyond a certain point it's simply more effective to stop simulating and hop in a plane to get the real feel. Plus it'll be better to keep it reasonably simple to build so most can get it done since I'm looking to put up plans. Later, Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Cockpit Hardware Building
Curtis L. Olson wrote: Alan King writes: The FAA defines tolerances that a sim builder needs to meet in order to be certified. Control forces are something they definitely pay attention to. Rudder force for some manuever might need to be within 5 lbs of the real thing for instance. But if it takes 4 lbs of force in the real airplane, that leaves you a bit of latitude. Well I wasn't really going for certification on my $30 homebuilt rudder and $30 yoke, although if there are specs and since I do motor controllers it might be worth looking at at a later date. But 5 lbs on the rudder when your leg weighs 30 lbs isn't nearly the same feeling as that same 5 lbs on the rudder when your leg weighs -30 lbs, and I'm not aware of too many sims that go inverted to do negative G's, though there are no doubt a few for military at least. But they're still useful even without doing everything perfectly. And a simple spring will still be useful, even if it has a few more trade offs and is less accurate a simulation than a motor system for more correct force, it's still much better than nothing, and has a significant chunk of the usefulness of a more complex system without the extra cost.. Time to go do the linkage, even without the pedals already feel pretty good. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-users] Slackware, USB, CH yoke
Andy Ross wrote: I've never looked at the kernel source. Presumably this would be a trivial fix, no? As always, write it and see.. :) A keyboard can be interrogated. A mouse outputs constant data and/or can be interrogated. A standard joystick does.. nothing. It can look like it's there when it's not, and it can look like it isn't when it is. And there are more than a few different formats of joystick, do you plan to load every possible driver, checking all the time, and then dump the ones not in use? What if they have TWO joysticks? Pick the one that moves? What if they hit the other one while picking up the one they want? How does your own software propose to reliably determine something that approaches near indeterminability? Trying to do this automatically will cause as many problems as it fixes. The USB can probably be done though, since it should have an ID string. You need to hurry up and write it, what is taking you so long? As always, everything seems quite 'trivial' to those who haven't actually tried to do it. Hurry up and build a running robot too while you're at it.. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Manuel Bessler wrote: Hi Alan, Do you have more pictures of your CNC ? Is the part that the steppers are mounted on some kind of plastic ? I'd like to see more pics of the details how you built your CNC :) Not yet, and yes they're 50 cent plastic electrical boxes for mounts. You can set the mouse resolution down in windows, or alternatively, you could change the scaling of the mouse axes in flightgear. (XML file) Yep found the scaling last night, the yoke scaling will be easy. Haven't figured out the mouse wheel rolling event name yet though.. Instead of teflon pads, you could use the material that those (usually white) bread cutting boards are made of. That material is relatively good to work with (sharp knife :) and are widely available. Its something that I've seen from one cockpitbuilder use and now others are using it as well, like me. ...and its not as tiny as the teflon pads from a mouse :-) Well there is plenty of leverage, so there will be very little force on the guides. The four pads can be gotten from an old dead mouse, I have a hundred mice or so laying around. If the mouse has strips, scissors are all you need since it really only needs a 1/4 piece. Really the wood works fine alone, but the teflon will reduce the wood sliding noise. Post some pictures of the rudder when you are getting there :-) Yep will be coming soon as they're made. The yoke is rediculously easy, I've reduced it to where there are no cuts. Well two cuts, but they are optional and just to shorten the unused part of the drawer slide so the whole thing will be smaller, none for bearing mounting. If I'm found dead within the next year or so, suspect a CH Products shareholder.. :) I bet that if I put up a complete webpage with how easy this is and detailed instructions, there will be at least 1000 made in the first year after the word gets around, maybe even 10,000. It is very easy, and has a very precise mechanical feel unlike most $100 bought products. The mouse is also just going to pop into a mouse pocket like holder, so you just pop it back out for normal use when you're not using the yoke. And no 4 pipe, a section of a 2 litre soda bottle or other cheap grocery container works fine since there's no force with the mouse gliding around it. Do you plan on something like a centering mechanism, so that there is a force that'll push the controls into the center positions ? Yep had a few minor errors and omissions in that first post, it was late. The bracket/mouse centers the yoke, maybe even extra weight to the bracket. Slide will need some type of springing though. Same for rudder centering. They are easy though after the functional design is optimized. The protocol and hooking it up to fgfs should be the easiest part compared to coming up and building the hardware. Yes I think so too now. Yoke is a mouse, and rudders have a controller. Actually I think the rudder controller will sit between the yoke mouse and the PC, and just insert left button down mouse rudder commands when needed. Same controller could do the same and issue mouse throttle and a bunch of other stuff as well. One problem with FlightGear needs to be changed though. When you hold button to move the rudder/throttle, motion is fine. But when the button goes up the cross hair should center back to where it was when the button was pressed to change the mode. As it is, it re-zeros so the end position is the new position for the previous alierons/elevator, but the cursor and mouse are moved to a way different position. I can live with the mouse being elsewhere although it eventually makes it off the pad. But the cursor ends up over the toolbars etc instead of snapping back to the relative middle of the screen. Maybe there is a setting for it. Also would be nice to just turn the cursor off in control move mode, so it doesn't distract in night flying especially and isn't moving over other items. It would be better with no cursor and only watching the instruments/external visuals. Whether the mouse and cursor rezero etc on mode change should be in the control file. Hmm maybe it is just haven't seen it yet, I need to type up some documentation on use as I get them figured a few things are a bit sparse.. Thanks for the detailed descriptions :) No problem, thought I'd save you some work laying out the rudders especially since I'd already just laid them out and gotten the functions working well. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel]F-16 cockpit)
John Wojnaroski wrote: Take a look at www.opengc.org. All the stuff to build the displays is there. You'll have to write your own routines for specific F-16 displays. And there is an interface to FG you can tweak to meet your requirements. I think I've convinced myself to not even work on it for the moment though. An LCD panel mounted around keyboard range with a panel display would do 90% of it with just the focusing attention in and out, so I'll keep to just basic controls only for now no need for a full cockpit. If one goes full out and make an exact cockpit placement for getting the control switch feel right etc it'd be great. But I'm thinking a 'real' panel but with all controls not in exact locations for a particular plane would be of limited use over just an LCD instrument display and generic controls. May still hook a gague or two up just to see, could be a better thing than I'm thinking off hand. Basic controls come first for now, control seperation clearly will be extremely useful even if the controls aren't in an exact placement to the real aircraft. A full cockpit sometime would be neat though. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Manuel Bessler wrote: On Wed, Dec 10, 2003 at 03:40:54AM -0500, Alan King wrote: time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) Just joined the list myself and this was one of only a few main reasons. I was drawing up homemade control system hardware this afternoon. Welcome Alan :) You showed up just at the right time. The hardware building thread started just a couple of days ago... :-) I think I have the rudder pedals down to the bare minimum for correct control, linear rudder and proportional toe brakes but only using 2 drawer slides for minimum cost and only drilled holes for easy assembly, no slots in a bellcrank etc. Yoke is just a sloped cabinet with a drawer slide underneath, two bearings mounted on this with a threaded drawer slides are pretty interesting for cockpit building. We used them for our XYZ table. http://cockpit.varxec.de/tools/ You can find them in any good home improvement store (or at home if you wanna get rid of some old funiture ;) Yep, here is a picture of my CNC/driller. I wanted mostly metal, all cheap hardware store components, and just drill hole assembly, no slotting etc. I have a large electronics inventory, and have about 400 stepper motors on hand and 2K mosfets and my own intelligent 4 and 5 phase stepper motor controller/driver board. Also while you're at it hit the beacon file, it looks good and I've now built much bigger one, note it's a 3 MB mpg.. http://home.nc.rr.com/alan69/FlightGear/CNC.jpg http://home.nc.rr.com/alan69/Beacon.mpg rod running through with the yoke. Fixed to the rod is an angle bracket, 2.5 out then several over, with an optical mouse attached. Sectioned 4 pipe fixed concentric to the rod with a pattern attached to the outside. With 2 in and out travel and 120 deg for roll it should the 120 deg, is that 60 in each direction, or 120 in each dir ? My yoke (747 style) has 180 deg total, so 90 in each dir. I have a several minutes long cockpit video from the net of a LH 747-400 where you can see the flightcontrols check. There the yoke went from -90 to +90 deg. Well I was just going at least 60 to 60 deg by what a pilot friend had said, actually it will do 180 deg total easily. With a little work, I could use a wireless mouse and even get 360 degrees continuous with the drawer slide going through a complete pipe section. give about 4 by 4 mouse travel around the pipe, for 1600 points total resolution on each axis, scaled down to reasonable for output. $10 optical mouse is the only part not absolute minimum cost, but with high res and all optical and a wheel to relocate for other use I think it's an ok trade off. Throttle and the rest are no real problem after that. Do you use that mouse as the primary mouse for fgfs for mouse yoke mode (what you get when you right click once in fgfs) or did you write a joystick driver for it ? The nice thing about using the mouse is, that the resolution is much better than with a potentiometer. It's just being built. But it did hit me looking at it last night that Windows handles 2 mice ok with both moving the pointer, just have it USB and plug it in and leave the normal mouse alone. Must have some scaling though, FlightGear is very touchy with my normal 400 dpi mouse. First dot over from center is a noticable jump, more than it should be. Will have a port to hook in my RC transmitter and multiple output formats, so I can fly either RC trans or yoke/pedals for Flightgear or FMS. Also since I need a slope cabinet for the yoke anyway, turn it around and the back side will be a dual joystick MAME controller for two players or dual joystick for Robotron 2084 etc. Trying to make it all in one so I only have ONE extra controller to have laying around! :) Should come in under $50-$60 for just the yoke/pedals part, I do PICs as well so that part's easy. The $200ish for the CH stuff really isn't that bad, but I'm going to make some for a couple friends as well. I'd rather have something that feels rock solid over a plastic game controller for myself anyway. Plus I can put it on the net and then Do you have any pics of your setup on the web yet ? I'm just laying things out, but since you're looking and others may have some interest, I put up some drawings/pics. Rudder first: http://home.nc.rr.com/alan69/FlightGear/rudder.gif I follow the KISS design philosophy. Note the gif has parts that aren't in right scale to each other, just the basic idea. OK about 1' front to back, 1' 6 wide for baseplate. Rails are easy to see, and excess rail from the minimum lengths will be cut down. On each rail is a flat guide plate, about 1' by 6. These are to take torqe instead of a second rail, and will be very cheap since you just buy a 4' by 6 finished board, and cut in 4 for both the guides and rudder pedals. Guide is flat, small 2 x 4 sections are vertical over the rails for pedals, see side view
Re: [Flightgear-devel] RE: [Jsbsim-devel] FlightGear on O'Reilly Network, December 11
Jon Berndt wrote: I can't find it. You might need to register with O'Reilly to see the article. Jon Nah it works for me, but I also looked past it at first. Just say 'It's in the three ad's at the top of the text, right one. Looks so much like an ad instead of a link many won't see it.. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Maybe we're just a few doing flightgear, but that'll certainly change over time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) Just joined the list myself and this was one of only a few main reasons. I was drawing up homemade control system hardware this afternoon. I think I have the rudder pedals down to the bare minimum for correct control, linear rudder and proportional toe brakes but only using 2 drawer slides for minimum cost and only drilled holes for easy assembly, no slots in a bellcrank etc. Yoke is just a sloped cabinet with a drawer slide underneath, two bearings mounted on this with a threaded rod running through with the yoke. Fixed to the rod is an angle bracket, 2.5 out then several over, with an optical mouse attached. Sectioned 4 pipe fixed concentric to the rod with a pattern attached to the outside. With 2 in and out travel and 120 deg for roll it should give about 4 by 4 mouse travel around the pipe, for 1600 points total resolution on each axis, scaled down to reasonable for output. $10 optical mouse is the only part not absolute minimum cost, but with high res and all optical and a wheel to relocate for other use I think it's an ok trade off. Throttle and the rest are no real problem after that. Will have a port to hook in my RC transmitter and multiple output formats, so I can fly either RC trans or yoke/pedals for Flightgear or FMS. Also since I need a slope cabinet for the yoke anyway, turn it around and the back side will be a dual joystick MAME controller for two players or dual joystick for Robotron 2084 etc. Trying to make it all in one so I only have ONE extra controller to have laying around! :) Should come in under $50-$60 for just the yoke/pedals part, I do PICs as well so that part's easy. The $200ish for the CH stuff really isn't that bad, but I'm going to make some for a couple friends as well. I'd rather have something that feels rock solid over a plastic game controller for myself anyway. Plus I can put it on the net and then anyone can go to the hardware store and then build their own cheap good flight controls. Alan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
