QtAgOpenGPS lives... and needs a new name

[torriem]

Since it’s cold and snowy outside again, thought I’d post a quick note to let anyone interested know that I’ve picked up work on QtAOG again. The hardest part is coming up with a name! I want to remove Qt from the name, and rename it so that people know it is based on AOG, but it is not AOG. f Any ideas are welcome. Too bad QOpenGuidance is taken!

User-interface-wise it still is virtually unchanged from before and mostly non-functional. However the core logic ported from AOG has been updated and is mostly in sync now with branch v4 of AOG, as of a couple of days ago. This means auto steer is working, U turn, dubins path planning, Stanley steering, and the basic simulator, so it can be played with at least. Also has the new section control logic. The only thing the UI lets you do right now is drive, turn on auto steer, you turn, and turn the sections on and off.

Does not have any code for serial ports or networking yet.

I tried to change as little as possible when porting the code. To make life easier in C++ I did remove all references to the main form in the Classes. Instead everything that’s needed is either passed in or retrieved from the application global settings store. I moved some variables to different classes, such as placing the array of sections inside the tool. Some of my moves I noticed Brian has already begun to do in AOG. There are lots of variables in AOG classes that mirrored the data stored in the Properties (settings), so I eliminated them which made things easier. Speed of retrieving data from the settings store doesn’t seem to be much different.

Currently I’m working on the file saving and loading methods. After that I’ll work on the methods and functions the GUI will need to do things like create AB lines, etc. Munhktamir from South Korea is doing some work on a GUI that hopefully can be attached later this summer.

I’ve got some time to spend on it while it’s still cold so we’ll see how far I get. I can only hope Brian will get good weather soon to finish his harvest and start planting, so he’ll be too busy to work on AOG and I can catch up again.

The code is at GitHub - torriem/QtAgOpenGPS: A Qt C++ port of BrianT's AgOpenGPS, in the csport branch, which I’ll merge back into the master at some point soon.

Currently compiles and runs on Linux, Windows, and Android, but should work on any Qt-supported platform that has some 3D support, equivalent to OpenGL ES 2.

[KolDon]

I am new to qt creator. I downloaded and started your project, but got an error
Failed to start the program. Is the path or rights invalid?
What am I doing wrong.

[torriem]

Hmm. My Russian is a bit rusty. What does it say? Did you try the csport branch or the master branch? Probably easier to cut and paste the error message rather than a screen shot.

EDIT: I did a google translate and yes it says it could not start the executable. Did it compile? Can you find the executable in finder? Can you run any other Qt samples? A simple hello world app compile and run?

[KolDon]

it was a master, now I tried cport and it’s even worse

[torriem]

Three errors isn’t bad!

Yeah I don’t have a Mac to test it on. Looks like an easy fix, though. Mac doesn’t have lround in the std namespace. I’ll push a change to CSPORT. Just remove the #ifdefs and only keep the line return lround(number);. That should work on all platforms.

[BrianTee_Admin]

Quagmire.

[KolDon]

everything worked out

I hope your code will bring some clarity to my project on porting AOG to Unity AOG Unity port for Android

[torriem]

Found a number of bugs caused by errors in my translation. Contour recording crashes on the current github commit because I neglected to notice that AOG had increased the size of the stepFixPts array, so I had memory corruption. Will push a fix for that soon. Fortunately there are very few places in my c++ code where memory corruption is possible, since nearly all data structures are using containers like lists and vectors.

Also my lookahead pixel distances don’t seem to be the same as AOG’s. I’m doing some deep comparative testing on that.

Finally, I must have a transcription error in the dubins code, as when the width gets smaller than the turn radius, I get a really odd second lobe to the path, instead of a nice hair-pin shape.

[torriem]

Pushed fixes for the first two issues, now tacking the dubins issue.

[BrianTee_Admin]

ooooohhh dubins. Shudder…

[Richardklasens_admin]

I think a good name idea is some like
FGA, FarmerGuidanceApp
OGA, OpenGuidanceApp
AOA, AgOpenApp
BTA, BrianTeeApp
MTG, MichaelTorriemApp
SGA, SpeedoGuidanceApp

[torriem]

OpenGuidance is already almost the same as Christian’s project, and I don’t want my name in the title. But I’ll think on the rest!

Certainly better names than the one I came with which was Guide-ee-McGuideFace.

[BrianTee_Admin]

Kitt
ArduMap
QtAg
FireStar
InFront
Tremble
Gormin
CovidMap
iMapNow

I personally like QtAg - pronounced “Cute Ag”

[svenn]

qtcreator7 and qt 5.15 on a debian laptop. I get black squares instead of the expected png icons. Any idea why?.

[torriem]

Is this Windows or a Linux distro? Usually a blank square means your system is missing a dll for handling PNG images, which would be highly unusual for Linux. Not sure about Windows; I would have though Qt5 on Windows came with everything it needed.

[svenn]

This is a linux distribution, haven’t tried with windows. It looks as if qtagopegps is the only place were I cannot see the png. I have been googling for solutions or similar problems and all I can find is that some color: “transparent” property should be set, but the iconbuttons in qtagopengps seems to predate most of the qt versions referred to in solutions.

[sonicpp]

Hi @torriem , whats your plan with QtAgOpenGPS? Its been some time you updated the code. I was using QtAgOpenGPS few times in the past (with changes you also merged), but now I am coming back and I am thinking about trying vanilla AgOpenGPS on Linux. since Qt version is quiet for some time. Where do you see the future of AgOpenGPS on Linux, Qt version, or original via Wine or Mono/dotnet?
Thanks for your work!

[torriem]

Good question! I would like to get back to the Qt code again but haven’t had any time to do that and won’t have time to do it this winter either.

Obviously the first priority is still to come up with a catchy name for the port.

While AOG does still run okay under wine with the official dotnet runtime installed, the problem there is that this is not a solution that works on ARM.

In an ideal unicorn world, at this point if AOG could transition away from WinForms to a cross-platform UI framework like Avalonia on dotNet Core, that would be enough. AOG would then run natively on any platform dot net core is on, which includes Linux on x86 and ARM, and also iOS and Android. AOG on Android would actually be a sweet spot. And Avalonia would get it there while remaining in C# and dot net.

[sonicpp]

That would be cool. Unfortunately I am not much familiar with C# neither Avalonia, so I dont feel there is much how I can help (but still I can try). It also depends how authors of AOG are open to rewriting UI to other framework.

Regarding Qt…its also question is how much effort does it take to keep C++/Qt code up to date with upstream C#/WinForms.

AgOpenGPS via Wine is far from perfect (going to write post to Wine thread here).

[torriem]

A change from WinForms to Avalonia (or something similar) is definitely not trivial. AOG’s structure is designed around how WinForms works, so changing UI would necessitate some change in the structure of AOG. So it’s not likely to happen. I kind of vascilate between wanting to continue QtAOG and wanting to work directly on AOG to make the GUI use Avalonia. I don’t know C# very well, and I have no experience with either WinForms or Avalonia however. Wouldn’t mind learning, but just can’t do it now.