A software to do a GPS-based guidance of farming equipment. It uses a principle called "dataflow programming": basicaly this means every module of the software receives, modifies and then sends data. These modules are then connected in a meaningful way, so a calculation network does the job of transforming the input data (GPS, wheelangle, roll, heading...) to a 3D-view on the screen and finally outputs commmands for the equipment (steering commands, hitch, section control, etc).

As clearly in the file LICENSE stated (especialy Section 15 through 17), there are no guaranties of any kind. You're responsible to use the software responsibly. If you think, this software is fit to drive expensive equipment with potentialy deadly consequenses, that's you thing.

This software uses QT5 and Qt3D. Install them on your machine along with qtcreator. Open the project in qtcreator, change the buildtype to "Release" (the small screen-icon on the lower left), compile and run it (the green triangle). It is developed on linux, but should work on any platform supported by QT and Qt3D.

If you find an issue or a bug, report them on github.

It is possible to run this software without forking. So if you're not interested in making changes yourself, don't. A normal clone (not with the function "download ZIP") can be easily kept up-to-date with a periodical git pull. To keep a fork synchronised with the forked from repository, more work is needed. A downloaded ZIP lacks the nessesary data for git and cannot be actualised with git pull.

If you want to contribute to the project, there are some rules:

1. Fork it on github, send pull requests with a clear and compelling description
2. Good and complete commit descriptions, no "WIP"-commits without any hint what is changed
3. Have a plan what to change and what to achieve with it. Read and comprehend the existing code.
4. Coding style rules:
   • 2 spaces indentation, no tabs
   • Blocks are opened on the same line (pe. if(...) {)
   • spaces around operators and on the inside but not outside of parentheses
5. Meaningful and descriptive names. If you alter the meaning of a temporary variable, also change its name.
6. Generaly keep a dataflow-paradigm in the code: data comes in, gets altered/calculated and then gets sent to the next block
7. Use meaningful datatypes to exchange data; steerangle alone is ok, also Tile+Vector3D+QQuaterion for the position+orientation, as they are alone meaningless. But don't mash together logicaly different things like velocity + roll. Use seperate signals/slots, instead of one with all the data.
8. No global variables to exchange data, all data and config gets exchanged with signals and slots.
9. Keep things as local as possible, make as few globals as needed. When adding reused objects/variables, use the factories to pass a pointer to the blocks. Keep the factories in the same file as the block itself.
10. Use as much of QT as possible, especialy Vector3D, QQuaternion and Qt3d
11. You can add libraries, but it has to be as a git submodule and built together with QtOpenGuidance
12. Don't introduce platform-specific code, use the avaible QT-abstractions
13. QT and Qt3d are pretty performant, so no "optimized but unreadable" code (aka write-only code). Qtcreater has builtin support for profiling; implement new features clean and straightforward, profile and only optimize if needed. Saving RAM and storage space is pretty pointless on modern machines, saving cycles most of the time too. So generally: better implement new features instead of getting +1% more performance on codepaths, which are not critical.
14. This isn't a collection of proof of concepts, but a maintainable, usable and readable codebase for a RTK-based guidance. So keep your implementations readable, documanted and clean of premature optimitions.
15. Experiment in your own branches, don't break the master-branch or configfiles without a really compelling reason