Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. 26664aaff0e2f97db916909218d849b51636ccc0

2012-08-29 Thread James Turner

On 29 Aug 2012, at 06:09, Flightgear-commitlogs wrote:

 - Log -
 commit 26664aaff0e2f97db916909218d849b51636ccc0
 Author: Mathias Froehlich
 Date:   Mon Aug 27 20:51:16 2012 +0200
 
Push SGMaterial use into these classes that need it.

Nice work Mathias - much better decoupling of the AIModels from the scene. 
Thank you.

James


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] feature request

2012-08-29 Thread Arnt Karlsen
On Tue, 28 Aug 2012 22:50:31 -0700 (PDT), Michael wrote in message 
1346219431.79144.yahoomailclas...@web140204.mail.bf1.yahoo.com:

 http://www.kickstarter.com/projects/1523379957/oculus-rift-step-into-the-game
 
 I believe at the above link, they have some more complete with
 development sdk, but only for 3 more days?
 
 I'll wait for the final product, but yes this is for getting ready
 games. 3D glasses are very cool, but this will be huge.

..aye, meanwhile, there's prior art: ;o)
http://hackaday.com/2009/10/27/head-mounted-computer-with-spit-bailing-wire/
http://www.popsci.com/gadgets/article/2009-10/cardboard-smartphone-sweet-diy-augmented-reality-googles

..using 2 cellphones, one for each eye, means resolution is 
2x1280x800 if you use 2 Samsung Galaxy Note phones.  5.3in 
screens, each weighs 178 grammes.  Or you can try 2 S3s:
http://www.phonearena.com/reviews/Samsung-Galaxy-S-III-vs-Samsung-Galaxy-Note_id3045

..with 2 screens, you probably want them mounted at an e.g 35 
degree angle to keep the screen height the same around you.  

..to move the cell phone screens really close, trim the box to 
size and play with e.g. 3+ glasses inside the safety goggles,
until you have a nicely sized view.

..a good way to find the right strenght glasses, is hold the 
cell phone screen as close as you want it, you want to be 
able to see the horizon over the glasses and the cell phone 
screen thru the glasses at exactly the same time, _without_ 
wasting time refocusing, or _without_ squinting, you want 
your view _comfortable_ and _pleasant_, sacrifizing anything 
here merely adds to the pain when you e.g. crash fpv planes 
on eye fatigue.

..refocusing wastes a second or so, every time you refocus,
not what you want when you e.g. try pick up an fpv plane for 
a rc-style landing.  
 
..this augmented VR goggle rig idea also works in plexi glass 
boxes, just copy the marker idea below and look over the 
glasses to 'uncover' the plane.
http://www.popsci.com/gadgets/article/2010-05/gadgets-timeline-mobile-augmented-reality-system

..the obvious next steps:
http://diydrones.com/profiles/blogs/fpv-with-the-ar-drone-with-head-up-display
http://www.theblaze.com/stories/google-reveals-design-for-virtual-reality-glasses-would-you-wear-them/



-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Running Nasal at simulation rate

2012-08-29 Thread Johnathan Van Why
I know this has been brought up before, but it's been a while so I'll bring
it up again.

I have a need to run Nasal code at the same rate as the simulation.
Currently, without modifying the source code for FlightGear, the only way
to do this is to find a property updated at the right time in the
simulation cycle and set a listener on it. From a code quality standpoint,
this is less than ideal.

There is a thread on the forums discussing this at
http://flightgear.org/forums/viewtopic.php?f=46t=17069#p164697. In this
thread, a couple of viable ideas are discussed. These ideas are:

1) Run a second events system and add an additional parameter to Nasal's
settimer allowing you to use this new events system. Hooray has already
created a patch for this (in the linked thread).

2) Add in a signal that is fired each simulation step, probably right
before the Autopilot system is run.

At this point, I am unsure which to pursue. Which method do you find to be
better?

Thank you,
Johnathan Van Why
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. 26664aaff0e2f97db916909218d849b51636ccc0

2012-08-29 Thread Mathias Fröhlich

Hi,

