AgOpenGPS - Page 14 - The Combine Forum
 2119Likes
 
LinkBack Thread Tools
post #131 of 4060 (permalink) Old 11-12-2016, 11:53 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,680
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Quote:
Originally Posted by torriem View Post
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.
To quote Futurama..... The engines donít move the ship at all. The ship stays where it is and the engines move the universe around it.

Yes you are right, and it doesn't really matter which one you do because the net effect is the same. If we move the world in a positive X direction, it is the same as moving the camera in the negative X direction.

There are 3 main matrices. Model, View, and Projection. The Model defines where in the world the object is. the View matrix defines the camera "the look at" position, and the Projection matrix defines how much of the world we want to see and project the 3D image onto the 2d surface we see - the monitor. Each of the matrices can have Rotation, Scaling, and Translation matrices all along anywhere at anytime as all the matrices are multiplied together to create the final view. That's why it is so easy to end up with nothing on the screen visible as one tiny change in the wrong direction is disastrous.

In terms of many triangles there is an upper limit, a few million, but not all have to be drawn either all the time. This is called Frustum culling and the OpenGL pipeline drops off the triangles that aren't in the view (what is seen) so it takes little to no resources for most of the triangles. You can also do manual calculations to determine if a triangle lies inside or outside the view to leave out the triangles that will never be drawn and only send the ones that will be drawn to Opengl. That technique is used a lot in gaming.

In the OpenGL_Draw routine there is also a 2D model,view, projection that does the lightbar stuff. It is an X,Y type of screen that has no depth and a fixed screen size like basic 2D graphics of text etc. These also get added into the matrices of the 3D.


BrianTee is online now  
Sponsored Links
Advertisement
 
post #132 of 4060 (permalink) Old 11-13-2016, 06:35 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,506
Mentioned: 6 Post(s)
Quoted: 869 Post(s)
Haha. We are seriously nerdy around here. A farmer that can quote futurama is pretty impressive!

So in your function that does lookahead, which matrix do the translations and rotations apply to? Because it looks to me like the triangles strips are always going in according to northing and easting, no matter what heading angle we've rotated the world around to. EDIT. Looks like we are always manipulating the PROJECTION matrix. Got it.

Is there a reason you used x and z for easting and northing in the coverage calculations? To me it looks like you could have used x and y there and just not tipped things on their side by 90.


Last edited by torriem; 11-13-2016 at 07:27 PM.
torriem is offline  
post #133 of 4060 (permalink) Old 11-17-2016, 08:45 AM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,680
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Quote:
Originally Posted by torriem View Post
Haha. We are seriously nerdy around here. A farmer that can quote futurama is pretty impressive!

So in your function that does lookahead, which matrix do the translations and rotations apply to? Because it looks to me like the triangles strips are always going in according to northing and easting, no matter what heading angle we've rotated the world around to. EDIT. Looks like we are always manipulating the PROJECTION matrix. Got it.

Is there a reason you used x and z for easting and northing in the coverage calculations? To me it looks like you could have used x and y there and just not tipped things on their side by 90.
It is more "natural" to use Y as an elevation. Z is into and out of the screen X is left and right. So off into the horizon and behind you is the Z axis. Heightfield maps etc to make mountains and terrain all use Y as the height or elevation axis. Since the default for OpenGL is -Z going into the screen, i also flip that 180 so +Z goes into the screen. This was done because UTM coordinates are positive as you go north and east. So, after all the flips and twists it looks like a normal XY grid with 0,0 in the center, and increasing northing is straight into the screen up the +z, north. South is towards you and is -Z. West is -X or left, and East - which is increasing UTM is +X. Yopu only have to do the flips once in the camera and once that is done all translations and rotations match the real world and is much easier.

As below, you can see why. The only difference really between 3D systems is whether or not going into the screen (Z) is positive or negative. That also sets the rules for right hand or left hand rule for things like triangle winding, translate, rotates etc. Explained briefly here... https://www.evl.uic.edu/ralph/508S98/coordinates.html

BrianTee is online now  
Sponsored Links
Advertisement
 
post #134 of 4060 (permalink) Old 11-17-2016, 08:54 AM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,680
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Code:
                       double over = Math.PI - Math.Abs(Math.Abs(fixHeadingSection - fixHeading) - Math.PI);

                        if (over < 1.5)
                        {
                            trailingToolEasting = hitchEasting + (Math.Sin(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                            trailingToolNorthing = hitchNorthing + (Math.Cos(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                        }

                        else
                        {
                            fixHeadingSection = fixHeading;
                            trailingToolEasting = hitchEasting + (Math.Sin(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                            trailingToolNorthing = hitchNorthing + (Math.Cos(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                            prevTrailingToolNorthing = trailingToolNorthing;
                            prevTrailingToolEasting = trailingToolEasting;
                        }
So hopefully solved the wild hitch issue when stopping or rolling backwards slightly. If the hitch exceeds around 90 degreees its just forced to be a rigid hitch. Don't know if you have ever used

Math.PI - Math.Abs(Math.Abs(fixHeadingSection - fixHeading) - Math.PI)

to calculate the delta of two spinning angles - but its a good one!

I'll be getting AgOpenGPS version 2.0.0.1 up soon. Some major changes - although it looks exactly the same except for the settings stuff. If you thought the OGL stuff was difficult before, this now translates everything to the pivot axle of a vehicle, the hitch, the implement, and the antenna. You can have steering in the back like a combine, front or rear tool, rigid or trailing, antenna ahead or behind. Fun stuff!
BrianTee is online now  
post #135 of 4060 (permalink) Old 11-17-2016, 03:11 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,506
Mentioned: 6 Post(s)
Quoted: 869 Post(s)
Sounds great. I've been playing with some code to do better lookahead while the implement is turning. I'll rebase my code here when you get yours released. Looking forward to seeing the changes.

Nice delta angle trick. I was doing a subtraction followed by adding or subtracting 360 depending on the sign and magnitude (if it's > 180).

What issues where you seeing when stopping or rolling backwards slightly? I never saw any wild issues. The only issue I could foresee would be if the hitch was very short. I did have issues when starting out since the heading information from the tractor while stopped could be anything. I did something very similar to your code to fix that. So maybe we're talking about the same thing.

Last edited by torriem; 11-17-2016 at 03:24 PM.
torriem is offline  
post #136 of 4060 (permalink) Old 11-17-2016, 03:27 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,680
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Quote:
Originally Posted by torriem View Post
Sounds great. I've been playing with some code to do better lookahead while the implement is turning. I'll rebase my code here when you get yours released.

Nice delta angle trick. I was doing a subtraction followed by adding or subtracting 360 depending on the sign and magnitude (if it's > 180).

What issues where you seeing when stopping or rolling backwards slightly? I never saw any wild issues. The only issue I could foresee would be if the hitch was very short.
If you did a quick 180 like roll backwards the hitch would be 180 out and it would pendulum all the way around the vehicle. At the start too depending on the first few fixes it could be sticking out the front of the vehicle and would have to swing all the way back to where it should. On a simulator it was evident, and in real life it was only evident if you rolled a bit back, then rolled a bit ahead, then back it was easy to replicate. It just takes time for the previouses (not a word!) to work their way thru. Not really a bug, just looked bad.

It may be tricky for a single section and lookahead as half the section is moving ahead and half moving forward. Or a wide center section of a 3 section.
BrianTee is online now  
post #137 of 4060 (permalink) Old 11-17-2016, 07:59 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,506
Mentioned: 6 Post(s)
Quoted: 869 Post(s)
Hmm that's very odd. The algorithm should just push the implement back. I'll have to look into that and see what's going on. The tractors heading should not have a rapid change effect on the implement's heading. In fact if you back up and turn while doing so, the implement prediction algorithm should cause the implement to push back and jackknife much like in real life.

Yes the idea of part of the sections moving forward and part moving back is exactly what I'm working on. And also the parts of the sections are moving at different rates.

Last edited by torriem; 11-17-2016 at 08:07 PM.
torriem is offline  
post #138 of 4060 (permalink) Old 11-17-2016, 09:05 PM Thread Starter
Senior Member
 
Join Date: Aug 2012
Location: Vermilion Alberta Canada
Posts: 5,680
Mentioned: 18 Post(s)
Quoted: 2483 Post(s)
Quote:
Originally Posted by torriem View Post
Hmm that's very odd. The algorithm should just push the implement back. I'll have to look into that and see what's going on. The tractors heading should not have a rapid change effect on the implement's heading. In fact if you back up and turn while doing so, the implement prediction algorithm should cause the implement to push back and jackknife much like in real life.

Yes the idea of part of the sections moving forward and part moving back is exactly what I'm working on. And also the parts of the sections are moving at different rates.
There is no backing up in GPS, only forward. If you back up, you're immediately driving forward in the other direction. So if your heading is 30 deg and roll backwards you're now going forward with a fixHeading of 210 deg immediately. The tool position remains the same except now the hitch is pointing the wrong way.
BrianTee is online now  
post #139 of 4060 (permalink) Old 11-17-2016, 09:40 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,506
Mentioned: 6 Post(s)
Quoted: 869 Post(s)
I got my el cheapo RS232 to bluetooth adapter today. After much trial and tribulation I think might have it working. Came with no documentation and it wasn't clear at all how to set it up. I think I got it working though. We shall see.

I think for the real deal, an adapter like the Aircable Serial5 would be the most reliable solution, though it costs a bit more.
torriem is offline  
post #140 of 4060 (permalink) Old 11-17-2016, 09:47 PM
Senior Member
 
Join Date: Sep 2009
Location: S. AB
Posts: 3,506
Mentioned: 6 Post(s)
Quoted: 869 Post(s)
Quote:
Originally Posted by BrianTee View Post
There is no backing up in GPS, only forward. If you back up, you're immediately driving forward in the other direction. So if your heading is 30 deg and roll backwards you're now going forward with a fixHeading of 210 deg immediately. The tool position remains the same except now the hitch is pointing the wrong way.
Right. Okay I see what you meant. Sounds like I independently implemented the same solution in my copy of the code the other day. Hope to see the latest code soon so I can try to integrate what I'm working on.

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