The Combine Forum banner

201 - 220 of 4139 Posts

·
Registered
Joined
·
4,005 Posts
Glad to be of help. Yes so far the OpenGL ES seems to do everything that we need.

Exceptions are sometimes difficult to know what to do with. Because nearly everything can cause an exception. I think I've settled on some best practices that I picked up in the Python world. Often times, not catching an exception is the right thing to do. That's because exceptions are exceptional events. IE events you weren't expecting and can't deal with in a sane way. Only exceptions that you want to deal with you should catch. In other words, if you have some logic that "does the right thing" (tm) when an exception occurs, then you can and should catch it. Otherwise, catching exceptions blindly just hides bugs.

I guess what I mean is that I don't think you need to have trys and catches around each and every string or array access. If you had done that here, it would have been a lot harder to track down this problem. (which may not have been a problem...)
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #202
Totally agree, its why there really is try catch mostly in the serial port and decoding nmea strings. In those it is very helpful to ignore strange data as it happens often.
 

·
Registered
Joined
·
4,005 Posts
For section control at least, it's mostly working now, and downloadable now to try (easiest to try it on a laptop, with your gps connected to a serial port). Steering is quite a ways off. Though some assembly is required. Controlling the sections requires an arduino connected to some relays.

Long term I think AgOpenGPS could be ported to run on Android, and then sold in the store for a couple hundred bucks. Section control hardware could connect via USB OTG (just like we currently do on our windows tablets), or bluetooth, or even wifi.
 

·
Registered
Joined
·
4,005 Posts
I had a go tonight to see if I could make the reversing behavior a bit better. I wasn't happy with just turning everything 180 on the screen when I reversed. Made a pretty X pattern on the coverage map, though!

Determining forward or reverse from just watching position and heading is actually quite hard! I think that watching for near 180-degree heading turns is good enough to determine a change from forward to reverse and vice versa. Once tractor orientation is determined (information from the IMU would make this a sure thing), the rigid toolbar can be computed properly. For swinging hitch toolsbars, the algorithm already can deal properly with backing up... we just need to push the hitch back and it goes where it should, more or less. Actually works quite well in my tests.

Anyway, it occurs to me that if we not only calculate the speed of each section as we're going but also a tool section direction vector somehow (basically just a binary forward or reverse thing... is the section moving on about the same heading as fixHeadingSection, or 180 from that), then when doing lookahead, we can look either ahead of the boom or back of the boom, depending on which direction we're going. The heading of the toolbar should always face towards the front of the tractor, in my opinion (if we can figure that out ), but the lookahead could look behind. Hope that makes sense. Might have a go at that.

EDIT: So noticed that you make the swinging hitch position relative to the tractor's hitch, and that led me to realize that half of my calculations were no longer necessary. Here's what it looks like now that I trimmed it:
Code:
                    //tool attached via a trailing hitch
                    if (vehicle.isToolTrailing)
                    {
                        //Torriem rules!!!!! Oh yes, this is all his. Thank-you
                        if ((hitchNorthing - prevToolNorthing) > 0 &&
                            (hitchEasting - prevToolEasting) > 0)
                        {
                            fixHeadingSection = Math.Atan2(hitchEasting - prevToolEasting, hitchNorthing - prevToolNorthing);
                            if (fixHeadingSection < 0) fixHeadingSection += Math.PI * 2.0;
                        }

                        toolEasting = hitchEasting + (Math.Sin(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                        toolNorthing = hitchNorthing + (Math.Cos(fixHeadingSection) * (vehicle.toolTrailingHitchLength));
                        //prevToolEasting and prevToolNorthing saved below;

                        // Compute the distance the tool moved vs the distance the tractor moved
                        // so we can make more accurate predictions of the speed of each section.
                        // Won't be necessary when we do actual section speed calculations.

                        double dist = Math.Sqrt( (pn.northing - prevNorthing[0]) * (pn.northing - prevNorthing[0]) +
                                          (pn.easting - prevEasting[0]) * (pn.easting - prevEasting[0]) );
                        if (dist != 0) {
                            dist = Math.Sqrt( (toolNorthing - prevToolNorthing) * (toolNorthing - prevToolNorthing) +
                                              (toolEasting - prevToolEasting) * (toolEasting - prevToolEasting) ) /
                                              dist; //ratio of tool movement to tractor movement

                            // overwrite the GPS speed with the estimated tool speed
                            pn.speed = dist * pn.speed;
                        }
                    }

                    //rigidly connected to vehicle
                    else
                    {
                        fixHeadingSection = fixHeading;
                        toolEasting = hitchEasting;
                        toolNorthing = hitchNorthing;
                    }
I moved the prevToolEasting and prevToolNorthing assignments farther down the code because I was going to use them to calculate section speeds.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #206
That sounds great - i like fast and simple!

Cool tip, multiplication is 41 times faster then division so for example 10/2 takes 41 times as long as 10 * 0.5. I know sometimes its unavoidable, but if it can be multiplied, its the way to go.

Have a manual/auto/off solution methinks. Pretty much reworked how all the determination for on off works. Rather then a button deciding if a section should be on and its state, the section carries the state and the button or buttons simply change that.

I'll throw up a video, let me know what you think. Its a huge part of the user interface and is critical it does what we want. Feedback is required!

Really looking forward to throwing in the smart lookahead! This is looking really good.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #207
A bit of spare time drying canola so may as well work on this thing! Short video on the new section On Off Auto buttons. I think there is any combination available, and quick one push to do anything you want. Let me know if i missed anything.

 

·
Registered
Joined
·
4,005 Posts
In my little code snippet there, I think the && actually could (should) be ||.

Yeah I will work on section speeds here shortly, unless you get to it first.

By the way I tried moving all of the code you mentioned from FormGPS_Load to the constructor, but actually all the openGL stuff has to stay in _Load() because it depends on the OpenGL surface being realized. So the only things I moved to the constructor were the section initializations and the NMEA parser.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #209
This is how my constructor for FormGPS looks with deleted accordingly out of FormGPS.load() now.... BTW, it didn't work on my tablet either till i did this change


Code:
        /// Constructor, Initializes a new instance of the "FormGPS" class.
        public FormGPS()
        {
            //winform initialization
            InitializeComponent();

            //create a new section and set left and right positions
            //created whether used or not, saves restarting program

            for (int j = 0; j < MAXSECTIONS; j++) section[j] = new CSection(this);

            //  Get the OpenGL object.
            OpenGL gl = openGLControl.OpenGL;

            //create the world grid
            worldGrid = new CWorldGrid(gl);

            //our vehicle made with gl object and pointer of mainform
            vehicle = new CVehicle(gl, this);

            //our NMEA parser
            pn = new CNMEA(this);

            //create the ABLine instance
            ABLine = new CABLine(gl, this);

            sw.Start();//start the stopwatch
        }
ABline, vehicle etc need the gl context in order to initialize so they need to be all in one place
 

·
Registered
Joined
·
4,005 Posts
Oh right. It just needed to be after the InitializeComponents call. Got it!

So another error in that little code I posted. Make it:
Code:
                        if ((hitchNorthing - prevToolNorthing) != 0 ||
                            (hitchEasting - prevToolEasting) != 0)
I got velocity calculations working. I stuck it in SerialComm, before the calls to turn on the section. I thought about putting it in the Section class, but that's not really used unless the isJobStarted is true and isMasterSectionOn is true. One problem I see is that this area of the code only executes if a certain distance has passed. Thus sometimes when you come to a stop, a lot of time elapses so I have to probably use the Stopwatch, rather than assume each pass through is 1/rmcUpdateHz seconds long.

Also I've noticed some problems with the sections and low speed. For one I can't seem to turn on the master switch and have it start to automatically turn on sections unless I do it above the threshhold speed. I haven't had opportunity to look into this. I also had a couple of situations where one section wouldn't come on when it was supposed to, but when hit the master button, it suddenly laid down a large block of coverage (after I turned it off). I think this also has to do with the thresholding logic for reducing triangle count.

At some point I would like to add an option to have the automatic control shut down sections when they come to a stop. Related to that, I would like to be able to turn on the master while stopped, but have it not turn on the sections until I start moving. That's what I often do on my Raven SmartBoom.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #211 (Edited)
I was just playing around driving in circles. You can literally have 1 or 2 or 3 sections and in one section one end of the section is going forward, the other end backward and the middle of the section standing still. What should be used for lookahead? No wonder its not really used in commercial stuff, its an extremely difficult solution as there seems to be no right answer.

I think the practicality needs to be figured out before the code. Define the possible movements and then do the tradeoff of how accurate we want it to be. Given the above in many circumstances there is no right answer.

Do you like the section control button logic? Did i miss anything?

In regards to your section off on, working on the buttons, the old button logic had issues when standing still and section requests were being made. while i haven't ran it enough to confirm it works perfectly, it works pretty good.

Putting updated version on Github. Give it a try.
 

·
Registered
Joined
·
4,005 Posts
Haven't look at your latest code yet, but I shall. I'll have to merge or stash the changes I made and get things synced up again. I'll have to likely make changes to my section speed calculations based on your newer logic.

As for individual sections, if I had a speed for each section plus a direction vector, then lookahead could be either ahead of the bar or behind, depending on the vector when compared to the fixHeadingSection. And when it comes to spraying, really, anytime the boom is at zero speed or going backwards, it could be turned off. In fact in most cases I can't think of any reason I'd want the section on when that section is moving backwards relative to the direction the toolbar is facing.
 

·
Registered
Joined
·
4,005 Posts
Okay I pulled in your changes. Sometimes git is pretty slick when it comes to merging branches.

I like the concept of how you have the manual buttons. It operates a bit differently than I was originally thinking, but I think I like the basic logic in it, though part of the interaction between buttons confused me at first, especially the state of the master section on-off button.

Here's an idea. For the two main buttons, how about changing them so that the top button toggles between master auto on and manual on, and the bottom button is simply, "off." Pressing the top button once engages full auto mode, what you want most of the time. Pressing it again, turns it to manual, and again, back to auto. Just like it works now. But the bottom button has only one function, and that is off, which turns all the booms off and resets the individual section states to off/auto, regardless of whether they were auto or manual on before.

The individual section buttons will work as now.

thoughts? Think I'll sleep on it.
 

·
Registered
Joined
·
6 Posts
A very impressiv project Brian and torriem!
I
I have a question regarding what open GL version is needed. I run 3,1 and as soon as I connect a Agsim signal the screen turns whit whit a red cross.

Tia Linder
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #215
A very impressiv project Brian and torriem!
I
I have a question regarding what open GL version is needed. I run 3,1 and as soon as I connect a Agsim signal the screen turns whit whit a red cross.

Tia Linder
Welcome to the forum!

So it initially comes up just fine and you can see the main screen and vehicle, buttons etc? And as soon as it gets gps info it goes red x?

What is the error code? Or is there an error code? If you hit details does it give a line number and other details on the first line?

It uses old school v2.1. No shaders or anything special in the app. It should just run as that is in v 3.

Try downloading the latest one i put up last night on github. Hopefully that will solve it as it worked great on desktop computers but not tablets.

Hopefully we can figure this out. Can you try it on another computer also?
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #216 (Edited)
Okay I pulled in your changes. Sometimes git is pretty slick when it comes to merging branches.

I like the concept of how you have the manual buttons. It operates a bit differently than I was originally thinking, but I think I like the basic logic in it, though part of the interaction between buttons confused me at first, especially the state of the master section on-off button.

Here's an idea. For the two main buttons, how about changing them so that the top button toggles between master auto on and manual on, and the bottom button is simply, "off." Pressing the top button once engages full auto mode, what you want most of the time. Pressing it again, turns it to manual, and again, back to auto. Just like it works now. But the bottom button has only one function, and that is off, which turns all the booms off and resets the individual section states to off/auto, regardless of whether they were auto or manual on before.

The individual section buttons will work as now.

thoughts? Think I'll sleep on it.
So you hit top button, its in auto. You hit the stop button. Now you want to auto again so did the stop button change it back to first hit auto second hit manual or is the auto manual still in auto which means hitting again its now in manual?

I like where you are going with this. Having an off button. But its the resetting the section buttons again that's tricky.

hit auto, works in auto and all comes on in auto mode. Section buttons say auto and hitting individual sections allow off auto on. So i turn 3 sections to on. Do i have to hit each section button twice in order to resume all to auto? Because if i hit auto its now manual and all sections turn to On. Not at all what i wanted. And so i need to hit it auto/manual again to be auto. Or i hit stop and hit auto again missing a spot.

Edit....., this problem exists in current version too. It is the Kobayashi Maru of buttons!

Its the turning all the sections on trying to get back to all auto may not be a good idea.

Hmmmm

Right now the manual doesn't shut off the auto. But hitting auto shuts off the manual. Perhaps it would be less confusing that when manual is hit, auto goes off, manual goes on. If i hit auto, turns manual off. If you want it off, just hit the one that is on. Or could have auto button manual button and a stop, but since its so obvious which one is on, just hit it. I'll try making that change.

99 percent of the time its just hitting auto on and hitting auto off. Pushbutton style with obvious graphics.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #219
A very impressiv project Brian and torriem!
I
I have a question regarding what open GL version is needed. I run 3,1 and as soon as I connect a Agsim signal the screen turns whit whit a red cross.

Tia Linder
Try the AgSim one i've attached to this reply. May something is goofy up on git.
 

Attachments

·
Registered
Joined
·
4,005 Posts
Okay so I got per-section speed calculations working. And using those instead of my yawrate seems to work well. I thought while I was at it I would add logic to shut the sections off when they go backwards. Unfortunately the naive approach won't work, especially when while turning at a nearly-stopped speed. The section tends to turn on and off and can lead to misses. So I think I'll abandon that particular idea.

For section speeds, right now I'm just taking an average from the middle of the section. But I think we'll have to calculate both ends of the boom and take the greatest speed to make sure we can get 100% coverage. Now that I've proved the concept I'll do that.

Right now I am doing the calculations outside of the part of the code that calls addPathPint, but I'm going to try to merge it to eliminate duplicate calculations.
 
201 - 220 of 4139 Posts
Top