58 replies to this topic

[dwillis]

I've started having a look at the practicalities of building GCS for Android using Necessitas. This is a tweaked version of Qt Creator that's been modified to use the android sdk and ndk along with android lighthouse/Qt4.8. Necessitas' installer installs everything needed including the android sdk/ndk, android port of Qt4.8 and Qt Creator and the arm v5 and v7a toolchains.

So far I've got a build environment that requires some manual intervention. We currently need a build step that creates the uavobjectgenerator to generate synthetic uavobjects that are then used to regenerate the openpilotgcs make files. This presents a problem for cross compilation as we need uavobjectgenerator to be built for the host platform, not the target. I've yet to work out how to do this automatically so I currently need to build uavobjectgenerator on linux and copy it to my android build directory.

Currently it builds as far as OpenGL stuff in cachedsvgitem so currently I've a way to go yet. I notice that necessitas comes up in this thread and wonder if anyone else has managed to get this working more recently. I should point out that I've only tried this in Qt Creator, not the stand alone makefile...

[Brian]

It looks like I got about as far as you before I git sidetracked.  It would be great if we could get this working.  When I tried getting it to compile it seemed like Necessitas still had a ways to go.  Hopefully it's in better shape now.

Good luck!

[Reddog]

When I checked out Necessitas I also noticed there was another QT port to android that may have been more advanced in certain areas, its callled grym-android-lighthouse

[dwillis]

For anyone interested, I've made a wee bit of progress. I've #ifdef'd out glc_lib and the sdl joystick stuff. A few other #ifdefs else where and I've now got to a point where it fails building the rawhid plugin. So far I've not had a chance to work out what this is for so I don't know if I should drop it from an android build or not. I'm guessing that the android ndk doesn't have any USB support. Anyway, it's bedtime now, hopefully I can get this to build completely tomorrow...

Edited by dwillis, 28 December 2011 - 12:18 AM.

[naiiawah]

dwillis, on 28 December 2011 - 12:17 AM, said:

For anyone interested, I've made a wee bit of progress. I've #ifdef'd out glc_lib and the sdl joystick stuff. A few other #ifdefs else where and I've now got to a point where it fails building the rawhid plugin. So far I've not had a chance to work out what this is for so I don't know if I should drop it from an android build or not. I'm guessing that the android ndk doesn't have any USB support. Anyway, it's bedtime now, hopefully I can get this to build completely tomorrow...

Actually, I'm betting the latest versions of the NDK do have USB support (as well as the JNI side).  See: http://developer.and.../usb/index.html

