Silas Parker

Pedals and gear sticks for computer games are quite expensive, so I made my own out of some scrap wood offcuts, rubber bands, string, an old screwdriver, a Teensy 3 micro-controller and potentiometers.

They work with any game that supports a normal USB joystick by using the Teensy 3 in joystick mode.

Driving Pedals

6 Speed Gear Stick

The Teensy 3 is very good for this project as it takes care of all the USB communication and provides a simple API to send the data.

The devices I built do have a number of short-comings: the peddles pivot on the potentiometers which are weak, the gear stick is sometimes unreliable at shifting if it doesn't make contact.

The upside is that it only cost the price of the Teensy (£21) and three potentiometers (£1.50). Rather than £150 for a commercial set.

If making your own set, when programming the micro-controller, you can compensate for some of the unreliability of the hardware in software. The pedals gave a much smoother response when I added took a five point moving average of the samples. The gear stick is de-bounced in software using the Arduino Bounce library.

The game Euro Truck Simulator 2 (ETS2) has a telemetry API to allow plugins access to the data about the in-game vehicle. I've created a plugin to send the data down a serial port to an Arduino microprocessor, which then controls the servos, LEDs and an LCD screen.

This initial prototype is made from cardboard, with the components just pushed through from the back.

This is the back of the dashboard, showing the Arduino board (blue) connected to the other components.

These are the steps I went through to build Qt 4.8 for Embedded Linux for the Raspberry Pi.

Build a cross compiler

Follow the instructions on using CrossTool-NG. I used the latest version of CT-NG and chose the GCC, Binutils and Kernel Headers to match the tools on the RasPi. I also had to adjust the compiler support libraries to match, via a process of build, change versions, build, etc. It is also important to enable C++ under language support, as by default only the C compiler is built. Once you have built a cross compiler, I strongly recommend testing it by compiling a test program such as:

fatal error: .pch/release-shared-emb-arm/QtGui: No such file or directory

This can be fixed by running:

touch src/gui/.pch/release-shared-emb-arm/QtGui

Error message whilst compiling SerializedScriptValue.o This can be fixed by going in to the directory where it is building (src/3rdparty/webkit/Source/WebCore) and re-running the failed call to g++ but with the -O2 flag changed to -O1

Once it has built, you can copy the /opt/raspi directory on to the RasPi, make sure you put it in the same place.

Testing

On the RasPi, before running the demo programs, you need to set the keyboard driver to use with:

I heard about libcloud on the podcast FLOSS 181, it makes it easy to access cloud things from Python. This example code lists all the file objects in all containers, to use this you will need to modify the API_ constants to your account.

You may want to create a wrapper class around the QStringList so that modifications can trigger the signals that other classes listen for.

QMutex and QWaitCondition

You can use the Qt thread synchronisation classes QMutex and QWaitCondition to do the classic manual synchronisation like you have done previously. When using QMutex, the QMutexLocker is useful for scope lock and release of a QMutex.

Your application should have a single QNetworkAccessManager that all code uses, don't create one for every call, create one in main and pass that to where it is needed.

You need to delete QNetworkReply using deleteLater as explained in the manual.

Creating another event loop in a function is generally not a good idea. Create a slot on the class httpManager connected to the QNetworkAccessManager::finished(QNetworkReply * reply) signal, read the reply and call deleteLater from here.

To do this you need to use the QWebFrame::evaluateJavaScript function to run a bit of JavaScript (JS) in the page. Most plugins can be scripted using JS, so you just need to write snippets of JS to trigger the functions.

Built in release mode - in PRO file you have CONFIG += release so this should be okay, you may also want to add a CONFIG -= debug debug_and_release line, just to be sure

If using MSVC - Linked against the release version of the C library (/MD) not debug (/MDd)

You are deploying the release version of Qt DLLs (QtCore4.dll) not debug with a d at the end (QtCored4.dll)

You are deploying the correct DLLs for your compiler - the Qt that comes with GCC included will have two versions of the DLLs, ones built with GCC that your program will link against, and ones built with MSVC that the pre-built tools (like qmake) will link against.

If using MSVC, that you have all service packs and updates installed, and that the MSVC re-distributable you ship matches the compiler exactly.

