The Combine Forum banner

81 - 100 of 4139 Posts

·
Registered
Joined
·
5,856 Posts
Discussion Starter #81 (Edited)
Works good now, took it for a real world muddy spin in the truck. "sprayed" 10 miles and no problem.

The little number counting from 0 to 0.3 or displays -1 is the distance checker at slow speed. if speed is greater then 2 kmh then distance since last fix is ignored (-1). If less then 2 kmh then record the last know fix position and keep calculating distance from there to the new current position. If its more then 0.3 meters, allow the screen to update to new position. Save the new fix position as previous position, start all over. This previously was messing up the section control, but now each runs on its own independently.


Edit. No amount of averaging fixes the slow speed issue. it will just spin in circles less frequently lol

Kalman . Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. Tried that in my balancing robot. Nope. No where's near enough education to do it properly
 

·
Registered
Joined
·
4,091 Posts
Great progress! I have Visual Studio installed now, so I can slowly get up to speed on your code and try a few things in the near future.

I think the problem with Kalman is that all the matrix math gets in the way of understanding. I'm starting to understand it a little bit. Whether or not it's applicable to the problems at hand I don't know.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #83
The Arduino code is very simple...


Code:
int inByte = 0;         // incoming serial byte
  
void setup() {
    //Pins 8 thru 12 as output, 8 is LSB
    DDRB = B00011111;

    //PORTB turn off 8 thru 12
    PORTB = B00000000;
    
  Serial.begin(9600);
  while (!Serial) {}

  establishContact();  // send a byte to establish contact until receiver responds
}

void loop() {
  // if we get a valid byte, read analog ins:
  if (Serial.available() > 0)
  {
    // get incoming byte:
    inByte = Serial.read();
    Serial.print(inByte);

    PORTB = inByte;
  }  
}

void establishContact() {
  while (Serial.available() <= 0) {
    Serial.print("X");   // send an initial string
    delay(500);
  }
}
 

·
Registered
Joined
·
4,091 Posts
Brian, if I read the code right, you calculate the heading based on a change in position. Is that correct? Is there a reason you don't use the heading that's in the RMC message, as computed by the GPS? Just wondering. I have no idea if the heading in RMC is filtered in the receiver at all (could be different for every receiver).

I don't think this matters, but VTG sentences provide speed in kph already, so no conversion from knots would be needed. For whatever reason most of the GPS-enabled equipment I have (Raven, NH AFS600) use VTG, rather than RMC. I don't think extra calculations for kph matter at all, but it is just something I was wondering about.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #85 (Edited)
Brian, if I read the code right, you calculate the heading based on a change in position. Is that correct? Is there a reason you don't use the heading that's in the RMC message, as computed by the GPS? Just wondering. I have no idea if the heading in RMC is filtered in the receiver at all (could be different for every receiver).

I don't think this matters, but VTG sentences provide speed in kph already, so no conversion from knots would be needed. For whatever reason most of the GPS-enabled equipment I have (Raven, NH AFS600) use VTG, rather than RMC. I don't think extra calculations for kph matter at all, but it is just something I was wondering about.
I originally used the heading, thought wow this is so easy. Went for a spin with RTK and the heading bounced all over the place and was extremely inconsistent. The individual fixes are much more accurate. Latitude longitude is converted to UTM, then the heading is calculated. It is many magnitudes more accurate. It also has the advantage of being able to calculate heading on the current fix and any one of the previous fixes also. The farther back you go the more stable however now you also have a delay. That's how it gets the tool to react slower then the vehicle. The fix for the tool is calculated farther back in time.

It's unfortunate that there isn't one sentence that has everything. It would make sense for me to use GGA and VTG. What i should do is have it use any available - RMC GGA VTG and just decode and update position etc.

I had to step back in the code, somewhere a bug crept in i couldn't figure out. Stuff like that is frustrating but also is inevitable. I added in settings the ability to set filtering for camera, section and vehicle. It all worked pretty good, but for some reason if the heading spun around it completely messed up section control. Enough "features" now - time to make it stable. Stable version on Git
 

·
Registered
Joined
·
534 Posts
Any idea of compatibilty with older operating systems?
Specifically XP,sp3 .. I have used these older laptops with another notebook based GPS mapping system, and have a few assorted antennas,
vary from one to 10hz refresh, mostly usb, only one is bluetooth ..net 4.0 installed
I installed the current github tonight, however cannot select gps port [blank area], and section control gives odd errors, one section selected,shows two width portions

