On Mon, 10 Sep 2007, Anders Gidenstam wrote:
>
> Hi all,
>
> I'm experimenting with head tracking and to get the data into FlightGear I
> want FlightGear to read a stream of binary UDP packets using the generic
> protocol capability. Since it currently only support binary
Hi all,
This patch has been sitting in my source tree since 2007.
It still works, so if there is any interest in being able to handle
generic binary input protocols in FlightGear..
http://www.gidenstam.org/FlightGear/HeadTracking/FlightGear/generic_binary_input_protocol.new.diff
It is part of
rribly dirtyhack) to decode and print the results. Execute it with:
$ python test_decode.pyTo do list for the generic binary support:* use ntohl() etc to make the protocol independent of host endianess.* add CRC checksum as a possible packet footer* add binary input support
* test thoroughlyCheer
I/O module will violate the GPL
> - Not every nice (non GPL violating) user interested in extending FlightGear
> is able/willing to build the whole binary
> - Only some of the users will violate GPL
> - Generic interface simplify/facilitate FlightGear extensibility for all
> u
data coming from the UAV, to test the ground
station software etc.).
There has been talk on the mailing list before (e.g. here:
http://www.opensubscriber.com/message/flightgear-devel@flightgear.org/1750238.html
by Michael Meyers) about added binary support to the generic protocol,
but it seems
generic binary mode patch, or better yet, wants to
add it into the main FlightGear repository, reply (to the list).
Also, if anyone else has uses or requirements for binary protocols, let
discuss them here, so that we can make generic binary support as broad
and applicable as possible.
I think it
Thanks Erik,
Here is the patch. Let me know what needs to be changed, fixed, or
refactored before it can go into CVS. Note that at this point, the
binary protocol is output only.
Also attached is a really simple protocol to test the patch
(bintest.xml). Run FGFS with:
$ fgfs ... --generic=file
Hi all,
I'm experimenting with head tracking and to get the data into FlightGear I
want FlightGear to read a stream of binary UDP packets using the generic
protocol capability. Since it currently only support binary protocols for
output, I implemented some minimal support for binary
Hi!
On Friday, April 18, 2008 Haluk Sevener wrote:
>> How can I run the master-slave model with generic i/o interface?
>>How can I control a FG instance with over network using generic interface
>>with socket input option? (I failed doing this >> one. maybe my in
ary. I
believe that this is accaptable.
Regarding the different foms:
I have seen your implementation and what I believe we can do more generic.
Sure there is a part of your implementation that hard codes some attribute
names of the foms into the binary. But this could be done in a more generic
rietary users may use X-Plane.
Every coin has two sides:
- Not every I/O module will violate the GPL
- Not every nice (non GPL violating) user interested in extending FlightGear
is able/willing to build the whole binary
- Only some of the users will violate GPL
- Generic interface simplif
ote a C++ code to handle incoming messages, now try to
> change your C++ code to drive FG using position and orientation only.
> I am using generic protocol to drive FlightGear from external program.
> Protocol was changed
also
work OK.
This update includes the changes to generic input device so it can be built
under both Linux and Mac.
Please let me know if there are any problems.
Torsten,
Could you check if the change to configure.ac and src/{Input, Main}/Makefile.am
work on Linux regarding to generic inpu
able.
Not for me. :-(
>Regarding the different foms:
>I have seen your implementation and what I believe we can do more generic.
>Sure there is a part of your implementation that hard codes some attribute
>names of the foms into the binary. But this could be done in a more generic
&g
nybody how to solve
> this problem?
I connect FlightGear with my programm (which is external FDM) through
generic protocol. Generic protocol was changed to accept in/out in binary
form (not corresponding to that one in CVS tree which does binary output
only). From FG property tree I t
your receiver (or sender) code also have to use that encoding convention.
The encoding used by the generic protocol is independent of the output
channel you choose (file, TCP socket, UDP socket, serial port or
whatever).
If you are unsure about what encoding FG uses for
binary data src/Network
to implement an external control mechanism.
I have the same progrmme. It get from FlightGear terrain elevation and
send to FG airplane position, orientation, control deposition, etc. The only
difference is that I have to modify generic protocol for binary i/o.
>
> Anyway, I started the instanc
Hugo Vincent wrote:
Thanks Erik,
Here is the patch. Let me know what needs to be changed, fixed, or
refactored before it can go into CVS. Note that at this point, the
binary protocol is output only.
I've made some small changes (mainly changing printf to SG_LOG, etc) and
committed it t
u could just supply a more generic 32 bit binary but it's always
nice to have the source too.
Cheers,
AJ
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integra
>> All valid points but irrelevant for the GPL. It is already possible to
>> connect proprietary software to FlightGear using the generic binary
>> (socket) protocol handler, but that doesn't violate the GPL. Plug-in
>> interfaces tend to do because they are considere
ompile and re-link FlightGear
against a particular set of libraries. Thus there can never be a single "HLA
compliant" FlightGear binary.
To follow the "do things right" rule I think it would be great to implement a
generic interface for standalone I/O modules. Both Micro$oft FSX an
you ask me.
Yes, that is extremely generous. In fact, this allows me to implement the
generic plug-in interface and distribute the modified FlightGear along with my
binary runtime modules that are all under GPL.
>That linking non-GPL modules would be illegal, anyway, doesn't make
>the
ment. That means to me it's
> possible to store in the property tree float ... ooopsss ... double values
> with an exact decimal precision. How do I deal with that? What am I still
> missing? Why the property-assign can do that excatly and a generic protocol
> can't?
The problem com
Martin Spott schreef:
> Well, we've been driving two 'external' displays on last years LinuxTag
> exhibition using the 'generic' protocol. We were surprised to encounter
> a significant performance hit on the master machine serving two clients
> at 20 Hz. Th
On Fri, 30 Jun 2006, Robin van Steenbergen wrote:
>> Main thing is that I can't find the documentation for the protocol used
>> by FlightGear for data I/O.
There are several protocols. In fact, infinitely many. ;)
You can define your own protocols with --generic (binary or te
>
> I'm saying that if your generic protocol file specifies
>
>true
> network
>
> your receiver (or sender) code also have to use that encoding convention.
> The encoding used by the generic protocol is independent of the output
> channel you choose (file, TCP s
> All valid points but irrelevant for the GPL. It is already possible to
> connect proprietary software to FlightGear using the generic binary
> (socket) protocol handler, but that doesn't violate the GPL. Plug-in
> interfaces tend to do because they are considered 'part of
Hi!
On Saturday, April 26, 2008 Adam Dershowitz wrote
>
> Then your extension must be handling the input differently. When data
> is read in from a text file, using --generic it is not possible with
> the current code to read in a double. It is called an FG_DOUBLE in
> some pla
a recording of a simple takeoff at high frequency, with everything
at the defaults:
fgfs --generic=file,out,32,/Users/dersh/Documents/Cases/587\
Animation/DFDR\ data/test_out.csv,playback
and then did a playback:
fgfs --generic=file,in,32,/Users/dersh/Documents/Cases/587\
Animation/DFDR\ da
lity (DLC). However, some RTI libraries may
> not be compliant to the SISO standard.
Ok.
> >Regarding the different foms:
> >I have seen your implementation and what I believe we can do more generic.
> >Sure there is a part of your implementation that hard codes some attribute
&
that FG is sending out its
> outputs
> > in floating point format, because I'm not sure it is, I have the generic
> > file setup for binary mode, but I'm not convinced that FG is transmitting
> > data as floats, I think it might actually be transmitting data as
> integer
in sync, so I reckon I will have to do the
> binary chop manually. This is really a labour of love & curiosity, cos
> all is ok on another more powerful m/c with nvidia graphics + 4
> monitors.
Try checking out the c172p as of the commit before
caeebdbd935015fd7b2bb3071
Hugo Vincent wrote:
Any one had a chance to look over the patch yet?
What needs to be changed/fixed/rewritten/redesigned(!) before it can be
applied to the main CVS version?
No need to panic, If I have to apply it I just need some time to look
over it and apply it. This may take a few days.
On Tue, 16 Aug 2011, Derrick Washington wrote:
> One last thing is there a way to ensure that FG is sending out its outputs
> in floating point format, because I'm not sure it is, I have the generic
> file setup for binary mode, but I'm not convinced that FG is transmitting
On Apr 26, 2008, at 12:11 PM, Alex Buzin wrote:
> Hi!
> On Saturday, April 26, 2008 Adam Dershowitz wrote
>>
>> Then your extension must be handling the input differently. When
>> data
>> is read in from a text file, using --generic it is not possible with
&g
FlightGear so that
> it will listen to my UDP-packets? It would also help, if someone could tell
> me what data FlightGear expects in the packets...
It is described in the protocol configuration file:
http://www.gidenstam.org/FlightGear/HeadTracking/headtrack.xml
run: fgfs --generic=s
;m not an fg networking user, so I can't comment on or commit
>> your patches. I'll leave that to Curt. :-)
>>
>No, this is not the problem. May be in some cases. I provide FG
> with
> data at 100Hz in binary form (my extension for generic protocol).
> The
gt; marco
>
Hi Marco,
You are wanting to use the so-called generic protocol. This allows you
to log what you wish.
I found that the link below was very thorough. While I did not run the
compiled binary (no MS Windows here), the set up instructions are
very clear and helpful. (Especially if
One thing to add...
Ralf Gerlich wrote:
> Currently there is no shapefile version of GSHHS 1.5, which was
> available for 1.3, so we need to get some tool to import the custom
> binary format of GSHHS into the database, including the handling of
> shorelines crossing the dateli
nVidia drivers
> nvidia-kernel-2.6.26-1-686-bigmem 173.14.09+3 NVIDIA
> binary kernel module for Linux 2.6.26
> nvidia-kernel-2.6.26-1-vserver-686-bigmem 173.14.09-5+2.6.26-13 NVIDIA
> binary kernel module for Linux 2.6.26
> nvidia-kernel-common
; FlightGear so that it will listen to my UDP-packets? It would also
> help, if someone could tell me what data FlightGear expects in the packets...
>
> It is described in the protocol configuration file:
> http://www.gidenstam.org/FlightGear/HeadTracking/headtrack.xml
>
> run:
ding out its
> outputs
> > in floating point format, because I'm not sure it is, I have the generic
> > file setup for binary mode, but I'm not convinced that FG is transmitting
> > data as floats, I think it might actually be transmitting data as
> integers
> >
> It's an issue with the finite precision of floating point variables.
> Everyone is suprised when first seeing this. Only values which happen to
> be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
> accurately. Everything else, even simple _d
from
both Textures and Textures.high directories. Renaming the Texture.high
directory cut the loading time in half...
Is it possible to prevent the generic autopilot,2d panels and any
unneccesary instruments from being loaded/initialized? I see
instrument.xml files in several folders , does this
t. :-)
>
No, this is not the problem. May be in some cases. I provide FG with
data at 100Hz in binary form (my extension for generic protocol). The data
can be lost while converting from double to float only. At 0.9.10 all was
fine but not at 1.0.0.
I look CVS for fix. It removes c
On Sat, 01 Dec 2007 20:46:33 +0100
AnMaster <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> I'm working on a custom protocol (generic protocol via xml file) for talking
> with a daemon, however I do have some issues:
>
> * How d
l
specification for a binary protocol so an external application can feed
flightgear an xml file to produce binary output matching exactly what that
external app wants and expects. Kind of like the "generic" protocol only
the underlying data is transmitted in binary form.
Curt.
--
guys think?
2. event names for buttons of mice, joysticks (for generic desktop page), and
gamepads
At this moment, there's no button-left, button-right, etc in Mac OS X
implementation.
The same is applied for gamepad buttons, and joystick buttons. Instead, the
button events are named like bu
Hi
I need to know if the inputs coming from FG, while using a generic
protocol having binary mode set to true, are coming in as integers that need
to be converted to floating point or is FG actually sending in a floating
point word, a byte at a time? So my code to receive FG data looks
> One last thing is there a way to ensure that FG is sending out its
>> outputs
>> > in floating point format, because I'm not sure it is, I have the generic
>> > file setup for binary mode, but I'm not convinced that FG is
>> transmitting
>> > da
Only values which happen to
be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented
accurately. Everything else, even simple _decimal_ values such as "0.1"
or "0.775" cannot be represented exactly in _binary_. Usually this
doesn't matter,
On Sun, 2011-08-07 at 20:33 -0400, Derrick Washington wrote:
> Hi
>
>I need to know if the inputs coming from FG, while using a generic
> protocol having binary mode set to true, are coming in as integers
> that need to be converted to floating point or is FG actually
On Sun, 7 Aug 2011, Derrick Washington wrote:
> Hi
>
> I need to know if the inputs coming from FG, while using a generic
> protocol having binary mode set to true, are coming in as integers that need
> to be converted to floating point or is FG actually sending in a floating
I was getting these errors in FG OSG before Maik made me a new win32 binary for
osg, now I cannot start plib due to similar problems.
Initializing Aircraft structure
Initializing HUD Instrument
Reading instruments from C:/Program Files/FlightGear/datacvs/Aircraft/Generic/ge
neric
> How can I pack several pieces of information into one variable?
Binary --> Decimal conversion technique would allow three on/off settings to be
stored in a decimal number valued 0-7. Switch one has a value of 1. Switch
two has a value of 2. Switch three has a value of 4. Add
On samedi 11 octobre 2008, Rob Shearman, Jr. wrote:
> > How can I pack several pieces of information into one variable?
>
> Binary --> Decimal conversion technique would allow three on/off settings
> to be stored in a decimal number valued 0-7. Switch one has a value of 1.
e corrupt)
..you wanna swap UUIDs for physical devices in your rescue
boot, these newbie recipes trot you thru it step by step:
http://www.sorgonet.com/linux/grubrestore/ or the Ubuntu way:
https://help.ubuntu.com/community/Grub2 or the generic way:
http://grub.enbug.org/Manual , sp
t as a bad idea
that either caused stutter or didn't provide enough properties. Sending from
nasal would be the SANE way to solve this for me.
Regards,
Arvid Norlander
K. Hoercher wrote:
> On Sat, 01 Dec 2007 20:46:33 +0100
> AnMaster <[EMAIL PROTECTED]> wrote:
>> I'm wo
he full pavement/taxiway description, made of several words
- Directly associate runways objects with their ILS navrecord (if one exists)
- Add variable winds (direction and gusts) for the boundary layer if defined in
METAR.
- Immediately fetch a metar if real-weather-fetch is re-enabled at runtime
- New
ne, here is just what I thought would be good.
fgdata should be only the VERY BARE ESSENTIALS to run the binary.
Possibly some generic stuff like effects, too.
Copy & Paste from gitorious web if. I marked the things that should go
into separate repos. Without warranty, I'm no
ent system is broken(Ubuntu stopped booting after I moved
> > > > > my / to another HD, changed UUIDs in menu.lst and fstab, didn't
> > > > > work, also my partition seems to be corrupt)
> > > > >
> > > ..you wanna swap UUIDs for physical devices in y
s coming from FG, while using a generic
> > protocol having binary mode set to true, are coming in as integers
> > that need to be converted to floating point or is FG actually sending
> > in a floating point word, a byte at a time? So my code to receive FG
> > data looks some
o send from a C# application the position of several aircrafts to a
> > flight gear multiplayer server.
> > The question is ... how can I get the aircraft orientation values from
> > position, yaw, pitch and roll?
> > thank you in advance.
> > marco
> >
>
Me asking a genuine question:
> Why do I need to make a song and dance to get the last stable under
> Linux when it works no fuss under Windows? Are we genuinely unable to
> provide a working generic 32 and a 64bit set of binaryies for Linux? I
> know that lib paths and
position of several aircrafts to a
> > flight gear multiplayer server.
> > The question is ... how can I get the aircraft orientation values from
> > position, yaw, pitch and roll?
> > thank you in advance.
> > marco
> >
>
> Hi Marco,
>
>
> You are w
the stuff
in git.)
If anyone thinks this might be relevant, just take a look at
https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
This is a living instance of a fossil repository, BTW: the
fossil binary, statically-linked except for libz, is ~900KB.
Yet it includes a simple wiki, a *ve
to ensure that FG is sending out its outputs
in floating point format, because I'm not sure it is, I have the generic
file setup for binary mode, but I'm not convinced that FG is transmitting
data as floats, I think it might actually be transmitting data as integers
or something else. I make thi
ombined
MAX/RTO modes, correct disengage behaviour and more disengage conditions.
Update MSVC project files for the autobrake files
Don't crash with UFO FDM, etc, or other FDMs that don't define global props
needed - just go into passive mode.
Don't look for /velocities/ground
desktops free of
'Your computer is at risk!' and other attention-grabbing messages very much.
But... why?
Why do I need to make a song and dance to get the last stable under Linux when
it works no fuss under Windows? Are we genuinely unable to provide a working
generic 32 and a 64bit
Linux when it works no fuss under Windows? Are we
> genuinely unable to
> > provide a working generic 32 and a 64bit set of
> binaryies for Linux? I
> > know that lib paths and versions are different across
> distribtions, but
> > can't one simply compile th
n't seem to appear in cockpit view or tower view, but they make all
> the other views almost unusable.
Yes.
> I have checked the developers lists,
> and I have seen people mention problems similar to this, but nobody
> seems to have a good solution.
I assume you found the thread
nfiguration files directly, the ability to use commands
> which actually do what I tell, and desktops free of 'Your
> computer is at risk!' and other attention-grabbing messages
> very much. But... why?
>
> Why do I need to make a song and dance to get the last
> stabl
ing things :)
>
Well, I already gave you the outline over breakfast in Berlin, but
nevertheless, I feel that it doesn't hurt to give a quick summary of our
generic release procedure. I'll start by our historical cvs based procedure,
and will later on give some indication as to how
Hi Hans,
Thanks for your contribution!
There are some workarounds that I made for Macs (Xcode project) on
these issues.
You can check out the patches from the svn repository available from
FlightGear Mac OS X website so take a look at that.
Since I need to make universal binary packages for
James Turner schreef:
>
> - My plan would be to build some generic classes which can be extended
> or configured to support Boeing or Airbus displays, or other similar
> systems (including the G1000). My current perception is that this
> would be pretty doable -
I agree that the property system is for generic data ... so adding
color_vectors or position_vectors is really out of the scope of what it
should be intended for. This is too specific and I agree that it creates a
mess and there's then no good place to draw the line when the next person
Curtis Olson wrote:
> I agree that the property system is for generic data ... so adding
> color_vectors or position_vectors is really out of the scope of what it
> should be intended for. This is too specific and I agree that it
> creates a mess and there's then no good place
Curtis Olson wrote:
> I agree that the property system is for generic data ... so adding
> color_vectors or position_vectors is really out of the scope of what it
> should be intended for. This is too specific and I agree that it
> creates a mess and there's then no good place
gt;
>
> Here is the slave’s command line.
>
>
>
> ./fgfs –aircraft=c172p –native-fdm=socket,in,30,192.168.1.8,5500,udp
> –fdm=external
>
Hi John,
Sorry for the slow reply. Since you are using the --native-fdm protocol,
all the values you are sending are full precision bin
g, around
>
> > LinuxTag Durk is often quite busy organising things :)
>
> >
>
> Well, I already gave you the outline over breakfast in Berlin, but
> nevertheless, I feel that it doesn't hurt to give a quick summary of our
> generic release procedure. I'll start
bad design; it doesn't seem to be required to enable an
otherwise impossible feature but at the same time introduces the
scope for new errors whilst breaking the consistency of the current
data atomicity.
LeeE
On Sunday 05 April 2009, Curtis Olson wrote:
> I agree that the property system
elop a demand to also
> benefit from such a change eventually (just because they can already do
> all of this simply by using a more verbose, user-friendly and
> self-explanatory format that's been in use for years).
If a subsystem can't parse a property, chances are good it doesn&#x
82 matches
Mail list logo
