The UAV Playground is a collection of software components I've written in Java. They extend the Processing Development Environment (PDE) with some functionality that can help you to simulate and test different aspects of UAVs. You can as well use the UAV Playground library outside of the PDE in any Java application.UAV Playground and all the Software it is based on are freely available. The distribution and the source code can be found on the Open Source project page at code.google.com/p/uavplayground.The whole project is a work in progress and will be extended as I work on the exploration of UAVs. I'd appreciate if you leave me a comment or even better contribute to the project.Features- object oriented- modular- extendable- freeHow to use it- install the Processing Development Environemt (PDE)- download the UAV Playground distribution and follow the installation instructions- [install the FlightGear Flight Simulator (optional)]- have a look at the sketches (examples) and browse the api documentation that is included in the jar fileA very basic example- connects to the flight simulator- displays the current altitude and airspeed
The UAVsim example- controls the flight simulator via virtual joysticks or...- controls the flight simulator via a PID processor (basic autopilot)- displays various dataAdditional examplesUAV Playground - NMEA to KMLUAV Playground 1.1- New GPS NMEA data import via a network connection to FlightGear- New GPS tracking in Google Earth via a HTTP connection to the UAV Playground
So the plan is to develop some interfacing to put a physical Ardupilot(or similar) "in-the-loop"? This would be really cool, there was a blog post a while back where a guy did this using X-Plane.
Tom, what you see in the screenshot above are three different applications talking to each other over a network connection. The UAV Playground and its demo application the UAVsim (on the left) provide all the necessary (software-) interfaces to handle i/o from FlightGear (top) and Google Earth (bottom).
If your telemetry gear provides an interface you could connect it to the UAVsim. An additional window could then display the real time video from the (real) airplane. So yes, it is possible but the implementation depends on what equipment you are using.
Does system this allow for onboard video picture replacing the virtual outside view, while the virtual airplane (from rear view) or virtual cockpit view still being there displaying actual data streaming in from the telemetry? Basically, a virtual cockpit view looking out at the real-time onboard video with an option to place a virtual plane viewed from rear about 50 yards ahead inside that same real-time onboard video display. Thank you.
The autopilot's components are decoupled as much as possible and running as separate threads. As you pointed out this makes it easy to run the code on multi-processor systems.
The input and output data is shared via an event handling mechanism (Observer). This allows you to easily add a new component, for instance a telemetry device, without touching a single bit of the original code.
Another advantage of the decoupling is the interchangeability. You could replace one or all of the existing flight data components (gps, motion, actuator) with your own version (hardware or different flight sim) without any change in the existing code.
Alex, have a look at this very simple example that shows you how to use the NMEA to KML functionality without the Processing Development Environment: UAV Playground - NMEA to KML
You can directly import NMEA to Google Earth from a GPS device or you can provide Google Earth with a KML file that it reads periodically. Have a look at the KML 2.1 Tutorial.
You should be fine with any kind of network connection as long as they don't use the same port.
Thanks jaron for detail explanation, I went through all your posts but still couldn't success in interfacing FG to GE :(
I am getting errors while compiling 'FlightGearNMEAReceiver' alone without using 'Processing'. Any ideas on avoiding Processing & still be able to fetch waypoint/tracks from FG to GE?
It seems that --nmea argument & GoogleEarth-Tracking.kml is working fine but I can't see anything in GE !
Any suggestions on simplifying this whole thing? I wanted to have a separate program to read nmea strings & pass it to .kml into GE. I am also using Matlab(for Autopilot code) which is using udp, whether that can be a problem? Can't we use udp & tcp together?
NMEA from FlightGear (FG)
The class FlightGearNMEAReceiver contains the logic that provides a socket connection for FG. Once FG is started with the --nmea argument (see Start-FlightGear-UAVsim.bat) it connects to the NMEA receiver. The receiver gets the NMEA data from FG and stores it in an object of type Trackpoint (an abstraction for the NMEA GPS data). After that the NMEA receiver informs all its listener about the new GPS data it has received.
Gluing the things together
An object of type GoogleEarthKMLProvider can be added as a listener to a FlightGear NMEA receiver object. By doing so it receives all the track points from the receiver and stores them in a list called track path (see Trackpath).
KML for Google Earth
By opening the file Start-GoogleEarth-Tracking.kml in Google Earth (GE), GE starts polling the KML provider periodically via a HTTP connection and gets served with the requested track path in the KML format.
There are many different ways you can provide GPS data for GE and the method depends, among other things, on how much control you would like to have over the generated data.
Comments
If your telemetry gear provides an interface you could connect it to the UAVsim. An additional window could then display the real time video from the (real) airplane. So yes, it is possible but the implementation depends on what equipment you are using.
Does system this allow for onboard video picture replacing the virtual outside view, while the virtual airplane (from rear view) or virtual cockpit view still being there displaying actual data streaming in from the telemetry? Basically, a virtual cockpit view looking out at the real-time onboard video with an option to place a virtual plane viewed from rear about 50 yards ahead inside that same real-time onboard video display. Thank you.The autopilot's components are decoupled as much as possible and running as separate threads. As you pointed out this makes it easy to run the code on multi-processor systems.
The input and output data is shared via an event handling mechanism (Observer). This allows you to easily add a new component, for instance a telemetry device, without touching a single bit of the original code.
Another advantage of the decoupling is the interchangeability. You could replace one or all of the existing flight data components (gps, motion, actuator) with your own version (hardware or different flight sim) without any change in the existing code.
The simulation seem perfectly suited to a multi-processor system.
You can directly import NMEA to Google Earth from a GPS device or you can provide Google Earth with a KML file that it reads periodically. Have a look at the KML 2.1 Tutorial.
You should be fine with any kind of network connection as long as they don't use the same port.
I am getting errors while compiling 'FlightGearNMEAReceiver' alone without using 'Processing'. Any ideas on avoiding Processing & still be able to fetch waypoint/tracks from FG to GE?
It seems that --nmea argument & GoogleEarth-Tracking.kml is working fine but I can't see anything in GE !
Any suggestions on simplifying this whole thing? I wanted to have a separate program to read nmea strings & pass it to .kml into GE. I am also using Matlab(for Autopilot code) which is using udp, whether that can be a problem? Can't we use udp & tcp together?
The class FlightGearNMEAReceiver contains the logic that provides a socket connection for FG. Once FG is started with the --nmea argument (see Start-FlightGear-UAVsim.bat) it connects to the NMEA receiver. The receiver gets the NMEA data from FG and stores it in an object of type Trackpoint (an abstraction for the NMEA GPS data). After that the NMEA receiver informs all its listener about the new GPS data it has received.
Gluing the things together
An object of type GoogleEarthKMLProvider can be added as a listener to a FlightGear NMEA receiver object. By doing so it receives all the track points from the receiver and stores them in a list called track path (see Trackpath).
KML for Google Earth
By opening the file Start-GoogleEarth-Tracking.kml in Google Earth (GE), GE starts polling the KML provider periodically via a HTTP connection and gets served with the requested track path in the KML format.
There are many different ways you can provide GPS data for GE and the method depends, among other things, on how much control you would like to have over the generated data.
-
1
-
2
-
3
-
4
of 4 Next