thanks
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #87
If only one section and say its a 10m boom then the right measurement would be 5 and the left would be -5. I agree not super intuitive, but not sure how to keep the same interface look for all 5 section configs.

If there are no ports coming up, windows can't see them. Can you see them in device manager?

Been doing a lot of changes as of late and as discussed it needs a stable version. That will be done shortly. This is alpha software, but it does work.

Have not tried on XP, does it work?
 

·
Registered
Joined
·
534 Posts
If there are no ports coming up, windows can't see them. Can you see them in device manager?
In other applications, ports show, and GPS reciever data is valid .. in setup the port and baud windows are initially blank, when port box is clicked, word port shows, with one blank box underneath, with baud clicked, word baud shows with several blank boxes underneath, when unselected both port and baud go back to being blank boxes
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #89 (Edited)
In other applications, ports show, and GPS reciever data is valid .. in setup the port and baud windows are initially blank, when port box is clicked, word port shows, with one blank box underneath, with baud clicked, word baud shows with several blank boxes underneath, when unselected both port and baud go back to being blank boxes
Is this on XP?

Are you feeding it an RMC sentence? One of the sentences should say $GPRMC,12345,110.3456,..... etc

Torriem suggested, and is a great idea, most ag stuff uses GGA and VTG so am changing the software to read those sentences primarily, and if RMC shows up only, to use it. But the version on Git uses RMC. If on the main screen in the upper corner you see no sentence, it may not be getting RMC because that little window only shows RMC. Hopefully today a new version should be up that addresses some of these inital limitations. A lot has changed in a short time and unlike Ag Dealers, i admit it isn't running on all cylinders.

From the help:

The files…

All the files to run are in the Application Directory. Run AgOpenGPS.exe to start the program.
Fields are stored in the MyDocuments folder and settings are stored in AppData\AgopenGPS so the application can be run from anywhere.
Connecting…

Connect a USB type GPS antenna to your computer or tablet that outputs an NMEA string. Take note of which port it connects to. It must output RMC and will work with only that.
If you want to see elevation, and more GPS information GGA is required also, but not absolutely required.
Running the App


**** You MUST CLICK ON SAVE to save your changes. If not, it won’t save. *******

Double click the file AgOpenGPS.exe to run the application.
First time it runs it knows nothing about its surroundings so it will say COMxx doesn’t exist and that you need to go into settings. Click OK.
It should pop up and show a grid and single section with vehicle.
Click on Settings -> COM Ports to start setting.
Click Port and choose the right one.
IF you don’t see your Port, click Rescan. If you still don’t, it’s a problem.
Click Baud and choose whatever your antenna prefers.
Click Connect.
**** You MUST CLICK ON SAVE to save your changes. If not, it won’t save.
You should see a stream of letters and numbers in the white text box that previously said nothing. Nothing will work till it shows an RMC stream of lines.
 

·
Registered
Joined
·
4,091 Posts
If I get a chance I'll try it on XP. I have Windows 7 and XP both in virtual machines on my laptop.

I'm currently working on kalman filtering. So far I think I have a mostly working, matrix-based implementation that I am going to experiment with (it currently only deals with position and velocity, not yet acceleration). It wasn't nearly as complicated as it looked. If it works I'll convert it to a non-matrix solution that I'll attempt to add it into AgOpenGPS and submit a patch (pull request). I think for non-RTK GPS, this will be essential. The examples I've seen work with straight latitude and longitude readings, which works not too badly, but I wonder if filtering the UTM coordinates would be better, since lat and lon are not rectilinear coordinate systems.

Anyway I'll head out after lunch and record a bunch of actual paths from my tractor (just dump the raw serial data to disk) and then I'll use that in the filter and see what happens.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #91 (Edited)
Excellent. Been working on two things. The crazy hitch and finishing up the GGA VTG addition. Going thru code trying to eliminate any bugs. I so appreciate you looking at this. A different set of eyes and mind really help.

I think i have a reasonable hitch solution.

One thought on the filtering though is tilt compensation. While the signal may seem noisy, it actually isn't. AgOpen just isn't compensating for it.
 

·
Registered
Joined
·
4,091 Posts
Yes I was thinking about tilt compensation today. Eventually a IMU board on the Arduino could send back tilt data to the tablet for use in correcting the GPS signal, and then send the results of that through the filter. I was going to take a stab at hitch compensation, but I think I'll try to get the kalman filter running and converted to C#.
 

·
Registered
Joined
·
4,091 Posts
Nice link. I'll definitely keep that for future reference. It's very clear and shows how simple the kalman filter is, at least in one dimension! In its simplest form, it's essentially a complementary filter.

As far as GPS data goes, it's at the very least 2-dimensional (latitude and longitude). And from a kalman filter point of view, GPS data is 6-dimensional. We track x & y position, x & y velocity, and x & y acceleration. But the nice thing about the kalman filter is that the math is the same even with additional dimensions. If we were to track the z axis (height) we could add another 3 dimensions for that even. I was running the filter with just 4 dimensions (x & y position and velocity) but I decided to add additional dimensions for acceleration because I found that while I could ask the filter for intermediate estimates of position between GPS data points, I couldn't ask it for velocity. So I added acceleration and now I can at any time ask the filter for a prediction of position and speed, even between GPS updates. (mind you this is all in python code that is processing a NMEA text file I created from my tractor at this point).

Remember how I said it AgOpenGPS was working fine and then it suddenly stopped? I discovered why while looking at this text file dump. For whatever reason, every so often a bunch of non-NMEA messages and codes come through the serial off of the GreenStar receiver. All of these messages begin with a ^B and appear to end with a ^C. Sometimes they talk about parity error, or other things. I'll see if I can address this issue in the C# code in the near future. I think it's just a matter of skipping unrecognized bytes or bad input until we get to a clean NMEA marker. This would be good to do anyway, because serial lines can lose data, and someone could plug or unplug it while AgOpenGPS is running and it should react gracefully to it.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #95
Remember how I said it AgOpenGPS was working fine and then it suddenly stopped? I discovered why while looking at this text file dump. For whatever reason, every so often a bunch of non-NMEA messages and codes come through the serial off of the GreenStar receiver. All of these messages begin with a ^B and appear to end with a ^C. Sometimes they talk about parity error, or other things. I'll see if I can address this issue in the C# code in the near future. I think it's just a matter of skipping unrecognized bytes or bad input until we get to a clean NMEA marker. This would be good to do anyway, because serial lines can lose data, and someone could plug or unplug it while AgOpenGPS is running and it should react gracefully to it.
I've spent a lot of time on the serial port lately to make sure it only is decoding what it should. New version, at least i hope, should be even John Deere proof! One interesting thing was given the format is

$GPGGA, 123456,lat, long, xxxxxx *7e \r\n

if the string such as this appeared ... 123456,lat, long, xxxxxx *7e \r\n $GPGGA, 123456,lat, long, xxxxxx *7e \r\n....

it would look for The "$" and the "\r\n" and of course find them ,think it was valid, and try to parse them. Insta crash. :sFun_comp: Or it would just keep adding to the buffer and return from the parsing asking for more sentences as it was invalid. NMEA constipation very quickly.

So now it can be run with GGA and VTG or RMC or all three or just GGA and no VTG but then no speed. Should calculate speed from fixes in that case. Todo.
 