On the rawhid, (this is a guess, didn't chase it down in the code right now) that is probably the raw Human Intf. Driver (HID) that GCS uses to talk to the fw on the board with.  Other than on a tablet with USB (Acer Iconia & a couple others), you are going to be talking via BlueTooth, so as a temporary measure, you could probably turn it off.  Those of us with the Iconias (me ) would like to see the HID support turned on eventually.

[dwillis]

OK, I can compile that out for now and add it to the list of stuff to go back to...

[dwillis]

Here's a wee hint of where I've got to so far:

 GCS_Android_Deployed.png   51.09K   21 downloads

This is the GCS app installed in an android 3.2 emulator. Sadly it currently doesn't run as the deployment is missing bits...

Edited by dwillis, 29 December 2011 - 01:02 AM.

[dwillis]

Right, this now actually runs in the emulator. Currently the necessitas application loader is passing a '-platform android' parameter to GCS which is causing it to write the help text to the console and exit. Once that's sorted, hopefully I'll have something that actually works, minus a few bits...

[dwillis]

Using a horrible dirty hack, I've temporarily got round the application parameter issue. I'm now at the point where I should be able to load the core plugin if I can get its pluginspec file out of the application's apk file. I think I now have sufficient information on how to do this so hopefully I'll have something running soon...

[dwillis]

Hmm, sort of running now: core plugin loads (no attempt to load anything else) but nothing to see but OpenGL ES API errors on the debug console. Currently using a hard coded Core.pluginspec location; still need code to find pluginspec files. Also need to fix up OpenGL stuff in core plugin...

[dankers]

The core plugin needs a big review, it was done at the start of the project and there is still a lot of cruft in it that is no needed. Just in case you come across a lot of stuff that makes no sense at all, consider removing it and testing if the GCS still works.

I am also working with Trevor and Mike to help you make this port much easier regarding the UI.

[dwillis]

I'll be looking at this over the next few days. I'm also wondering if I should wait for a qml interface to be developed or maybe write a basic one as a proof of concept. Getting this running so far has taken a lot of dirty hacks which I can work on fixing properly...

[dwillis]

Still plugging away at this. Now working on trying to get a basic 'Hello World' style gui in QML for the coreplugin. I'm still missing libraries from the deployment but that's an easy fix. Hopefully tomorrow I can get it to display something other than a blank screen on the android emulator...

[Dmytro]

I tried to implement a QML based plugin, it's not finished yet but I hope to push the initial version soon for review (more as a proof of concept, far from final). I played with PFD svg file, but only on desktop, it's worth to combine the efforts for android version.

[dwillis]

At last: I've got the core plugin to display something on my phone. Extremely basic "Hello World" qml but at least it shows that GCS will load a plugin and display a qml GUI on android. Still can't get it to work on the emulator though... Looks like all the right bits are in place, just need to wire them all together. Anyway, rubbish screenshot below:
 SC20120210-211226.png   29.5K   11 downloads
Doesn't look like much but I'm happy and it's QML loaded by the core plugin.

[Dmytro]

You may be interested to have a look at the GCS_QML_Dmytro branch and http://git.openpilot...ru/OPReview-167 review request, I have an initial implementation of UAVObjects - QML context direct bindings.

I also attached the test.qml file to the review request with an example how the binding used.

[dwillis]

Thanks for the pointer, I'll have a look at that next. I've not got as far as working out the bindings side yet...

[dwillis]

Dmytro, here's a screen shot of your Welcome Plugin running on my Galaxy S. Still needs a bit of work on the core plugin to get this to work properly and the Qt menus are decidedly non-Android. I also suspect that a phone screen might be a bit too small.

 SC20120220-230914.png   84.01K   15 downloads

As a proof of concept, I think this isn't bad...

[dankers]

Nice! Really fantastic progress.

The big motivation behind QML for us is android, here's the plan as I hope you see it

1. A separate and stripped down core plugin for android, no menubar and load of stuff can go like the tool bar as well. It can be stripped back to the bare essentials really. The Android core will also have to support slide to change screens also but also have a way of locking them from this.

2. We really need to share as many plugins as we can and to do this, I need to convert the desktop ones to QML, Android should only need new QML if we get this right.  Welcome is the test case as this is pure QML already and it is your work why we rushed this. The physical home button should always return to the welcome screen if a device has one as that is where the different screens are selected, especially on screens where sliding to change screens is locked.

Right now we have Welcome and a base Gadget called QMLView that are QML, QMLView is not yet used in the desktop GCS but it will soon when Dmytro gets back from his travels. Currently a Android GCS can be completed to 80% if we start using pure QML with that one Gadgets based off that one, we also having all the UAVOs accessible from QML already thanks to a change by Dymtro.  Best to combine that work with moving the applicable Gadgets to QML to save double lifting really, I am trying to find some time to do some of this.

I will ask Steve for a new graphic design for the android home page, can you give me screen dimensions? Is there a way to change QML based on screen rotation or size yet in necessitas (this would be important for example for tablets also).

[dwillis]

dankers, on 21 February 2012 - 03:50 AM, said:

1. A separate and stripped down core plugin for android, no menubar and load of stuff can go like the tool bar as well. It can be stripped back to the bare essentials really. The Android core will also have to support slide to change screens also but also have a way of locking them from this.

I didn't take out much to get this to work. I'm just #ifdefing bits out as I go. I'll have a look at gesture handling and have a go at prototyping a slide-to-change pager. This should result in a replacement for the mode stack tab control.

dankers, on 21 February 2012 - 03:50 AM, said:

2. We really need to share as many plugins as we can and to do this, I need to convert the desktop ones to QML, Android should only need new QML if we get this right.  Welcome is the test case as this is pure QML already and it is your work why we rushed this. The physical home button should always return to the welcome screen if a device has one as that is where the different screens are selected, especially on screens where sliding to change screens is locked.

I wondered if the back button should return to the welcome screen leaving the home button to return to the actual device home screen.

dankers, on 21 February 2012 - 03:50 AM, said:

I will ask Steve for a new graphic design for the android home page, can you give me screen dimensions? Is there a way to change QML based on screen rotation or size yet in necessitas (this would be important for example for tablets also).

The Galaxy S screen is 480x800 (4"). I assume it should be possible to change the QML based on orientation. Apparently rotation sends resize events so that could be used to tweak the appropriate properties of each component.