I was thinking of creating a webbased version of AgOpenGPS so that you can use it on your phone/iPad or anything else. So you are independent from any platform. A raspberry pi for example could then emit a wifi signal. But a first look at the code showed me that unfortunately everything looks really entangled and that there is no clear distinciton between showing the data and calculating it most of the time. So this looks like a lot of work, still I think a lot of people could benefit from it. But I can’t do this on my own, so is anyone else interested in splitting the project up into four parts:
Hardware Interfacing
Business logic
Standard WinForms application ASP.Net server
And help me creating the ASP.net part? Has this ever been tried before? Do you think it would be feaseable?
I’ve thought about this possibility several times. It’s certainly doable. It requires completely separating the front end from the back end. Currently there’s no such separation. It would require quite a bit of work by contributors, but would be well worth it. If the backend and frontend were separated it would make porting to other platforms much easier, including web front ends. AOG is tightly coupled with OpenGL. The section control lookahead uses off-screen OpenGL to do the work. I’m not sure how that would work with something like a Pi running headless.
I guess there are two ways of approaching this. First would be to have everything run on the embedded server, including off-screen OpenGL, and the just use a web client (and webGL) to draw the UI and the current state of AOG and the field map. The second approach is to do everything in the web browser including section control lookahead with WebGL, steering calculations, etc, and then the embedded web server would just act as a hardware bridge. This isn’t as daft as it sounds Javascript is very capable, and already we’re using javascript to interact with 3D printers and CNC machines. But personally I would favor the first method, so things would keep working if you put the phone to sleep or hopped out of the machine for a bit.
But yes, a web front-end is a great idea, and would probably become the future.
As far as I can see here the pi 4 supports openGL. One of the better pi models is even capable of running windows, but with the .net core-framework or mono is should be possible to execute it within raspbian. I’ve never worked with AgOpenGPS a friend of mine just asked me if I could help him install it in his tractor. Then he said it would be cool if he could use his iPad as a tablet. I think a raspberry in combination with its built in GPIO-Pins should be sufficient to even get rid of the arduino.
Are there any ways how I could help you in creating a webbased version? I know a little bit about ASP.net for the backend, I’m good with Angular or React for the frontend. But I have no idea how AgOopenGPS works. What do you think would be the best way to get to know it?
Angular is what my colleagues in the company are using as well. But I’m a hardware developer - so I can tell you everything about hardware up to C and some Python, but that’s where my knowledge ends and that doesn’t help here… And I’ve the same roots: A friend of mine as me to help him.
So if someone takes the lead on that I would adapt my PCB assembly as a pi4 extension. For me, “web based” definitely is the future.
Agree, I would be glad if someone could take on the (I have to say tideous) task to make the business logic completely independent from the UI, so that you can then built a WinformsUI, WebUI or whatever else on top of it. This also would be necessary to to make the project executeable on Raspbian because WinForms is only supported on windows (at least at the moment). If there’s a REST-backend that doesn’t rely on WinForms in any way it would also pave the way for more operating systems. But all of that definetly is something too big for just 2-3 people if we want to see results within the next few months.
What I know so far is that @BrianTee_Admin is beautifying the software a lot right now making everything cleaner and more generic. That may be a good starting point for that big step one day…
Can you guys explain a bit more about the advantages of a web based system? So far it sounds to me like the Apple religion members could join the Apple logo at any cost.
I feel the main target here is to help farmers with a low cost approach. I don’t mind if experts go for Android or Apple one way or the other but I hope it does not distract resources from the low cost approach. How could an iPad with the necessary HW bring a lower cost setup. I understand some of us have an iPad already but but far more of us have a compatible windows tablet anyway.
Also in my opinion the AOG HW should remain stable as long as possible. Even if the current HW (the auto-steer board) is not expensive, some need help building the box and would want to avoid doing it again and again.
You dont need to use an iPad. With a Webbased version you don’t have to buy a tablet or anythin at all. You can just use your phone, laptop or iPad if you already have one. Furthermore the use of a Raspberry Pi would eliminate the need for multiple Arduinos. Combined with the fact that you don’t need to buy a tablet this makes it actually cheaper as it is now.
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.
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.
webbased means, it works with any device with a modern browser w/o the need to install anything. That also means, you can even start with using a mobile phone at first, if the web application is “responsive”
webased also means, the server is doing the steering and the browser does all the graphics calulation
if using a PI 4 as platform, it is possible to provide an image for a SD card, so the only “installation” step for a user is to copy that image to the card - no need to have any idea of Arduino and programming, etc. You don’t even need a PC!
I don’t see the decision “either C or Python” as Python can run with libs written in C. It should be possible to combine the benefits of these two. Python comes with Bottle or Django, but Angular is also a way to go
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:
Decoupling between UI and operation. A UI freeze isn’t going to bring down the whole tractor.
Improved platform support. It’ll likely require a new code base, and we can start from a base that runs on windows and linux, opening up a whole new swath of usable hardware, and reducing costs (if you only run one tractor at a time, you can have one tablet/laptop for using the GUI and all the tractors run a low-cost SBC)
Improved remote control ergonomics: instead of remoting into a machine to run the GUI, you simply connect to the server. This also heavily enables “fleet” style control, because having a more well-defined REST (or otherwise) interface to the tractor lets you abstract over machines.
Improved testing/reliability. It’s REALLY hard to do reliable testing of a GUI, there is so much state that we intuitively navigate but is very hard to do rigorous testing on. Both on the unit tests side as well as larger integration tests. I can see there being a standard set of test fields in a simulator that has to perform within a set of bounds for every release.
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!
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.
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.
That may be a good starting point for that big step one day…
). Slapping a web (Angular/Node/React) interface on after that would be nice BUT