Untangling the front end would be good (-> unit tests, easier for new people to dive in, reuse in my robot 
). Slapping a web (Angular/Node/React) interface on after that would be nice BUT
^ Yup, and I’m not optimistic about how much code can be reused easily (based on my little dabble fixing Linux/mono bugs a year ago). I haven’t checked QtOpenGuidance recently but that might even be a better starting point.
Thanks for the suggestion, I’ll give QtOpenGuidance a look
AOG has had the same autosteer board since the beginning and even though a lot of the software will change on the new version, the hardware remains all mostly the same. The only difference is mostly the imu part which is about finding better parts. But even that now can be its own module.
AOG will always be free, and inexpensive to build using good parts.
I used a program that used the chrome extensions to run the program and still used serial ports to communicate.
It was easy and always updated. Not sure anything like that is still available?
I think the web based is a great idea, but don’t need to change the hardware side, just make AOG available on more devices.
Hi,
I thinks it would be a great step forward if there was a way of using diffrent devices. However I am not sure if webbased aplications is the way to go.
I don’t really know what your plan here is but if you would for example run it on a server at home you will need a stable internet connection. And for some this may not be an option.
If you want to run the server localy you will still need to rewrite most of it to make it work on a rasbery.
I have been strugling with this idea as wel because it would take of a lot of the current limitations (decent and strong windows tablets are expensive compared to a rasbery)
But i would have opted to rewrite the program in a more suitable luanguage.
While keeping in mind the decoupling. But that would take a lot of time and planning. I was hoping on working on this myself, but i am afraid I wont have enough time.
then there is also the decision to be made of what luangage.
If you want it to run as fast and optimal as possible go with c++. However development time will go up
if you want to develop quickly and easy go with python. But this will give less chances to optimize the computings. However it’s very easy to learn and program in.
If there was someone to start something like this i may be interested to help. But i cannot promise to have time every week to do so.
there are several aspects to consider:
I’m no expert on software, so I won’t be a big help on that (only for hardware drivers perhaps), but what I can contribute is an adaptation of my PCB assembly into a PI4 hat. It would be much leaner and even more inexpensive due to the many possibilities the PI has out-of-the-box. Maybe around $25 including a power supply for the PI.
By the way: We have a guy here in the group (@joaquinperaza; more active in the Telegram group) who has a software running (!!) on a tablet, but AFAIK it’s not webbased. But of course it’s a “must” to collaborate with him as well as with @BrianTee_Admin of course!
I think is a good ide to use a android or ipad tablet, The windows tablet was hard to find when i build mine, and a computer was to big. But its a must to functionally even without internet connection.
I’d like to chime in here - I’ve been side-eying this for a while as my dad is starting the first steps in building out a system, but I’m too busy with school atm to interact meaningfully.
I think separating the business logic from the GUI is pretty much essential if we ever want to build out more inter-connected systems.
The main benefits in my opinion are:
All of this comes mostly at the cost of extra work - both from the rewrite and there is extra work in maintaining that interface layer between client and server, but I think that’s well worth it if there are enough people to take it on.
I would also generally recommend writing the backend in python. With a well organized python project, it’s quite trivial to replace any performance-sensitive code with an identical wrapper into a more performant language. Python is also quite easy to pick up and more performant than I think a lot of people give it credit for. I would ideally write it in a language with stronger typing (e.g. Rust), but that would increase the barrier of entry for contributing.
The frontend client could be written in any language, web apps have their benefit of not needing to be installed on the client machine, but then also you could write a more performant/responsive client with Qt and OpenGL.
Also I do really like the architecture of QtOpenGuidance, but it does seem to be quite tightly coupled to Qt, such that it would be fairly difficult to extract the business logic out of the GUI.
The embedded hardware would also not have to be changed in any way, we could simply re-implement the same communications methods (although I do have opinions about that - I believe a more structured protocol like UAVCAN would be a big improvement - that’s a different topic )
And to clear up a misconception I think a few people have: using a web-app GUI does not require an internet connection or any connection to external equipment. The server in this case would be the hardware running AgOpenGPS, and your client is whatever your using to view the GUI. The only network connection would be inside of the tractor, and in many cases the server and client would even be running on the same computer!
very good post!
by the way: when there’s some time left I dabble in transfering my AgOpenPCB into a Pi hat, so when someone is interested in driving this project he/she shall not hesitate to ask me for suitable hardware. Right now, I’m looking out for a good housing in order to have a professional look from the beginning.
Is it possible to receive a udp stream in a browser effectively?
the current version being worked on talks to AgIO via loopback udp, a separate application that interfaces to the real world of udp and serial. Been looking at WebGL, I think there is a possibility to do the whole thing (perhaps simplified version) run in a browser with AgIO then being written for other os’s. But since it is just networking and serial connections, not that hard.
Not really, no. The only networking you get in a web browser is based on websockets or http requests.
there seems to be a misunderstanding here. all realtime functions will stay on the Pi. It directly connects to the dual GNSS w/o any interfacing - just direct NMEA via UART. No jitter at all. Same is true for the motor/valve drivers, WAS ADC, etc. All necessary interfaces ship with the Pi!
The tablet or mobile phone (or both at the same time - you can display the field on the tablet and the buttons on the mobile phone e. g.!) provide the GUI and do the graphics calculations. No realtime communication is needed and only few data needs to be exchanged, so even REST would work.
No misunderstanding. Brian was speculating as to whether everything could be done in the browser with no backend server at all. It’s certainly within the realm of possibility except for the UDP stuff. But I agree keeping the heavy lifting on an embedded computer and using the browser for the UI is probably the better way.
the graphics needs a million times more atomic calculations than the steering, but steering needs real time. so each device should do, what it’s optimized for. this will keep the Pi cold as well…
And you can keep all the steering code and “just” 
put the C# stuff to the Pi.
Seems the gamers have already figured it out years ago, server could reside with AgIO. No need for the Pi. WebGL for graphics
is that answer really for me? I didn’t see any security issue yet. Wait - yes, my neighbour could remote-control me and let me plow his field! 
You sure can with teamviewer control a tractor from anywhere. Pretty cool
Im too cheap to buy the full version of team viewer, so i will only be able to remote operate my tractor 30min at a time, being half Ukrainian could be a software bug.
Farm simulator is a huge game, if the insurance risks were not so big AOG could be used for a remote “Real Farm Simulator” version. Scary, leave some 8 year old running the combine from his basement.
VNC helps you out. There are many free implementations… 
It’s possible to make a tractor safe, e. g. with laser scanners, but it won’t be reliable any more. Most often, you’ll do a u-turn directly in front of trees or bushes, which will be fail safely inhibited by such devices… Apart from that it can be safe if applied in a hight which is low enough, so noone can duck under. So never suitable for harvesting and too difficult for hobbyists yet…
I use it, the free one, but use ip direct to the router in AgraBot via wifi