On Wednesday, August 29, 2012 09:08:44 James Turner wrote:
 Nice work Mathias - much better decoupling of the AIModels from the scene.
 Thank you.
Thanks, it was independent of what you started. It just originates from moving 
the bvh stuff to simgear core which could be solved like that ...

Greetings

Mathias

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Running Nasal at simulation rate

2012-08-29 Thread ThorstenB
 From: Johnathan Van Why jrvanwhy@gm... - 2012-08-29 13:20

 I have a need to run Nasal code at the same rate as the simulation.

 At this point, I am unsure which to pursue. Which method do you find to be
 better?

To be frank, the whole idea is just bad in the first place - so I vote 
for #3: avoid *any* Nasal in the fast simulation loop.
Nasal execution is slow and non-deterministic. Running it in the fast 
simulation loop is the last thing we want.

I know, some people on the forum would like to eventually replace 
fgfs(.exe) with nasal(.exe), because apparently everything is just 
better (tm) when implemented in Nasal (core = bad, nasal = good). But I 
really think this is a completely wrong direction - and harming the project.

Concerning your original issue on implementing an autopilot: a much 
better way to do it is to avoid Nasal for the actual autopilot 
controller elements (numeric computation). Instead, use XML autopilot 
rules for the filter, gain, damper, integrator elements:
http://wiki.flightgear.org/Autopilot_Configuration_Reference

You can then use Nasal for the high level stuff, and 
enable/disable/switch the individual controller elements (e.g. in order 
to automatically switch the autopilot mode when capturing the ILS). 
There are some nice examples with fgdata/Git aircraft. You could look at 
the 777.

This is also how such things are done in the real world: controllers 
aren't implemented in imperative programming languages these days - 
especially not in scripting languages. People use model-based design and 
connect controller elements - using graphical tools like 
MATLAB/Simulink. Obviously, FG is missing a graphical interface to 
specify the controller rules - but the idea of specifying through XML is 
the same and specification is straight forward.

cheers,
Thorsten


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Running Nasal at simulation rate

2012-08-29 Thread Jon S. Berndt
 Concerning your original issue on implementing an autopilot: a much
 better way to do it is to avoid Nasal for the actual autopilot
 controller elements (numeric computation). Instead, use XML autopilot
 rules for the filter, gain, damper, integrator elements:
 http://wiki.flightgear.org/Autopilot_Configuration_Reference
 
 You can then use Nasal for the high level stuff, and
 enable/disable/switch the individual controller elements (e.g. in order
 to automatically switch the autopilot mode when capturing the ILS).
 There are some nice examples with fgdata/Git aircraft. You could look
 at the 777.
 
 This is also how such things are done in the real world: controllers
 aren't implemented in imperative programming languages these days -
 especially not in scripting languages. People use model-based design
 and connect controller elements - using graphical tools like
 MATLAB/Simulink. Obviously, FG is missing a graphical interface to
 specify the controller rules - but the idea of specifying through XML
 is the same and specification is straight forward.
 
 cheers,
 Thorsten

I'd strongly agree with Thorsten here. It's nothing against Nasal from me -
I've not even used it - but creating an autopilot (or any GNC or system
model, for that matter) can be done very effectively with discrete objects
such as summers, gains, controllers, filters, switches, etc., much as JSBSim
has done with the system components. This is a standard approach in industry
as Thorsten mentions as exemplified by Mathwork's $imulink product.
Scilab/Scicos is similar in concept. Control system topologies are often
diagrammed in a way that can lead to a one-to-one correspondence between a
block and a control system object that can be referenced in an XML file, if
the control system component library has been defined properly. This, again,
is the way that JSBSim has approached the solution.

Some benefits to such an approach include (IMHO) better testability, more
predictability, and easier interface (someday) with a GUI tool, should one
materialize. The downside is that XML can be verbose, but it's a price I've
come to accept.

Jon



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Gear transit times

2012-08-29 Thread castle . 64
Hi, 

Is it possible to specify gear up and down transit times for each gear? In real 
airplanes the gear never ( well rarely, maybe ) sequence in perfect unison. In 
reviewing the xml files for the 737, I note there are transit times defined for 
each flap position, but the kinematics for the gear is only a single value for 
up or down based on gear selection state. 

Is this something in Nasal? or native code or something in JSBsim? 

Thanks 
Jack 

- Original Message -

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Gear transit times

2012-08-29 Thread Jon S. Berndt
Jack,

 

Check out the attached message from the JSBSim developer list.

 

Jon

 

 

From: castle...@comcast.net [mailto:castle...@comcast.net] 
Sent: Wednesday, August 29, 2012 7:52 PM
To: FlightGear developers discussions
Subject: [Flightgear-devel] Gear transit times

 

Hi,
 
Is it possible to specify gear up and down transit times for each gear?  In 
real airplanes the gear never ( well rarely, maybe ) sequence in perfect 
unison.  In reviewing the xml files for the 737, I note there are transit times 
defined for each flap position, but the kinematics for the gear is only a 
single value for up or down based on gear selection state.

Is this something in Nasal?  or native code or something in JSBsim?

Thanks
Jack

  _  

 

---BeginMessage---
 Happy New Year everybody. 
 
 I have been working on individual gear motion and failure for 
 the last week and I think the result is usable.
 This change deals with the following:
 
 a) The gear position is computed for each individual gear if 
 it is retractable and stored in a property named 
 gear/unit[n]/pos-norm. The current implementation holds all 
 gear positions in the property gear/gear-pos-norm.
 The suggested implementation does not break existing 
 configurations that use gear/gear-pos-norm. 
 
 b) To make a gear prone to failures, a actuator element may 
 be used to drive each individual gear instead of a 
 kinematic element.
 
 My configuration for the landing gear looks like this:
 
 channel name=Landing Gear
 actuator name=Gear Nose Actuator
 inputgear/gear-cmd-norm/input
 rate_limit0.1/rate_limit
 outputgear/unit[0]/pos-norm/output
 /actuator
 actuator name=Gear Left Actuator
 inputgear/gear-cmd-norm/input
 rate_limit0.13/rate_limit
 outputgear/unit[1]/pos-norm/output
 /actuator
 actuator name=Gear Right Actuator
 inputgear/gear-cmd-norm/input
 rate_limit0.15/rate_limit
 outputgear/unit[2]/pos-norm/output
 /actuator
 /channel
 
 Three files have to be changed for this:
 FGLGear.h
 introduces the method GetGearUnitPos() and two variables 
 GearPos for the current gear unit position and useFCSGearPos, 
 a flag for backward compatibility.
 
 FGLGear.cpp
 - implements GetGearUnitPos() which returns the current gear 
 unit position. It checks if the useFCSGearPos flag is set or 
 the gear/gear-pos-norm property has changed. This is for 
 backward compatibility
 - binds and unbinds the gear/unit[n]/pos-norm properties the 
 the GearPos variable
 
 JSBSim.cpp
 use the new gear-GetGearPos() method instead of FCS-GetGearPos()
 
 I have succesfully testet this with an existing unchanged 
 configuration for the 737 and a modified configuration using 
 the above example for the SenecaII.
 
 Here are FlightGear screenshots demonstrating the new feature:
 http://www.t3r.de/fg/gear-failure-1.jpg
 http://www.t3r.de/fg/gear-failure-2.jpg
 http://www.t3r.de/fg/gear-failure-3.jpg
 
 I hope this finds its way into JSBSim - it's fun to try a 
 landing on a partially failed gear. Comments are welcome.
 
 The attached diff is against FlightGear cvs, but I can 
 provide one against current JSBSim cvs.
 
 Sorry for the long posting.
 
 Torsten

Hi, Torsten:

Hey, don't apologize for the long posting - it usually means a lot of
work has been done. :-)

In theory, treating each landing gear individually seems like a good
idea. In retrospect, I don't know why we didn't do it that way in the
first place.

The changes seem sensible. I'll look at this more at lunchtime. Unless
anyone has any objections, I'll try to get this into JSBSim cvs in the
next day or two. If I don't, please remind me and/or post a Feature
Request at the JSBSim web site. I've been trying to address some of
those in the past few days, and having the feature request and bug
reports has been very helpful.