This is quite tricky to get correct, if I've missed something, let me know.

The QAudioProbe class allows you to monitor audio being played or recorded.

As the QMediaPlayer is a subclass of QMediaObject, you attach the QAudioProbe to the QMediaPlayer with bool QAudioProbe::setSource(QMediaObject* source), then connect to the void QAudioProbe::audioBufferProbed(const QAudioBuffer& buffer) signal. The documentation provides an example.

I think you will need to use private Qt classes to do this. This is generally not a good idea as the interfaces are internal and subject to change.

In the Qt (4.8.4) sources \src\gui\text\qcssparser_p.h header the QCss namespace is declared.

Whilst I haven't tried this, it looks like you will need to create a QCss::Parser, call parse to get a QCss::StyleSheet. This object contains the parsed data including a vector of QCss::StyleRule which matches QCss::Selector and QCss::Declaration together, have a look at the comment above the QCss::Declaration to see how it is all broken down.

Final Warning: Using Qt private interfaces is liable to cause maintenance problems - don't do it without a very good reason.

You should just be able to write a wrapper library with a C interface, that calls the C++ library.

The key here is using extern "C" when building as C++ to ensure the C++ parts call the C functions as C and not C++.

The SD header is more complicated to wrap than, for example, Serial.h as you need to return and wrap the File objects as well. This can be done using a struct declaration in the header, with the real type defined in the .cpp . By working only with pointers to this type in the header, you don't need to define the struct at this point. You could alternatively use void* pointers, but I would avoid this as you loose type safety.

The method above is the generic way to wrap things, in your case you could, for example simplify things and only allow a single file to be opened at once, as the SD.h library only allows one open at once.

Having 3 different types of parser was decided to be too complicated, so with the move to Qt 5 the XML module has been deprecated and the recommended parser is now QXmlStreamReader. This is quite an easy parser to use (unlike QXmlSimpleReader), but has far lower memory use than QDomDocument.

Therefore, if you are writing new code in Qt for XML parsing, even if you aren't currently using Qt 5, I would strongly recommend using QXmlStreamReader.

Unfortunately for you, the manual page notes:

QXmlStreamReader is a well-formed XML 1.0 parser that does not include external parsed entities.

This means, it doesn't resolve your SYSTEM entities. Also, after inspecting the source code, it doesn't look like there are any 'hidden' hooks or methods you can use to intercept the entity resolution.

If you want to include external XML documents into another document, you may want to look at using XInclude. It would be reasonably simple to write an XInclude processor using QXmlStreamReader and QXmlStreamWriter.

Here is a basic Qt XInclude processor I wrote, it only does one level of include, but I'm sure you could extend it to support recursive inclusion reasonably easily.

Once you have a fully resolved XML document, you should be able to use the QXmlSchemaValidator to validate it.

Take a look at Graphviz, this is a suite of graph layout tools and libraries and it used by many other programs for drawing graphs such as Doxygen and KCacheGrind.

You can use it either as a library, to link against; or write out a file, call the executable to process it and read the file back in. This second (file write/process/read) method is the most commonly used.

To do this you:

Write out the graph (your FSM) in dot format (a simple text format).

Call dot (one of the graphviz tools) with the output format as dot, this will append the layout information to the file

Read the dot file back in and use the position information

There are several libraries for doing this including for Python, see pydot.

@astre I don't think there is any way to control the signal rate. You could create a proxy class that would do this to batch several signals together. Alternatively, you may want to do the FFT in another thread, for example use QtConcurrent::run to run the FFT and use a QFutureWatcher in the GUI to get the results to display them.

I can't see any functions for doing what you want. Consider posting a question about what you want to achieve more generally to see if there is a different solution. It is often best to leave the Qt Meta system alone unless there is no other way of doing things.

I think you would need to create a Firefox Plugin that registered as a feed handler (see Adding feed readers to Firefox). The plugin would then notify your application of the new feed, for example by launching it (or a helper app) with specific command line parameters. I don't know enough details to write a proper answer I'm afraid.

@LaszloPapp The QByteArray is not needless, see How can I convert a QString to char* and vice versa?, particularly the line "it is necessary to store the bytearray before you call data() on it". Use of qPrintable is valid, but you have to be careful to never store the return value.