AgOpenGPS - Page 253 - The Combine Forum
 2161Likes
 
LinkBack Thread Tools
post #2521 of 4131 (permalink) Old 10-08-2018, 04:39 PM
Senior Member
 
Join Date: Jan 2018
Location: P.E.I. Canada
Posts: 211
Mentioned: 2 Post(s)
Quoted: 84 Post(s)
Quote:
Originally Posted by dairytech View Post
I am afraid the free version of Slack is not big enough for this project. We used it at work until we ran into the 10,000 message limit. That comes a lot quicker than you might think; it took two of us about 14 months. AOG and its community is on quite a growth path. If it gets moved to a new home, it needs to be one that can scale properly with it. I don't think we want to chose a platform that will require us to pay $10/month each to access all of the content of the community has generated. Escaping subscriptions is part of what brought us here.
I reserved the AgOpenGPS Slack channel a while back (see this post) and I figured the same thing after trying to get that going. Users shouldn't have to pay to get some of the features required for a project of this scale.

WTalen is offline  
Sponsored Links
Advertisement
 
post #2522 of 4131 (permalink) Old 10-08-2018, 06:27 PM
Junior Member
 
Join Date: Oct 2018
Location: New Mexico
Posts: 21
Mentioned: 0 Post(s)
Quoted: 8 Post(s)
Brain,
I'm willing to debate the merits of running Windows vs. something else, but I doubt either of us will convince the other. I'm concerned about the provable max response time for Windows, so I would prefer to run a different OS. I don't expect you to change the OS you're developing for, and I certainly don't expect you to rewrite everything in a different language. Would you consider accepting changes to the code that are geared towards decoupling the GUI and core logic? I haven't dug through the code deep enough to see how much of a concern that is/will be, but I think that if that can be done, then porting AOG to another OS can be done with mostly changes to the UI code and thus not splitting development of the core logic, which is important.

On the more general progress front: I've installed Monodevelop on my Windows machine and have started to poke at the code and getting it compiling under that as a first step to porting. It seems that GTKSharp is the current favorite GUI toolkit for Mono, so if a change is needed there, that's what I'm leaning towards. QT and wxWidgets don't appear to play nice with C#/Mono, so GTK is the only other major cross-platform toolkit I've seen much of. I would need a really good reason to try and rewrite AOG in another language and "QT is C++" doesn't do it for me. I'll put up a github repo later this week for those who are interested.

Is there any chance of a sub-section of these forums being setup for AOG? That would seem like a good option if possible, sense this is where things have congregated already.

NealAnthony is offline  
post #2523 of 4131 (permalink) Old 10-08-2018, 07:35 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,735
Mentioned: 19 Post(s)
Quoted: 2498 Post(s)
Quote:
Originally Posted by NealAnthony View Post
Brain,
I'm willing to debate the merits of running Windows vs. something else, but I doubt either of us will convince the other. I'm concerned about the provable max response time for Windows, so I would prefer to run a different OS. I don't expect you to change the OS you're developing for, and I certainly don't expect you to rewrite everything in a different language. Would you consider accepting changes to the code that are geared towards decoupling the GUI and core logic? I haven't dug through the code deep enough to see how much of a concern that is/will be, but I think that if that can be done, then porting AOG to another OS can be done with mostly changes to the UI code and thus not splitting development of the core logic, which is important.

On the more general progress front: I've installed Monodevelop on my Windows machine and have started to poke at the code and getting it compiling under that as a first step to porting. It seems that GTKSharp is the current favorite GUI toolkit for Mono, so if a change is needed there, that's what I'm leaning towards. QT and wxWidgets don't appear to play nice with C#/Mono, so GTK is the only other major cross-platform toolkit I've seen much of. I would need a really good reason to try and rewrite AOG in another language and "QT is C++" doesn't do it for me. I'll put up a github repo later this week for those who are interested.

Is there any chance of a sub-section of these forums being setup for AOG? That would seem like a good option if possible, sense this is where things have congregated already.

Absolutely you can port it, that would be great! I would love to see it in C++ and in a form without the graphical limitations of Winforms.



The GUI is merely a set of buttons with delegate actions and events (function pointers in C++ if you're familiar) that do the specific action in the delegate code or call another function and all reside in classes. Your interface would only have to call the event and would only require the object and Event Args sent. Multi file modifications would be very tedious to update. AFAIK, none of the functions utilize either the sent object class or any eventArgs ie they could just be dummies. AOG is a purely event driven, multithreaded, with all input output as asynchronous, and is a fully non blocking application.



What is the quantifiable response time that you are having issue with? The normal loop in AOG takes about 5 msec while data incoming is at 200 msec for 5 hz GPS or 100 for 10hz. With a good video card and mainboard, it can run at 50 hz. The main loop runs at 50 ms - roughly 10 times as long as the frame time. You can see the frametime at the bottom left of status bar. If there are actual latency issues you have discovered, they need to be fixed. Can you elaborate?
BrianTee is online now  
Sponsored Links
Advertisement
 
post #2524 of 4131 (permalink) Old 10-08-2018, 09:34 PM
Junior Member
 
Join Date: Oct 2018
Location: New Mexico
Posts: 21
Mentioned: 0 Post(s)
Quoted: 8 Post(s)
I'll try to explain: Windows (and most OS's that people are familiar with) control which client software has access to resources at a given time, right? So, Windows dictates when any give thread is allowed to run computations on hardware. That means that even though the CPU and video card may be capable of running the computation in extremely short times there is still the question of when those computations are allowed to run. That is: when a thread is serviced. Windows, MacOS, and most desktop variants of Linux do not guarantee that any given thread will be serviced at any given rate. You can try to boost a thread's priority, but that is still not a guarantee. If the computer is in the control loop then I believe that it needs to be able to guarantee a maximum response time for any necessary data, just as the GPS, IMU, sensor fusion, and PID/steering controller must. I do not believe that any typical desktop OS is suitable to be in the loop based on this. A port to Linux is, to me, the first step to moving to a RTOS which would meet the requirement of guaranteeing a maximum time between updating data that the auto-steer system needs.

My concern is not with latency issues per se, and I haven't seen any, but with a lack of certainty. I actually have seen (on a similar but completely unrelated project that I mentored for a while) that Windows will not service a thread for hundreds of msec up to or over a second on a regular basis. It depends on what else is running, how the system is configured, and what the multi-threading code in Windows looks like on that release. I'm not a controls guy, but from I know most industrial systems get around this problem using PLCs or similar embedded systems that run the controls logic and communicate back to data collection/UI programs running on desktops where msec scale timing is not important.

Hopefully that makes my concerns clearer? I do realize that this will seem like minutia to many people, but like I said previously my background is in RF hardware research so it's the way I think. And I think it's valuable and important enough that I am willing to put in effort on this.
NealAnthony is offline  
post #2525 of 4131 (permalink) Old 10-08-2018, 10:38 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,569
Mentioned: 6 Post(s)
Quoted: 875 Post(s)
GTK Sharp is an option for a port... I've seen people do OpenGL with GTK Sharp.

I'd also like to see AOG (or port of AOG) be able to run on other platforms besides x86 Windows, such as any of the plethora of ARM-based systems out there, which are quite a bit cheaper than windows tablets. These ARM platforms could integrate nicely with sensors and even drive the steering valve directly from GPIO pins (would require a real time kernel). Makes a lot of sense to me to have that flexibility eventually, which is why I started my Qt port, which I'd still like to see through. The Qt version I started is written nearly entirely using QML for the UI (think more like an HTML-style interface with CSS and Javascript), so that means it would be possible to run it on Android. Qt does use real C++, and it's actually quite readable and not too hard. There are a few C++isms to deal with such as smart pointers on occasion, but it's really not that much different than C# for our purposes.

As for the realtime aspect of it, real time is not technically required for AOG since the time sensitive stuff like PID control of the steering is offloaded to a dedicated microcontroller. But Linux can run a soft real time kernel, and it works well enoguh to drive CNC machines.

If you would like to help out with the Qt effort, let me know.

Last edited by torriem; 10-08-2018 at 10:44 PM.
torriem is offline  
post #2526 of 4131 (permalink) Old 10-09-2018, 08:56 AM
Junior Member
 
Join Date: Oct 2018
Location: New Mexico
Posts: 21
Mentioned: 0 Post(s)
Quoted: 8 Post(s)
I haven't actually worked with C# or Mono before, do you know if it runs reasonably well on non-x86 hardware? That would be a reason to change to a different language in my opinion. I actually do like the idea of everything in C++ since it isn't so strongly associated with a single supplier, but I'm more concerned with splitting an already small development community.

If the sensors and target position and heading for the PID loop are being mediated by AOG (I think this is a typical setup right now?) then I would argue that it is in the control loop, and if the inputs don't meet the bandwidth requirements of the PID there is a problem that could lead to oscillations. I do expect a soft real time would be suitable in this case, should be possible to calculate out the max bandwidth that any control loop needs based on speed and steering sensitivity. I would probably try to run safety systems asynchronously, just for good measure, but that would need further investigation to understand the trade offs.
NealAnthony is offline  
post #2527 of 4131 (permalink) Old 10-09-2018, 09:35 AM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,735
Mentioned: 19 Post(s)
Quoted: 2498 Post(s)
Neal, can you confirm that this is a problem in AgOpenGPS? Can you demonstrate it? I've used both LinuxCNC and Windows Mach on my CNC stuff - they both work just as good, just as bad.



Has anyone ever noticed the display stutter repeatedly? Ever noticed going around a corner where the points plotted for a boundary aren't a smooth corner but are jagged from missing fixes? Any missing section regions being painted? Any section control not turning on or off at exactly the right time? Once every 3 minutes it needs to back up all the data and write to all the files, some rewritten completely, some appended to, and not even then have i noticed a lag.

Let's not be chasing windmills here. I'm not saying it shouldn't be ported, but not ported because it doesn't work in Windows.