Next, we probably should think about doing something similar for the
spoilers, flaps, etc. - that is, treating them individually. I have some
thoughts on that, but that's another topic.

Jon

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Jsbsim-devel mailing list
jsbsim-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
___
The JSBSim Flight Dynamics Model project
http://www.JSBSim.org
___
---End Message---
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and 

Re: [Flightgear-devel] Gear transit times

2012-08-29 Thread Scott Hamilton
Yes there are two or three aircraft that do this. I've modified the A380 in 
flightgear to use three groups with different times.

I'm not near my desktop at the moment but can send you what I had modify to 
make it work. 
If you wanted detailed realism you could make different config for each gear 
and add a small offset depending on hydraulic pressure which could have some 
random filter applied..

S.

castle...@comcast.net wrote:

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Gear transit times

2012-08-29 Thread castle . 64
Thanks, Jon 

judging by the date on the msg and looking over the code in an older 2.4 ( 
released around 2010 ) would appear the suggested change is in. And the 
property rate-limit sets the rate at which the actuator moves. Correct? 

node-getChild(position-norm, 0, 
true)-setDoubleValue(gear-GetGearUnitPos()); 

is the line of code in JSBSim.cxx. 

And to simulate a gear failure, one would set the rate limit property to zero? 

Neat! I'll give it a try tomorrow. Just installed a new gear system and gear 
indicators in the 737. Yes, downsizing the sim from a 747 to a 737 to make room 
for the new collimated displays. As Gene put it, serving as his first victim 
for the big iron display. The next few months will be interesting ;-) 

Jack 

- Original Message -
From: Jon S. Berndt jonsber...@comcast.net 
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net 
Sent: Wednesday, August 29, 2012 9:10:30 PM 
Subject: Re: [Flightgear-devel] Gear transit times 




Jack, 



Check out the attached message from the JSBSim developer list. 



Jon 








From: castle...@comcast.net [mailto:castle...@comcast.net] 
Sent: Wednesday, August 29, 2012 7:52 PM 
To: FlightGear developers discussions 
Subject: [Flightgear-devel] Gear transit times 




Hi, 

Is it possible to specify gear up and down transit times for each gear? In real 
airplanes the gear never ( well rarely, maybe ) sequence in perfect unison. In 
reviewing the xml files for the 737, I note there are transit times defined for 
each flap position, but the kinematics for the gear is only a single value for 
up or down based on gear selection state. 

Is this something in Nasal? or native code or something in JSBsim? 

Thanks 
Jack 
- Original Message -



-- 
Live Security Virtual Conference 
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ 
___ 
Flightgear-devel mailing list 
Flightgear-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/flightgear-devel 
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Gear transit times

2012-08-29 Thread castle . 64
Hi Scott, 

Yes, please send me your mods when you have a moment. 

Thanks 
Jack 

- Original Message -
From: Scott Hamilton scott.hamil...@popplanet.biz 
To: FlightGear developers discussions 
flightgear-devel@lists.sourceforge.net 
Sent: Wednesday, August 29, 2012 9:27:52 PM 
Subject: Re: [Flightgear-devel] Gear transit times 

Yes there are two or three aircraft that do this. I've modified the A380 in 
flightgear to use three groups with different times. 

I'm not near my desktop at the moment but can send you what I had modify to 
make it work. 
If you wanted detailed realism you could make different config for each gear 
and add a small offset depending on hydraulic pressure which could have some 
random filter applied.. 

S. 

castle...@comcast.net wrote: 


Hi, 

Is it possible to specify gear up and down transit times for each gear? In real 
airplanes the gear never ( well rarely, maybe ) sequence in perfect unison. In 
reviewing the xml files for the 737, I note there are transit times defined for 
each flap position, but the kinematics for the gear is only a single value for 
up or down based on gear selection state. 

Is this something in Nasal? or native code or something in JSBsim? 

Thanks 
Jack 

- Original Message -


-- 
Live Security Virtual Conference 
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ 
___ 
Flightgear-devel mailing list 
Flightgear-devel@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/flightgear-devel 
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel