Car Dashboard Project

It’s been quite a long time since I’ve posted here. To tell the truth I’ve been quite busy lately, and lazy when not busy. That doesn’t mean however that I’ve stopped hacking, or discovering new things though.

At the beginning of the year, reading PlanetQt, I discovered the Automon Project
Based on Qt, it allows you to monitor various sensors from your car using the ODB II interface.

In parallel, I’ve been doing a bit of electronics with an Arduino and learned about a new board the UDOO which basically is an Arduino embedded on a 4 core Arm board.

In addition to that, I’ve made a XBMC remote in Qt/QtQuick2 which allows you to nicely go through your media libraries, launch medias on your XBMC server and (in some mesure at the moment) play them on your device.
SmoothRemote
It works on Linux and Android at the moment.

All those things seem unrelated at first but as a side project, I’m also in the process of restoring / improving a car. Thinking about how easy it is to retrieve sensors’ data with an Arduino, how easy it is to make nice UI with QtQuick and how powerful embedded boards are becoming, I though why not recreate my car dashboard.

Using a UDOO with a Qt Yocto operating system, it could have a screen with gauges instead of regular analog gauges. As for the central dashboard. Why not, remove everything and keep a large touchscreen there. XBMC could be installed on the UDOO and, the remote would act as a frontend for it. Or I could just rewrite a complete media player with QtMultimedia.

I’ve already started making some gauges in QtQuick. Keep in mind I’m not a UX designer. QtQuickCarGauges

I tried to make them as customizable as possible to adapt them to pretty much any kind of style or sensor.

Instead of making this alone, I believe if other people are interested that we could build something great together. I’ve already contacted Donal of Automon and he might be interested if some parts overlap with his project.

This could become the Open Dashboard Project.

This project could be divided in 3 parts regarding the software:

Sensor/Acquisition : Either based on Automon if Donal is ok with it or made from scratch. Acquisition of analog sensors and/or ODB interfaced sensors.

Gauges : Speedometer, tachometer, oil pressure, engine temperature …

Entertainement System : Media player, Maps, Reverse Camera – Radar, day and night lighting, air conditionning …

As for the hardware, any platform capable of running Qt with OpenGL 2 support should be fine. The UDOO looks quite interesting but other board could work. The advantage of the UDOO being having easy access to the GPIOs and being able to have things run independently on the Arduino, not interfering with the rest of the system. Maybe using Android as an operating system on the UDOO could also be something to think about.

The only issue that I see at the moment, is having a protected voltage source in the car. I’ve already started looking through that. Basically it needs protections against :

Transient voltage spike

Reverse polarity

Dump load

A circuit based on a LM2917 or LM2678 for voltage regulation and protected by a RBO-40 would do the job but I’m no expert either. Also, in case of sudden voltage drop (cold winter engine start), the system should either shutdown quickly or stay alive thanks to some kind a battery or capacitor.

Anyway, there is plenty to do, on many different aspects so if anyone is interested in working on that project, please let me know. I’m open to ideas and the goal is just
to have fun and possibly produce something that can compete with 5000$ car systems for 500$.

Using a LeapMotion for Qt inputs

We are still working on our project Tepee3D and although we have not yet reached the popularity we hoped too, this project has allowed us to work on many interesting aspects, one of which is adding LeapMotion inputs to our application.
For those of you who don’t know what a LeapMotion is, it is a small sensor about the size of a lighter that you can use to track hands movement in space.
You can find more information about it on the LeapMotion web site.

Leap Motion (Photo credit: khawkins04)

There are several ways to interact with an application using the LeapMotion sensor. However as Tepee3D has mainly been focused on touch and multitouch inputs, one simple way to use the LeapMotion was to convert fingers 3D position in Qt touch points so that they could then be used in QTouchEvent or QMouseEvents without having to rewrite the entire application.

