AgOpenGPS - Page 13 - The Combine Forum
 2161Likes
 
LinkBack Thread Tools
post #121 of 4131 (permalink) Old 11-08-2016, 03:37 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,570
Mentioned: 6 Post(s)
Quoted: 876 Post(s)
Looks very good, Brian. I like your graphics.

As far as being good enough goes, my Smartboom does no hitch turn prediction whatsoever and it actually works pretty well 99% of the time. And I farm circles. I thought it would be more of an issue than it turned out to be. But I'm definitely happy to contribute code and algorithms to make things as smart as we can. I just worry that as I make my algorithms smarter, I'm going to miss something and it will fail in some weird way.

torriem is offline  
Sponsored Links
Advertisement
 
post #122 of 4131 (permalink) Old 11-08-2016, 04:29 PM
Senior Member
 
wvca's Avatar
 
Join Date: Nov 2014
Location: Yorkton, Sk, Canada
Posts: 458
Mentioned: 0 Post(s)
Quoted: 110 Post(s)
Barn
Just curious as to a few things ..
First: which Arduino version are you using for the auto relay output.. I _assume_ Mega just because of the larger number of available I/O pins?
Second: What type of "spray is on" verification is there, separate pressure switches or? Just to verify that there is actually product being applied in areas that are shaded in the final coverage map produced ..
Last: Is there any sort of provision for 'acres applied' versus 'field acres', as with any overlap [either deliberate or accidental] there are more acres actually covered that what there are in the actual field..

Thanks
It does work under XP, although port and baud selections are 'whited out' until you actually hover the pointer over them, and show as whited out even after selection..

wvca is online now  
post #123 of 4131 (permalink) Old 11-08-2016, 06:39 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,570
Mentioned: 6 Post(s)
Quoted: 876 Post(s)
I think he's just using a regular Uno, which has enough pins for 5 or 6 sections. But if you needed more a Mega would work fine. There's not currently any verification. It just sends the signal and hopes for the best. The protocol he's defined for talking to the arduino is extremely simple and one-way. But in the future I can see a place for a two-way communications channel. For example, a bank of toggle switches could be used to do manual section control, while informing AgOpenGPS so it can map the coverage.
torriem is offline  
Sponsored Links
Advertisement
 
post #124 of 4131 (permalink) Old 11-08-2016, 06:51 PM
Senior Member
 
wvca's Avatar
 
Join Date: Nov 2014
Location: Yorkton, Sk, Canada
Posts: 458
Mentioned: 0 Post(s)
Quoted: 110 Post(s)
Barn
I can see the benefits of a master / manual switch, handy to make sure that the spray soleniods don't open up on the way out of the yard as they would show as an un-sprayed piece of ground ..
And a manual or Arduino monitored input micro switch that would actuate the mapping area would definitely come in handy for me, as it would allow any manually toggled or micro switch activated implement to be able to generate coverage maps .. good not only to see if there are missed spots, but also for useable acreage calculation mapping .
Another option that may come in handy for some users would be the ability to generate 'point markers' .. such as marking rocks to be picked at a later time .. for this just a low cost usb antenna with a tablet would suffice .. with a cost of little more than a hundred dollars, and easy interchange between tractors, etc ..
wvca is online now  
post #125 of 4131 (permalink) Old 11-08-2016, 07:05 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,741
Mentioned: 19 Post(s)
Quoted: 2504 Post(s)
Quote:
Originally Posted by wvca View Post
Just curious as to a few things ..
First: which Arduino version are you using for the auto relay output.. I _assume_ Mega just because of the larger number of available I/O pins?
Second: What type of "spray is on" verification is there, separate pressure switches or? Just to verify that there is actually product being applied in areas that are shaded in the final coverage map produced ..
Last: Is there any sort of provision for 'acres applied' versus 'field acres', as with any overlap [either deliberate or accidental] there are more acres actually covered that what there are in the actual field..

Thanks
It does work under XP, although port and baud selections are 'whited out' until you actually hover the pointer over them, and show as whited out even after selection..
First. I used the Arduino Uno. It has plenty of ports etc. It is 2 way communication, can read and write to Uno.

Second. Just like most auto sections without rate controllers built in, they are dumb and don't care if the boom is actually on. It just assumes when the relay goes on, its on.

Last. No, have not thought about that. Don't really record the data from an overlap, so at present it would be really hard to determine. You can use google earth, lots of other sites etc to calculate exact areas of fields only once forever - then just subtract the 2.
BrianTee is offline  
post #126 of 4131 (permalink) Old 11-08-2016, 07:09 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,741
Mentioned: 19 Post(s)
Quoted: 2504 Post(s)
Quote:
Originally Posted by torriem View Post
Looks very good, Brian. I like your graphics.

As far as being good enough goes, my Smartboom does no hitch turn prediction whatsoever and it actually works pretty well 99% of the time. And I farm circles. I thought it would be more of an issue than it turned out to be. But I'm definitely happy to contribute code and algorithms to make things as smart as we can. I just worry that as I make my algorithms smarter, I'm going to miss something and it will fail in some weird way.
I'm a firm believer in simple code. Easy to understand, change and maintain.
BrianTee is offline  
post #127 of 4131 (permalink) Old 11-10-2016, 11:53 AM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,570
Mentioned: 6 Post(s)
Quoted: 876 Post(s)
Brian, I have a couple of OpenGL questions for you. In your lookahead code you rotate the world according to the implement's heading, then you translate to the location of the tractor. The effect of this is to have the camera looking down on the field at the location of the tractor, but rotated according to the heading. Then you can use the ReadPixels calls to look effectively behind the tractor (in front of the implement) at spots that are where the implement would be in various subdivisions of the lookahead time * velocity. Is that a correct understanding?

Also. the GL transforms are cumulative right? In other words, once a world is rotated, the translations are now relative to that new rotation? If so, wouldn't it be correct to translate first to the tractor location and then rotate the world to the heading? What am I missing? EDIT: no I'm not right.

So what I'd like to try is to implement a lookahead that looks something like this. I've written code to track the rate of change of the heading so that during a turn we can predict the heading a second or two into the future. I'd like to try to make the lookahead code then look down the present heading however many seconds, and rotate to a new predicted heading. That should account for the booms going backwards on a turn. I think I could do it by doing some translations and rotations, but it must not be a simple thing after your initial rotation and translation because everything I try is not what I want! I've moved your hidden OpenGL widget out into the open so I can see what it's doing. Any advice for me on this? I think my problem is lying with not fully understanding how OpenGL coordinates are working.

Last edited by torriem; 11-11-2016 at 12:49 AM.
torriem is offline  
post #128 of 4131 (permalink) Old 11-11-2016, 01:28 AM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,741
Mentioned: 19 Post(s)
Quoted: 2504 Post(s)
Hey just got in. Actually combined some today!

In just thinking about this as you wrote how about just doing a readpixel 'behind' the boom all the time just like ahead of the boom? Also it has to work properly when a rigid boom is selected. The other thing i discovered was the back face culling was set so when the boom went backwards it was still making triangles, its just the winding was the other way around so to opengl they were facing the other way. Triangle winding, the order which the points are generated and culling, glCullFace are topics also worth looking at.

Opengl is a bit of a tough one. Getting all the translations and rotations just right and in the right order can be a monumental task. OpenAg using compass style degrees and direction makes it especially wonky. Everything is upsidedown and mirrored and 90 degrees rotated.

I probably didn't answer a single thing you asked.....
BrianTee is offline  
post #129 of 4131 (permalink) Old 11-11-2016, 06:15 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,570
Mentioned: 6 Post(s)
Quoted: 876 Post(s)
Glad you're combining!

I'll try to figure out exactly what I'm asking, then you can work on an answer!
BrianTee likes this.
torriem is offline  
post #130 of 4131 (permalink) Old 11-12-2016, 09:52 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,570
Mentioned: 6 Post(s)
Quoted: 876 Post(s)
Okay so I've educated myself on OpenGL a bit. Now you can tell me if I get this right. So each time we want to render a frame (whether that's to the hidden coverage widget, or the main display widget), we translate and rotate the world to be where we want it to relative to the "camera" which is always at the origin. Then we "draw" all the triangles. Is that right?

I know openGL is fast, but eventually if we have to create all the triangles for a very large field every frame will that be too slow to draw properly? I know you have logic to create fewer triangles when the machine is moving slowly.

torriem 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