FG Interface

From FlightGear wiki
Revision as of 20:02, 6 June 2017 by Www2 (talk | contribs) (Changes Mo in Mb/MB)
Jump to navigation Jump to search

FG Interface aim to make easier the building of real cockpit environnement and is dedicate to comunicate with flight simulator Flightgear. FG Interface has 2 distinct parts. The hardware and the software part.
Interface hardware part is build around a Raspberry Pi nano computer.
Interface software is written in Python 3

The Story

At the begining come the wish to see if it was possible to comunicate with the sim. Quickly, with a simple telnet client and the built in server it became easy to write the first scripts in Python. Python language have been choosen because telnet class was available in Flightgear sources. The first script was written , leading to automate some action, But I was not able at that moment to use switches or other to act on the simulator.

In the same time, big red & white old man bring me a wonderfull thing, a new nano computer generation, able to carry a full linux version, mono core cpu, the RPi was a small guy ..., 512 MB RAM. .... and a full duplex TCPIP RJ45 100 Mb/s.

Few time later, marriage was celebrated. It was easy to setup, all hardware drivers was already existed, even some very powerfull, and most of time low level library was existing too. Quickly the possibilities offered by raspberry went well beyond my expectations. The first tests showed how easy it was to configure and implement cockpit instruments. But to be easy to use, it was necessary to write a few libraries to offer a simple and powerful tool.

One year later, after doing some shopping and spending time between soldering iron, electronics and learning python language, I was able to build the first FG interface, a real prototype with 256 outputs and 128 inputs . Meanwhile, Raspberry Generation 2 was available, with 1 Gb ram.

Today, after 3 years working on this project, i am very close to release the first public version. Lot's of work have been done since i was playing with the propertries tree over a simple telnet client. Each element of the cockpit that you implement is represented in the interface by a virtual object manipulable at the breasts of the interface. Depending on the type of object [switch, indicator, display ...] this gives access to a different methods allowing the management of the object.

For example, in a display objet you ll have access to fonction as like :

  • WriteDisplay(value), a function that will display value you send on the display object
  • WriteDigitDisplay(value, digit), a function that will allow to manage a display digit

For a switch, a function like getSwitchState() will return the state of the physical switch.

All the background stuff is manage by the interface. There are only objects to manage and all informations needed have to be setup in configuration files. This mean that the main script still need to be wrote, calling object to be manage and process information comming from FG.

On the communication side, the server is build around the socketsever module, bringing a very powerfull tool to create and setup network comunication. A library is also available inside the interface package.

Electronic schema and PCB board are on the road and i am actually finishing verify process.

FG Interface in it actual state, look like more a tool box, than a full finish product. But it make the job. It need some rudimentary coding notion to create to main loop script.

I plan to release a tool helping to generate the main loop system with a more friendly GUI in future version, that will need a more accurate comunication system (TCP side)

Raspberry PI, the system heart

The Raspberry Pi is a series of small single-board computers developed in the United Kingdom by the Raspberry Pi Foundation.

https://en.wikipedia.org/wiki/Raspberry_Pi

A full linux support computer with input / output capabilities.

First generation release in 2013 was built around ARM V6 32 bits CPU at 700 Mhz and 512 MB RAM (version B1+). I was able to create lot's of instrument and i never have been blocked by hardware resources.

Today, the last generation (V3), with a quad core at 1.2 Ghz CPU, with 4 USB port, 1 Gb RAM and RJ 45 Port (version 3B). There is actually one limitation that cannot be cross. Major problem is linked to the hardware itself and the addressing system on I2C device. That will be discuss later.

In addition, the Raspberry is provided with a 40 GPIO connector, opening to the world all the Input / Ouput / buses of the computer.

The FG Interface is built around the I2C bus. On generation 3, Raspberry PI has 2 I2C buses, but one is reserved for the camera connector and is difficult to open.

I2C Bus

I²C (Inter-Integrated Circuit), pronounced I-squared-C or I-two-C, is a multi-master, multi-slave, packet switched, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors).

I2C Bus

Why this bus ?

  • 1°) Well, i didn't start coding the interface before having a look on what hardware was available. And fact is that most hardware drivers are all using I2C. Or more simply, all device and devices drivers needed to manage a full cockpit can be found with an I2C port comunication.
  • 2°) All standard hardware devices have their own low level library available, most of them can be found for example on adafruit

I2C Devices & Limittation

As has already been said, there is a material limitation which can not correspond to the actual state of development. On the I2C buses, each driver device (chip) is known by its address. A standard device available on all electronic component websites for I / O (chip MCP23016) has 16 I / O and a physical address coded on 3 bits ..... Consequently, there can be only 8 This type on the bus. The range of address for the MCP23017 ranges from 0x20 to 0x27, which brings us to a maximum of 128 input or output or even an input / output mix, but the maximum will always be 128 with this type of driver. I talked earlier about the 256 output, because I use in the interface another driver device, the HT16K33, which is perfect for managing LEDs or display segments but this type of d The device has its address range between 0x70 and 0x77. Same thing with the pilot device for the servo motor, this type of element has its own control device on ranges with different address than the others

Python

Python is a widely used high-level programming language for general-purpose programming, created by Guido van Rossum and first released in 1991. An interpreted language, Python has a design philosophy which emphasizes code readability (notably using whitespace indentation to delimit code blocks rather than curly brackets or keywords), and a syntax which allows programmers to express concepts in fewer lines of code than possible in languages such as C++ or Java.[22][23] The language provides constructs intended to enable writing clear programs on both a small and large scale.

https://en.wikipedia.org/wiki/Python_(programming_language)

Why Python?

  • 1°) Well, when looking at how i could comunicate with the sim, i found the python telnet class in the Flightgear sources.
  • 2°) Python is the official programming language on Raspberry, and lot's of device driver lib are available in this language.

On other language more 'pro', as like C or C++, libraries are existing too, but it was not in my knowlegde ... maybe some day i will port te interface in theese languages.

Comunication

Au début, je jouais avec le client telnet et l'arborescence des propriétés via une connexion TCP / IP. La framboise possède un port RJ 45. Il apparaît rapidement que le protocole telnet n'était pas asser rapide pour gérer une grande quantité de données.

At first I was playing with the telnet client and the properties tree via a TCP / IP connection. Raspberry has an RJ 45 port. It quickly appears that the telnet protocol was not asser fast to handle a large amount of data.
By further examining Flightgear, I finally found the section of the Generic Protocol, and how to set up an appropriate communication system on the flightgear side. A server or client, based on the communication header, is created on the Flightgear side.

So one of the main part of the FG Interface is a full TCP client / server system dedicated to comunicate with flightgear. This mean it's possible to have more than one interface connected to the same simulator instance, so if generic I/O are limitted on one interface, with more interface, you will have more capabilities

At the actual project state, inter comunication between interfaces is not available

Project Status

system

  • Format Configuration File Done Done
  • I2C Protocol low layer wrapper libraryDone Done
  • I2C MCP23017 low layer wrapper libraryDone Done
  • I2C HT16K33 low layer wrapper libraryDone Done
  • FGInt TCP Server 80}% completed

library

  • Switches Library (Multi switches type class) Done Done
  • Switches Light Library Done Done
  • Segment Displays Library Done Done
  • Rotary Encoder Library Done Done
  • Servo library 30}% completed

add-on

  • A320 / 330 Airbus FCU add on Done Done

hadrware

  • Schemas Done Done
  • PCB 90}% completed