For the specific gestures (swipe, circle, screentap, keytap) offered by the Leap SDK, creating a custom QtQuick/QWidget element that will handle these is a clean way to include the additional inputs of the LeapMotion without compromising touch and mouse inputs on platforms that do not have access to a LeapMotion.

Though originally developed for Tepee3D, this library is made to work with any Qt/QtQuick application.

Those not interested by the code explanation below, you can directly obtain the sources and a sample project here.

Building a remote compilation service for various Qt targets

Targeting many platforms with the same code base is the reason why many of us choose to use Qt. In the Tepee3D project, we would like to attract people to develop widgets using Qt and Qml. Currently, Tepee3D runs on 8 platforms and asking developers to compile their widgets for each of these platforms would be a lot of troubles. In case a new platform is added, they would have to find a way to either crosscompile Qt for that platform or have a dedicated system for it on which to compile it.

On the other hand, building a remote compilation service where developers can request their widget to be build on a given platform would solve that issue. Using Jenkins would be a solution but setting up a dedicated queueing system where build requests can be distributed to nodes that are configured to build a given platform wouldn’t be much harder.

Deploying Qt Applications on Linux and Windows

One of Qt’s greatest strength is also one of its major weakness. The code once deploy everywhere motto is nice when coding but once you reach the deployment step, it gets a whole different meaning.

As we are getting ready for the alpha release of Tepee3D (and almost a week late), I thought I’d post about what made us lose time.

Before creating installers for each of the platforms you are targeting, you have to run your application without the whole Qt environment on each of those.

There are two ways two proceed, either by compiling Qt statically against your executable or by delivering the necessary Qt libraries with your application.

Simple rules to make your development stay on track

Do not try to gain time by using a weak design.

Always consider the modular and generic design over the one piece specialized one.

Always think twice about what your code can’t handle before starting.

Appearance should always be good as it is the first thing users will see.

You’ll always figure out you can’t do something after having coded the most part so think some more!

The power of qobject_cast

One feature we wanted to implement in Tepee3D was a Services Manager that would allow various classes to interact with Services provided through shared libraries. Those services are axed toward database management, web services access and platform specific interactions such as posting notifications on Android and so on. That mechanism allows us to add new features during the course of the developement without having to modify the main application’s structure or void any previous work.

A practical case : exposing Qt C++ Models to Qml

When it comes to manipulating data within QtQuick, exposing a Qt C++ model is often a good path to take. It allows you to easily separate the logical part of your application from the UI. In addition your models can interact with a SQL database and be processed through some resources heavy filters while still reflecting the changes smoothly onto the UI. Shortly, it is a way of combining the best of both world, the power of C++ with the ease of presentation of QtQuick.

Qt3D Repeater and Loader bug – Part 2

In my previous post, I talked about an important issue encountered with Qt3D 2.0 that would not allow Item3D in Repeater or Loader element to be loaded by the rendering engine.

Before entering into the details of this bug solving, I’ll quickly explained how Qt3D is integrated with the new QtQuick 2.0 scenegraph.

Qt3D Repeater and Loader bug – Part 1

While developing Tepee3D, we encountered a few bugs with the Qt3D module. Of course this is not something surprising as it is rather new and not officially part of the Qt 5.0 release yet. However, when having tight deadlines, waiting for someone else to solve them is not something to consider, especially when these bugs stop you and your team from progressing on your tasks. Trying to solve them and contribute to an open source project is a better way to handle such situations.

Tepee3D

As an Epitech student, a part of our fourth and fifth years has to be spent developing an innovative idea. Along with some other students we gathered around thinking about various project ideas. At the time we were developing the Tepee project on our spare time. Tepee was a multi-platform application developed with Qt and QtQuick that aimed at providing users a same interface across various devices. With that interface, users were able to post notes, add appointments in a calendar, post and retrieve files from an ftp server, save and visit bookmarks with the integrated web browsers… In addition, all those data could be synced so that if you had added a new bookmark on your phone, you would also have it on your desktop the next time you used the application.