¿This should work for catch MAVLink messages from a real drone and paint it in FG? As I said I was testing as SITL, all running in my laptop. I tought that Ardupilot was sending MAVLink messages to FG (and my GroundStation) and I only need to run a command like "fgfs -generic=socket,out,20,5503,udp,MAVLink" (I had previously installed FG, copy the MAVLink.xml in the Protocol path and give permissions to the path). I am working in the same case, but now I only can test in SITL (using Ardupilot with FG). Robotop wrote in Tue 10:13 am:Hi, did you finally make this work? Where can i find more details about the net_fdm packet ? srinath79 Posts: 5 Joined: Wed 6:12 pm If i start FG with the above options(a lot of the options like airport etc are redundant for me), i guess i would just need to have a middleware(not Matlab) that packs data in the fright format. Then it has a net_fdm packet for flightgear which sends FG the data in the format that it requires. #setenv FG_SCENERY C:\Program Files\FlightGear/Scenery:$FG_ROOT/Scenery:$FG_ROOT/WorldSceneryįgfs -aircraft=HL20 -fdm=network,localhost,5501,5502,5503 -fog-fastest -disable-clouds -start-date-lat=2004:06:01:09:00:00 -disable-sound -in-air -enable-freeze -airport-id=KSFO -runway=10L -altitude=7224 -heading=113 -offset-distance=4.72 -offset-azimuth=0 #setenv FG_ROOT C:\Program Files\FlightGear/data #setenv LD_LIBRARY_PATH C:\Program Files\FlightGear/lib:$LD_LIBRARY_PATH I just remembered that Simulink(part of Matlab) has a flight gear interface, that basically does this.įirst it starts flightGear with the following options The generic protocol can be also extended to do similar things, but requires a fair amount of scripting space workaroundsĪnd do note that you'll typically want to explicitly disable controls/fdm to pull this off, as in sync'ing multiple instances, see for example. Personally, I would probably go with telnet for starters, just because it is so straightforward - and because it supports polling, but also subscription-based notifications using less than 10 lines of code (python/perl etc): Īnother option is a web-based protocol, recently we also have support for AJAX/web sockets. It depends, there are several I/O options - the generic protocol requires an XML file like you say, see: įor the sake of simplicity, you could also use the props/telnet protocol, which simply requires a TCP connection, and you can run commands to get/set properties directly - i.e. If you'd like to see additional suggestions posted, please provide some details on the hardware/transport mechanisms, protocols and message formats involved. On the other hand, a more modular approach may be easier to implement initially, especially for people new to FG, new to C++ - who may already have experience doing this sort of thing outside FG. If this involves any form of USB devices that are currently not supported by FlightGear, there's also the pending USB/HID-support effort, see: įor FlightGear as a project it would obviously be better to identify building blocks required to pull this off and then augment/extend the simulator accordingly. Regarding #1, you'll want to look at existing I/O means and see if/how they could be reused/adapted to be useful, see for example: viewtopic.php?f=36&t=10173 The latter obviously requires being able to build from source, and knowing sufficient C++. directly modifying FlightGear by adding support for the required I/O protocols.a separate/standalone program acting as a proxy between FlightGear and your hardware/telemetry. This kind of thing would typically be implemented in either of two ways:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |