I spent the last few weeks updating my QtAgOpenGPS code to track the latest released (not the unreleased version 4, yet) AOG. As part of that I finally finished converting all the OpenGL code to use pipeline calls, which means it’s now compatible with OpenGL ES, which is what most ARM-based systems, including Android, use. Like before, the GUI is not there, which severely limits the usefulness of QtAOG, but Muhktamir from S. Korea is wanting to work on that a bit.
In the meantime, for kicks and giggles I compiled it for Android this evening, and it works on my phone and tablet.
The interface is too small for a phone screen, obviously, but theoretically could be adapted.
But don’t anyone get hopes up. Even with a working GUI, QtAOG is not currently well-suited for android. That’s because Android needs some special treatment for doing lifecycle control, and running in the background. Right now any time you go away from QtAOG (or the screen shuts off), it just suspends. I’m not sure Qt can actually do things like background running at all, actually.
And the interface is obviously not fully touch-enabled, although QML makes it fairly trivial to build that. Bluetooth would be the only I/O, although I think USB-OTG would be possible. Devices like the Teensy can be programmed to be a custom USB device that could interface with hardware.
Anyway, it was just for fun, really. And worth exploring in the future.
Yeah it’s probably time to change the name! Probably should drop the Qt part of it also. I’d like something that lets people know this is based on AOG, since 99% of the code is yours still. Any ideas of names that don’t start with Qt?
I have maybe another week of time to allocate to this and then I’ll have to let it sit for a few months.
By the way, OpenGL ES also does not support GL_QUADS. But I found that if I ordered the vertices a certain way, GL_TRIANGLE_STRIP worked fine to do the same job. DrawSky() used GL_TRIANGLE_STRIP to draw the quad, so I used that same technique. top left, top right, bottom left, bottom right.
Okay so here’s a demo anyone can install on an ARM android phone or tablet. It prefines a small field boundary, and has an AB line predefined at 5 degrees. With the simulator driving, autosteer works on that AB line, and manual UTurn works. Also section control is working, and boundary shutoff seems to work.
You’ll have to configure your device to allow installing apps from untrusted sources.
Also the github source is updated on my repo, and should build and run on any platform supported by Qt. So far only tested Linux, Windows, and Android.
Nice. Controls are a little small for the phone screen. Could be made to adjust sizes better. That’s a future plan. Although like I said before this is more of a novelty at this stage. Could be useful in the future though.
That’s good to hear that it runs smooth. The way qt does graphics, all the graphics are done in their own CPU thread. All the section and auto steer calculations are in the overactive thread. So I noticed on a very slow virtual machine that if that takes to long it won’t affect the drawing but it will cause section control to have problems. Kind of interesting.
I’d be happy if AOG just sat still for a year so I could catch up!
If you’re going to move to shaders, you might want to just support OpenGL ES. It’s supported everywhere and has everything you need for AOG, with the right shaders. Feel free to steal my simple shaders. I barely understand them but they do the job. They duplicate all the current stuff like drawing multiple vertices with multiple colors (used for various dots and also for the color fan on vehicle drawing), drawing with a single color, and then texture drawing and coloring a texture.
I do have a simplistic understanding of shaders and know the theory but they are still a bit like magic to me.
One thing I haven’t figured out yet is how to do dotted lines with shaders. I know there’s a way but it might be a bit more complex.
I wrote some simple wrappers and helper that give a more immediate-mode-style interface to work with, so it didn’t take very much at all to convert the immediate calls to use my wrappers. There are some things I tried to take more advantage of pipeline rendering, though. For example, the world surface and grid lines are only recreated when the zoom changes or when the CheckZoomWorldGrid() determines that the grid lines need to be recomputed. In other words the GPU hangs onto those vertices in a buffer and redraws them on command without having to push the data over. Was a good way to learn anyway.
Hey but look what you’ve done for thousands of people all over the world. And probably more in Canada then you realize! This coming release is going to make it spread even faster. So good thing you didn’t stop before v4. I still can hardly believe what you’ve done! Thanks
Well, AOG v4 has many interesting features, so I think the best idea is to merge Qt GUI into the mainline AOG.
But I understand that do this is not so easy, but maybe sometimes.
I am planning to rename my Qt C++ port to make it clearer that this is not just a different GUI for AOG. It’s a complete re-implementation of AOG in C++, compatible (ideally) with all the saved fields and vehicles, and hardware as AOG. While it’s true that 99% of the non-GUI code in QtAOG is identical to Brian’s code, it has been translated to C++. So it’s not possible to simply “merge” them. Currently QtAOG has all of the non-GUI code needed to do nearly everything AOG does, including AB Lines, U turns, Section control, Curved lines, contours, boundaries, geofences and headland control (automatic u-turns and hydraulic control). The big issue though is that QtAOG’s actual GUI is largely not present yet, but it’s something we’ll bring up to feature parity over the summer I hope, once I’ve completed the backend support methods and functions that the GUI will call.
Brian is the driving force behind AOG, and his tool of choice is C#, which allows him to rapidly develop new ideas and features. Thus AOG will continue to be be based on .NET. .NET is truly portable these days and the only thing that prevents AOG from running on all platforms natively, including iOS and Android, is WinForms. Brian has spoken of a distant future rewrite of AOG, and perhaps at that time a UI system like Xamarin.Forms or Avalon would be the way to go.
Also let’s not forget Christian’s work on QtOpenGuidance, which is taking the ideas and algorithms from AOG and implementing them in a clean, fresh architecture. There are times when it’s a good to take everything learned so far and start from a clean slate, which is what he’s done. I’m hoping to get it building on my workstation this week and have a good look.
Well it’s been a while since i did some work on AOG using linux with mono instead off wine.
See this old threat One major hurdle back then was the openGL stuff miscalculating.
From what i understand the first post: openGL ES is now working. Would mono still be a option to get around the GUI stuff then?
AOG uses immediate-mode OpenGL, and is not compatible with hardware that only supports OpenGL ES. Brian stated that in the future, he may consider moving from immediate-mode OpenGL calls to pipeline calls, which would be compatible with OpenGL ES.
For my Qt port, since my targets include SBCs like the Raspberry Pi, I had to rewrite the drawing code to Open GL ES -style calls. It turned out that it wasn’t that difficult to convert the drawing code, so if someone wanted to attempt it with AOG, I’m sure that would be welcomed.
With .NET core being pushed by Microsoft as the present and future of .NET, I’m unsure of where Mono stands. I don’t see much development happening on it, as focus has shifted to the already portable .NET core. Mono’s WinForms implementation is incomplete (since a full WinForms requires a full Win32 API, like Wine) and hasn’t seen any development in a long time. So I don’t know!