·
Registered
Joined
·
4,091 Posts
I think I was barking up the wrong tree with the kalman filter (as you probably suspected). While the filter works, it doesn't do that good a job of smoothing, and that probably is because the fix information coming out of the GPS receiver is already filtered. The only thing the KF would give us would be an interpolation between fixes, but at 5 Hz update, there're already enough fixes for what we need, at least at this stage of the game. Roll and pitch compensation would definitely be useful, though (and required for auto-steer), and working with IMUs typically require kalman filters. So at least I have a basic understanding of them now.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #97 (Edited)
I think I was barking up the wrong tree with the kalman filter (as you probably suspected). While the filter works, it doesn't do that good a job of smoothing, and that probably is because the fix information coming out of the GPS receiver is already filtered. The only thing the KF would give us would be an interpolation between fixes, but at 5 Hz update, there're already enough fixes for what we need, at least at this stage of the game. Roll and pitch compensation would definitely be useful, though (and required for auto-steer), and working with IMUs typically require kalman filters. So at least I have a basic understanding of them now.
Ya :( Plus any filtering of any sort will always add some delay. The new IMU's have built in Arm processors that do all that for you and spit out Euler vectors, RPY angles, directly. The Smart6L novatels give you roll angles directly in the NMEA stream.

The more i work on this the more i realize how many shortcuts retail boxes take too. For example, in the outback MAX manual, no where do you say if the "hitch" has 2 hitches like a tow between air tank setup for Aft measurement. Even if they "accurately" calculated the tractrix of the implement for a normal hitch it would be completely wrong for an air seeder. Like a video game, make it look pretty and almost lifelike, not necessarily 0.1% accurate.

i'll throw the next version up on Git here soon. The hitch is a disaster, but i'm going to use lookup tables like an ECU does for engine control. If you could try to break the serial input with the JD, that would be great. I made changes in AgSim too, great little simulator for GPS so you don't have to go outside. You just need a null modem cable and 2 usb to Serial RS232 adapters and good to go. Also updated on Github soon.

This program, while time consuming, is sure helping me keep my mind off the fact i have lots left to combine, but watching it snow instead.
 

·
Registered
Joined
·
4,176 Posts
I was going to say even Trimble's execution of an estimation of where the implement is tracking could be better. Draft skew alone on a turn messes with it a fair bit say compared to traveling on the wheels vs in the ground.
 

·
Registered
Joined
·
4,091 Posts
To answer wvca, AgOpenGPs does work fine on Windows XP, with the caveat that the drop-down boxes for serial port and baud rate appear to be white-on-white until you select them (same thing happens on Wine on Linux). But it connects to the serial just fine and I was able to get it to map coverage.

I think I'll have a go at trying my hitch compensating algorithm in AgOpenGPS this evening. I've got a few saved NMEA files that should show whether or not it works. How accurate it is compared to the real tool, that will be interesting. My theoretical testing with graph paper shows it should work with multiple trailers.

I was also thinking that just filtering or averaging the heading angle that the display is using to orient the map will make things look a lot better and just let the real data wiggle and wag however it wants to.
 

·
Registered
Joined
·
5,856 Posts
Discussion Starter #100 (Edited)
To answer wvca, AgOpenGPs does work fine on Windows XP, with the caveat that the drop-down boxes for serial port and baud rate appear to be white-on-white until you select them (same thing happens on Wine on Linux). But it connects to the serial just fine and I was able to get it to map coverage.

I think I'll have a go at trying my hitch compensating algorithm in AgOpenGPS this evening. I've got a few saved NMEA files that should show whether or not it works. How accurate it is compared to the real tool, that will be interesting. My theoretical testing with graph paper shows it should work with multiple trailers.

I was also thinking that just filtering or averaging the heading angle that the display is using to orient the map will make things look a lot better and just let the real data wiggle and wag however it wants to.
If you look in the function UpdateFixPosition you can see how it is presently done where it calcualtes the sectionHeading, cameraHeading, and fixHeading. It doesn't average, it just takes a farther back in time reading to steady out the display. Not sure why yours is so wiggly, could it be the JD output is wiggly? I've used a few different antennas/receiver options - including a 50$ garmin - and it is quite stable.

In regards to the hitch, what you do there also has to be able to be recomputed again for the section control reading of the back buffer opengl window. If you physically move the section away from where the Camera/section headings are pointed, the new camera angles and section angles would also have to be determined based on the new section fixings - and done once for each section. Also all the triangle coordinates that draw the section path would also have to be computed, also at the start of a path, and the end of the path. Its a rabbit hole that's very very deep. Just by only manipulating sectionHeading alone eliminates that. Also since the section isn't in the origin, translations after rotation are also required. Also needs calculation. Something to keep in mind.

It takes very little and you don't see anything in the window and those are very hard to fix. Also, the Z coordinate goes into and out of the screen. X goes left to right, and elevation is Y. In order for anything to make any sense a 0 heading to be like a GPS 0 heading, it isn't like the trig xy plot we are all used to - along the positive x axis, for GPS it goes positive Z axis into the screen. Also, GPS starts at the north and goes clockwise increasing degrees around the circle, and as you know sin cos in normal trig xy works the opposite. The camera is backwards to all that, because, well, its a camera so to move forward you move backward.

So after all that, the only answer needed for all the hitch calculations is what is the the heading of the section vs the heading of the vehicle for the next fixPosition. Because all the section math and display and camera angles and section control back buffer and section path display is all calculated from sectionHeading and not the other way around. For a rigid hitch like a high clearance sprayer, sectionHeading = fixHeading. Pretty simple eh?
 
81 - 100 of 4139 Posts
Top