The Combine Forum banner

121 - 140 of 4139 Posts

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
514 Posts
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..
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
514 Posts
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 ..
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #125
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #126
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.
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #128
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.....
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #131
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.
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #133
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

 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #134
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!
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #136
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.
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
5,826 Posts
Discussion Starter #138
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.
 

·
Registered
Joined
·
3,827 Posts
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.
 

·
Registered
Joined
·
3,827 Posts
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.
 
121 - 140 of 4139 Posts
Top