Thanks for the info.
I tried with Qt6 and then with Qt5 but with no luck.
I will try it with visual studio.
There’s build instructions on the repo README.md in my settingsdavid fork now
PR submitted for it.
1 Like
Using the Qt installer, install the following only
- Qt5, but customize and only select Qt5 for Mingw32 (or if you have VS, Qt5 for VS2019). 64-bit is fine. Should only be about 500 MB.
- Qt Creator
You should then be able to open the QtAgOpenGPS.pro file with Qt Creator, configure it for the mingw32 kit (or VS2019 if you went that route). You can then build and run from inside Qt Creator.
If you want to run QtAgOpenGPS from outside of Qt Creator, that requires an additional step, from the commandline, to run Qt’s "qtwindeploy " app which will make sure all the DLLs and shared plugins the EXE needs end up in the same folder as the EXE. Without this qtwindeploy step, running the EXE will just result in an error since it cannot find the Qt dlls.
@torriem I just joined so I don’t have the trust level to DM, so instead I’m posting here.
I’m very happy to see QtAgOpenGPS making progress. The cheap hardware caused by Windows 11 system requirements was too good to pass up, so I was looking for options given the Win 10 EOL later this year. I’m a fan of Linux, so I considered the Wine path, but seeing updates to your project got me excited about it.
Qt seems to me like a really good way to get AgOpenGPS on multiple platforms, and I would like to contribute to the project if you have need of more people. I’m a Qt noob, but an embedded C++ veteran. Qt is a framework I’ve had the itch to dig into for many years, and this project could be a good excuse to do so. I also have quite a bit of CMake and related tooling experience if you’d like to convert the project to CMake, as that seems to be the direction Qt is headed.
I’m assuming you can DM me if you’d like to contact me.
To keep this post somewhat on topic, and because the issue is still open, here are some name ideas:
I’m not a huge fan of Libre in project names, but there have been quite a few open source projects using that instead of Open or Free. So maybe use the Libre prefix?
Another idea - wordplay on existing guidance software package name? e.g. less replaces more. Instead of FieldBee, maybe AgriWasp? AgriBug?
Another idea - a name based on an animal that is famous for it’s navigation abilities, like an albatross or monarch butterfly. OpenAlbatross? Maybe a portmanteau like Agritross?
1 Like
Somewhere I kept a list of possible names. But for now Brian doesn’t care that much about having AOG in the name, so we’ve not worried about changing the name just yet.
But we welcome your assistance on the c++ code! We just finished updating to Qt6 and we’re currently bringing the C++ code to match the features of AOG 6.2.0. Brian revamped how the autosteer lines are done in AOG and I’m adapting that code to C++. This development is happening in my oneline_uturn branch on github. This branch does not compile currently, but if you wanted to check things out, I have a branch called “settingsdavid” that does compile and run.
Awesome, I’ll take a look at settingdavid. I had both master and the qt6 branch running. I fixed an annoyance with the Display menu, mostly to have an excuse to poke at QML. I can make a PR if you’re interested.
Is development discussion and coordination happening somewhere? This thread doesn’t seem like the right place.
I sent you a DM. Let me know if you didn’t get it.
Oh and if you’ll send me your github username, I’ll check out your change. We’ve been using git to share instead of github, then pushing to github.
I’ll go git remote add tenteen [url] in the terminal, then git pull tenteen [branchName] then git push to my github.
So instead of your git branch → your github → my github → my git branch, the sequence is more like:
Your git → your github → my git → my github.
Saves us having to do much with github, and has worked well so far.
1 Like
There is no such thing as multiplatform. Its a terrible and timeconsuming work to make connections work on all platforms. The code is full with if and else.
Yes that’s often the case. But so far Qt has provided enough abstractions that we have only maybe one ifdef in the entire code base. Not too bad! Coming from a Unix background I’m quite used to the idea of portable programming, so I’m not too surprised Qt makes it work so well.
QtAOG does build and sort-of runs on Windows, Linux, and Android. x86 or ARM. Probably macOS too, but I’ve never tried it. So that’s pretty good. There are some android-specific things that will require a bit of ifs and elses, including dealing with different screen orientations and sizes, and dealing with the onscreen keyboard. But those are things Android developers have to deal with anyway, even if they use “native” tools. There will also be issues with the serial port on Android which will require platform-specific code when we get finally to AgIO, next winter.
Its working with the excellent GitHub - mik3y/usb-serial-for-android: Android USB host serial driver library for CDC, FTDI, Arduino and other devices.. Maybe you must add devices to the prober.
At the moment I’m testing an Expo/ReactNative version of AgIO.
Great work! That’s awesome!
1 Like
Will there be a version of AgIO in qt6? I need a way to get data from my GPS into the qt6 version of QtAoG running on Linux.
It is under development.
Yes. I have a qt cpp version of agio on my fork right now. It hasn’t yet been merged into @torriem s fork yet, and is very much still under development. It’s only CLI based right now, and really all that works is the UDP code… No USB, no NTRIP, no auto reconnect. If you lose UDP connection of any sort, you have to restart. But here it is if you want to try.
1 Like
I started working on the agio side a few weeks ago and it was actually my first attempt at CPP coding, other than some Arduino work awhile back, so definitely isn’t just easy coding!
1 Like
Some have been asking about QtAOG, so I thought I’d put a quick note on here… QtAgIO is very much alive. UDP and NTRIP at least halfway work. I had it steering our tractor for .5 km today. The process to get it going was rather long and complicated and involved sending the steer settings via AOG and then switching out to my mint OS laptop. And editing the .ini to set the correct WAS offset. And even then the tires steered too excessively to really be useable. But having it steer for that far did feel like an achievement!
QtAOG: There’s still a lot of little things that need to be finished. A few not totally necessary pages that need to be completely designed. Probably the most major is it’s still the old V5 pre tracks code. Tramlines and flags are non existent. Field, boundary, headland creation should all work. The line creator doesn’t exist. Youturn doesn’t work. Vehicle creation should work. I think all the vehicle settings work except for the WAS offset, and the Arduino steer settings. (When I say work, I mean that we can change in the UI and the.ini file changes. There’s still quite a few of the main buttons that don’t function yet.
Torriem is in the middle of harvest now, so he is busy right now. Come winter, I think we’ll catch up QtAOG with v6. However, I don’t have sufficient cpp knowledge to do that on my own.
QtAgIO: Thanks to @tenteen for creating the basics so I had something to work with! As of right now, the NTRIP, UDP, NMEA, and the scan reply code backend works. The frontend has the four main module indicators connected. And a button for setting the subnet. I haven’t gotten the settings connected to the frontend yet, so all the settings have to be set in the.ini.
So. Progress has been made. But I’m not fast, learning both CS and cpp as I go along.
I was going to keep this short, but I think I failed 
6 Likes
Well done!
1 Like
You know I always want to help.
I finally got decent build instructions for linux on my repo wiki here. If someone has an idea of how to improve, let me know, or add it. They include how to download QT6 from the internet, and follow to running QtAOG on a desktop to creating .apks on android.
I also got .apk’s created for both QtAOG and QtAgIO. They’re not really useful yet, but look kind of neat. Android use in the field has a ways to go yet. The two programs idea will have to go, or get seriously redone. Not being able to see both QtAOG and QtAGIO at the same time is a real pain. And we need the correct code to allow a program to run in the background. APKs are on google drive if anyone is interested. QtAOG Binaries. - Google Drive
For now, android isn’t really the main thrust. Debugging is a pain, so there’s no point in really trying to get it to work until QtAOG works well on a computer OS. Then we’ll focus more on android.
I’d like to hear from someone who has built QtAOG on windows! The build instructions should be fairly close to linux, but could vary slightly.
2 Likes