Can Mono do 64 bit doubles yet? Arrays are dreadfully slow, its why Mono was chopped from my list initially. 32 bit floats won't cut it with 7 digits of precision. OpenGL.Net should really be the only openGL wrapper considered as its complete and currently one of the very few being updated.
Please demonstrate there is an issue in the current version if there actually is one.
Beerwiser, WW, dairytech and 1 others like this.
BrianTee is online now  
post #2528 of 4131 (permalink) Old 10-09-2018, 11:32 AM
Member
 
Join Date: Mar 2018
Location: Rock Valley, Iowa
Posts: 86
Mentioned: 1 Post(s)
Quoted: 35 Post(s)
Quote:
Originally Posted by BrianTee View Post
Neal, can you confirm that this is a problem in AgOpenGPS? Can you demonstrate it? I've used both LinuxCNC and Windows Mach on my CNC stuff - they both work just as good, just as bad.



Has anyone ever noticed the display stutter repeatedly? Ever noticed going around a corner where the points plotted for a boundary aren't a smooth corner but are jagged from missing fixes? Any missing section regions being painted? Any section control not turning on or off at exactly the right time? Once every 3 minutes it needs to back up all the data and write to all the files, some rewritten completely, some appended to, and not even then have i noticed a lag.

Let's not be chasing windmills here. I'm not saying it shouldn't be ported, but not ported because it doesn't work in Windows.

Can Mono do 64 bit doubles yet? Arrays are dreadfully slow, its why Mono was chopped from my list initially. 32 bit floats won't cut it with 7 digits of precision. OpenGL.Net should really be the only openGL wrapper considered as its complete and currently one of the very few being updated.
Please demonstrate there is an issue in the current version if there actually is one.
I wish I could give Brian's post here 5 likes instead of just one. I really believe that porting = fracturing, to solve a problem that we don't have. While it is technically true that Windows can fail to service a thread for an undetermined amount of time, realistically, it isn't an issue. Porting WILL come with some big costs with regard to investing time in duplicating what is already done at the expense of time spent expanding and polishing what we have. For everyone who has read all of the AOG posts, it is very clear that Brian did a lot of research into the most productive combination of software platform, programing environment, and hardware platform. I am convinced that he got all three right. Community size is a really big factor in projects like this, it is pretty hard to argue that there is a bigger community than the Microsoft Windows community, same for Visual Studio; for microcontrollers, what is bigger than Arduino? Most of us here are not programming or electronics professionals. Big communities mean you can find help much more easily; it is impossible to overestimate the value of that.

An awful lot of projects die pursuing perfection when good enough would do. Windows is not a real time operating system; this is a non-issue. It is vastly more likely that problems will arise from non-locking USB and Bosch connectors jiggling loose than that Windows will leave AOG hang too long.

If you are using AOG to operate big equipment, don't try index the contents of the Library of Congress on the same tablet at the same time and it won't be a problem.
Beerwiser and apm like this.
dairytech is offline  
post #2529 of 4131 (permalink) Old 10-09-2018, 11:34 AM
Member
 
Join Date: Jul 2011
Location: Manitoba
Posts: 58
Mentioned: 1 Post(s)
Quoted: 21 Post(s)
Quote:
Originally Posted by BrianTee View Post
Does AgraBot sound better then AgOpenGPS? Easier to type, understand?
Agrabot sounds cool. But How about just AgOpen?
Emphasizes the open-source, could be expanded (ie. AgOpen-Guidance; AgOpen-Steer; AgOpen-Section; AgOpen-Autonomous; etc).

Makes no difference to me either way what the name is.
BrianTee likes this.
rewandy5 is offline  
post #2530 of 4131 (permalink) Old 10-09-2018, 02:37 PM
Senior Member
 
Join Date: May 2011
Location: Manitoba
Posts: 369
Mentioned: 0 Post(s)
Quoted: 97 Post(s)
Quote:
Originally Posted by BrianTee View Post
Neal, can you confirm that this is a problem in AgOpenGPS? Can you demonstrate it? I've used both LinuxCNC and Windows Mach on my CNC stuff - they both work just as good, just as bad.
I can appreciate both sides of this discussion.

My Linux boxes just work. That being said, my Windows 7 machines also work almost as reliably (95%) but my Windows 10 tablet (Switch Alpha 12) for playing around with AoG is frustrating. After sitting for a couple weeks, it's unusable for the first several minutes while Windows 10 does things I can't seem to permanently turn off. It might be possible to run W7 on these but most don't conveniently provide the drivers for it and how much longer can we buy serial numbers for W7.

If it was ported, I wonder if it could run on a Raspberry Pi or similar.

I think I'd stick with Windows/C# and maybe build a small W7 box with a separate display.

m_elias is offline  
Sponsored Links
Advertisement
 
Reply

Quick Reply
Message:
Options

Register Now



In order to be able to post messages on the The Combine Forum forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.

User Name:
Password
Please enter a password for your user account. Note that passwords are case-sensitive.

Password:


Confirm Password:
Email Address
Please enter a valid email address for yourself.

Email Address:
OR

Log-in










Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page



Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

 
For the best viewing experience please update your browser to Google Chrome