The Combine Forum banner

61 - 80 of 4139 Posts

·
Registered
Joined
·
3,825 Posts
It keeps, either raining or snowing or cold and cloudy. Harvest isn't happening, so a bit more time to play lol.

Just a Lenovo tab2 yoga 10"

Awesome if you could test it.
Yes I was a afraid of that when I saw the impressive change list. Hope you get conducive weather soon.

I'll give it a test on my laptop when I get a chance. Probably Saturday.
 

·
Registered
Joined
·
3,825 Posts
I think a cable like this one may work for most tablets for charging and using a USB device at the same time. Though if it provides enough power to run an arduino while charging the tablet I don't know:
https://www.amazon.com/Micro-Cable-Power-Samsung-AtomicMarket/dp/B009YPYORM

If it doesn't, the arduino can be powered directly. Which might be a good idea anyway, since you'll probably want 12v going into the relays for the section control output signals.

EDIT: No the cable won't work. You can't charge when using USB OTG. But it seems to me a good solution would be a bluetooth to rs232 adapter. Could house it in the same box as the arduino. And actually talking to the arduino over bluetooth may not be so bad either, though a wired connection would be more reliable.

Brian, how are you connecting the tractor's GPS to the tablet? That'd have to go through USB also, right? A hub so you can connect both the arduino and the GPS USB serial adapter?
 

·
Registered
Joined
·
3,825 Posts
Hate to hog the channel here, but I did some searching for bluetooth modules and found this module, which I think would be ideal:
https://www.adafruit.com/product/1588

In fact two of them would probably work. One to talk to the GPS serial line (requires a TTY to RS232 logic converter), and one to connect to the arduino. Then both would show up in the tablet wirelessly. I've found bluetooth pretty reliable, so I think this could work. I'm planning to pick up a Windows 10 tablet in the near future and I think I'll go the bluetooth route, unless it gives problems.
 

·
Registered
Joined
·
5,823 Posts
Discussion Starter #65 (Edited)
I think a cable like this one may work for most tablets for charging and using a USB device at the same time. Though if it provides enough power to run an arduino while charging the tablet I don't know:
https://www.amazon.com/Micro-Cable-Power-Samsung-AtomicMarket/dp/B009YPYORM

If it doesn't, the arduino can be powered directly. Which might be a good idea anyway, since you'll probably want 12v going into the relays for the section control output signals.

EDIT: No the cable won't work. You can't charge when using USB OTG. But it seems to me a good solution would be a bluetooth to rs232 adapter. Could house it in the same box as the arduino. And actually talking to the arduino over bluetooth may not be so bad either, though a wired connection would be more reliable.

Brian, how are you connecting the tractor's GPS to the tablet? That'd have to go through USB also, right? A hub so you can connect both the arduino and the GPS USB serial adapter?
Yes, a powered hub specifically. Then the arduino can be easily powered by it too.

https://www.iogear.com/product/GUH304P/
 

·
Registered
Joined
·
5,823 Posts
Discussion Starter #66
Hate to hog the channel here, but I did some searching for bluetooth modules and found this module, which I think would be ideal:
https://www.adafruit.com/product/1588

In fact two of them would probably work. One to talk to the GPS serial line (requires a TTY to RS232 logic converter), and one to connect to the arduino. Then both would show up in the tablet wirelessly. I've found bluetooth pretty reliable, so I think this could work. I'm planning to pick up a Windows 10 tablet in the near future and I think I'll go the bluetooth route, unless it gives problems.
I got one of these but haven't played with it much, its 10$

RS232 Bluetooth Serial Adapter Communication Master-Slave Module 5v mini usb | eBay
 

·
Registered
Joined
·
318 Posts
Several updates. Step 2 of xx was to get actual relay control. Working pretty good. v1.2 will be up on Github soon including Arduino ino project.

So, total cost, a 200$ tablet, a 22$ USB to RS232 cable, a 25$ Arduino Uno, a 15$ 8 channel relay board, few hookup wires.

* Fixed the RMC and GGA parsing routine, rather then reading an NMEA line and then updating, read all existing lines and process all at once.
- much faster accumulation of data
* Changed OpenGL draw routine from being triggered when RMC rec'd to 5 frames per second and triggering functions from there.
- three seperate threads - GPS Serial IO and decoding NMEA stream, sectionRelay serial IO, Draw routine.
* Ability to save and retrieve fields
* Changed the Section tab to remove clutter with less sections
* added section on and off request in section control. Allows the section to delay turning off and when turned on to remain on for 2 secs minimum.
* Fixed fonts consistency
* Added bottom status bar - looks way better in Linux
* Added Arduino serial port to control sectionRelays
* Output the section on off status to Arduino for full external control of sections
* Added port selection to choose port for sectionRelays.
* added hitched or rigid in vehicle
* added antenna height in vehicle
* added port status in status bar
* added distance reset in status bar
* fixed section drawing so it uses section position rather then fix position to end section drawing
* added a guidance page to set overlap
* fixed bug in section control loosing accuracy from converting double to int too soon. (missing a pixel or two)
* other miscellaneous changes

A little video. As usual click on the YouTube and watch in there is higher resolution

https://youtu.be/5eXMUupVtqE
Wow...awesome work. This is something else. Is it going to be much work to adapt it to a 3 or 5 section implement (pull type sprayer)? Is towed implement modelling on the cards? Excellent work anyway...I wish I had the smarts and skills to do something like that...
 

·
Registered
Joined
·
5,823 Posts
Discussion Starter #68 (Edited)

·
Registered
Joined
·
3,825 Posts
I hadn't thought of that either. That would eliminate the need for the arduino entirely. Though I can see a use for the arduino-controlled relay still. The arduino could do additional I/O things like monitor physical toggle switches switches, or take input from a remote work switch, like I have on my air drill, and communicate that back to AgOpenGPS. Guess you could support different switching units in your config.

Also an Arduino plus the BT serial adapter and the relay board isn't much different in cost than this all-in-one bluetooth unit, so for my setup I'll stick with the arduino for now I think. Plus I'd like to implement a mosfet switching system instead of mechanical relays.
 

·
Registered
Joined
·
3,825 Posts
I'm working on an algorithm for approximating the implement position during turns. Basically I've considered two methods, one which over-estimates the turn and one which underestimates the turn. I've attached a picture showing the two approximations. The one on the left shows a path that is underestimating the swing of the implement, and the one of the right shows a path that is over-estimating the swing. The path taken is the path of the hitch pin, not the tractor or GPs receiver.

Both algorithms are pretty much the same computationally, and both actually converge on the real theoretical path if you chop the path up fine enough. At an update frequency of 5 Hz, I think you'd get a pretty good approximation. You could get an even better curve by taking each position update and chopping it up into even more intermediate steps. This algorithm would also work for multiple implements (ignoring side-slip) just by chaining the calculations. Here's how it works in abstract. Implement pivot is the point at which the implement pivots (center of a single axle). Hitch length is the length from that pivot point to the hitch pin.

Under-estimating:
Given a new position for the hitch pin, find a line that is hitch length long between the new hitch pin position and the line formed by the former implement's pivot point to former hitch pin position. This intersection is the new implement pivot position for the next iteration.

Over-estimating:
Same as under, but instead of using a line from former pivot to former hitch position, we make the line be former pivot position to current hitch position.

This algorithm has edge cases that have to be solved yet. The intersection point by definition has two places on the line it can intersect; only one of those makes sense.

I'm working on the algebra to do the calculations. One advantage I see to this algorithm is that it has a built-in smoothing effect on the implement position and angle and that the implement angle is not dependent on the heading the GPS unit provides, once you're under way. I've noticed on my New Holland computer monitor when just mapping work that as the tractor sways a bit while driving that the work line tips back and forth a bit as the coverage is mapped. For doing sectional control that is not good to have.
 

Attachments

·
Registered
Joined
·
318 Posts
Can you run multiple things on Bluetooth at the same time? Ie the relay module for boom switching, GPS antenna and maybe an arduino for controlling autosteer (possibly in the future?)

I was thinking of maybe an arduino for controlling something along the line of the ontrac 3 motor or an ezy steer. I know when I was working at gps ag, we had an autofarm a5 screen, receiver and sa module running an ontrac 2 motor and it worked fine.
 

·
Registered
Joined
·
3,825 Posts
Okay I have been doing some testing in Python, and I think I've got a simple algorithm down that should work even in the tricky cases like when the implement is pushed backwards by the tractor on a tight turn. Turns out that the over-estimating method works just fine, especially if the distance traveled between calculations is very small (which it will be on a tractor). And it's way simple. Once an implement position is calculated you can easily calculate the implements heading along the line between it and the hitch pin.

I prototyped the algorithm in Python and I think I'll post the straight python code here, since it's pretty clear. But you should be able to easily translate it into C#
Code:
def new_implement_position(hitch_len, old_imp_pos, old_hitch_pos, new_hitch_pos):
    """
        Given a hitch length, the old implement pivot position, the old
        hitch pin position, and the new hitch pin position, calculate an
        approximation of where the implement will now be.

        Parameters
        ----------
        hitch_len: float
                   The distance between implement pivot point and
                   hitch pin
        old_imp_pos: tuple of two floats
                     The x,y location of implement pivot point
        old_hitch_pos: tuple of two floats
                       The x,y location of hitch pin
        new_hitch_pos: tuple of two floats
                       The new x,y location of hitch pin
        returns: tuple of two floats
                 The new x,y location of the implement's 
                 pivot position, usually the center of the
                 single axle.
    """
    # Define a line between the old implement pivot position
    # and the new hitch position
    x1 = old_imp_pos[0]
    y1 = old_imp_pos[1]

    x2 = new_hitch_pos[0]
    y2 = new_hitch_pos[1]

    # calculate where on this new line to place the new
    # implement pivot position.
    t = hitch_len / math.sqrt((x2-x1)**2 + (y2-y1)**2)
    x = x2 - t * (x2 - x1)
    y = y2 - t * (y2 - y1)

    return (x,y)
And if intermediate extrapolations are required, this function uses the above function but with an arbitrary number of intermediate steps to increase accuracy.
Code:
def new_implement_position_steps(hitch_len, old_imp_pos, old_hitch_pos, new_hitch_pos, steps=10):
    """
        Wrapper function that calculates a number of intermediate
        steps between old_hitch_pos and new_hitch_pos and performs
        implement position calculations for each step. This causes
        the approximation to become more accurate to the actual
        expected draft of the implement, ignoring side forces that 
        might cause it to slip or drag during a turn.

        Parameters
        ----------
        hitch_len: float
                   The distance between implement pivot point and
                   hitch pin
        old_imp_pos: tuple of two floats
                     The x,y location of implement pivot point
        old_hitch_pos: tuple of two floats
                       The x,y location of hitch pin
        new_hitch_pos: tuple of two floats
                       The new x,y location of hitch pin
        steps: integer
               The number of intermediate steps to use in calculations.
               The larger the number the more accurate the calculation
               will be, but will consume more time. Depending on GPS
               update rate, not very many steps will be required.
        returns: tuple of two floats
                 The new x,y location of the implement's 
                 pivot position, usually the center of the
                 single axle.
    """



    x1 = old_hitch_pos[0]
    y1 = old_hitch_pos[1]

    x2 = new_hitch_pos[0]
    y2 = new_hitch_pos[1]
    for ti in range(1,steps+1):
        t = ti / steps
        x = x1 + t * (x2-x1)
        y = y1 + t * (y2-y1)
        old_imp_pos = new_implement_position(hitch_len, old_imp_pos, old_hitch_pos, (x,y))
        old_hitch_pos = (x,y)

    return old_imp_pos #actually it's the new position now
It's doubtful this second function is that necessary. I used it in testing and for very large gaps between position updates it does make it quite accurate.
 

·
Registered
Joined
·
3,825 Posts
Can you run multiple things on Bluetooth at the same time? Ie the relay module for boom switching, GPS antenna and maybe an arduino for controlling autosteer (possibly in the future?)

I was thinking of maybe an arduino for controlling something along the line of the ontrac 3 motor or an ezy steer. I know when I was working at gps ag, we had an autofarm a5 screen, receiver and sa module running an ontrac 2 motor and it worked fine.
Yes you can. the total bandwidth is shared, but it's something like 1 MBit/s. Each serial bluetooth device you pair will show up as its own serial device on Windows.

I have found bluetooth to be fairly reliable, but for really critical things do we want to rely on it? Guess we'll have to test it and find out.
 

·
Registered
Joined
·
318 Posts
Yes you can. the total bandwidth is shared, but it's something like 1 MBit/s. Each serial bluetooth device you pair will show up as its own serial device on Windows.

I have found bluetooth to be fairly reliable, but for really critical things do we want to rely on it? Guess we'll have to test it and find out.
Yeah I can see why pretty much all precision ag gear is run on cable...because it is so easy to troubleshoot and unless there is a break in a wire it is pretty bulletproof. If the serial cable is going to be the chosen path the next step is getting enough com ports to allow coms between receiver and autosteer and section/rate controllers.
 

·
Registered
Joined
·
5,823 Posts
Discussion Starter #76
Yeah I can see why pretty much all precision ag gear is run on cable...because it is so easy to troubleshoot and unless there is a break in a wire it is pretty bulletproof. If the serial cable is going to be the chosen path the next step is getting enough com ports to allow coms between receiver and autosteer and section/rate controllers.
They have lots of ports!

Torriem, so would you consider then.... Atan2 (x2-x1,y2-y1) to be the orientation of the implement?
 

·
Registered
Joined
·
3,825 Posts
Yes, though just remember that Atan2 returns angles that start with 0 along the x axis and goes counter clockwise. To convert that to a compass angle you would do something like:
Code:
(-Atan2(x2-x1,y2-y1) * 180 / pi + 90) % 360
where % is the modulus operator.

I'm not totally certain how to calculate the position of the hitch pin relative to the GPS receiver. Probably the simplest way is to just measure relative to the GPS heading angle even though that's not quite right (the tractor is turning, so the heading isn't going to be in line with the vehicle).

I just thought of an additional complication. If the trailer has a steerable front axle, it follows completely different from a trailer with a fixed axle. In the steerable configuration, it's kind of like two trailers. I'll think about how to model that.

Also, Brian, how do you handle reverse right now? The reason I ask is because my Raven Smartboom is really stupid about it. When I reverse it just assumes that everything is turned 180 degrees and that the actual sprayer is then in front of the tractor as I back up. If I forget and don't stop the raven while backing up, it messes up my coverage when I go forward again. I'd hope that you could make some logic that if there is a near 180 degree heading change rather quickly that this means we're in reverse and that the implement is still behind the tractor and thus in an overlap situation.

EDIT: I found an edge case in my algorithm that has to be dealt with. There's always a chance that the new hitch pin position will be exactly the same as the former implement position, which would result in a divide by zero fault. To handle that I added a check to see if the positions are the same. It's floating point, so it's best to use an epsilon comparison instead of equality, and we can pick a reasonable value for an EPSILON like say a few centimeters. Then we calculate the new X and Y position using the former hitch position:
Code:
    if abs(x2-x1) < EPSILON and \
       abs(y2-y1) < EPSILON:
        # if the new hitch position is exactly the same as the old implement
        # position, extend our line along the same slope as the old hitch 
        # position to old implement position

        x = x2 - old_hitch_pos[0] + x1
        y = y2 - old_hitch_pos[1] + y1
 

·
Registered
Joined
·
3,825 Posts
Tested the latest git pull in the yard and it worked pretty well for the most part. I left on the GGA and VTG sentences I need for my other applications, and added RMC. AgOpenGPs seemed to handle the extraneous data. Unfortunately torwards the end of my test, the tractor on the screen just stopped moving. I know GPS data was still flowing, but AgOpenGPS wasn't updating for whatever reason. The GUI was still responsive and I could turn it on and off. I think there was still some problem parsing the data. Maybe a buffer got full.

I also noticed the heading sway problem. First off, when starting the program but before moving, the tractor spun around in in different directions on the screen. Once I started moving it figure out where it was heading and settled out. But I still got quite a bit of small heading variations as I drove. The lower the speed the more pronounced the wobble, which is reflected in the coverage. The implement algorithm I worked on would certainly help with this, but maybe you need some averaging and smoothing. Something like:

Code:
alpha = 0.95 //pick a suitable value
heading = alpha*new_heading +  (1-alpha)*old_heading
I ordered a tablet off Amazon (the iRulu Win10 tablet for $113), so I hope to have a setup to play with soon.
 

·
Registered
Joined
·
5,823 Posts
Discussion Starter #79 (Edited)
Tested the latest git pull in the yard and it worked pretty well for the most part. I left on the GGA and VTG sentences I need for my other applications, and added RMC. AgOpenGPs seemed to handle the extraneous data. Unfortunately torwards the end of my test, the tractor on the screen just stopped moving. I know GPS data was still flowing, but AgOpenGPS wasn't updating for whatever reason. The GUI was still responsive and I could turn it on and off. I think there was still some problem parsing the data. Maybe a buffer got full.

I also noticed the heading sway problem. First off, when starting the program but before moving, the tractor spun around in in different directions on the screen. Once I started moving it figure out where it was heading and settled out. But I still got quite a bit of small heading variations as I drove. The lower the speed the more pronounced the wobble, which is reflected in the coverage. The implement algorithm I worked on would certainly help with this, but maybe you need some averaging and smoothing. Something like:

Code:
alpha = 0.95 //pick a suitable value
heading = alpha*new_heading +  (1-alpha)*old_heading
I ordered a tablet off Amazon (the iRulu Win10 tablet for $113), so I hope to have a setup to play with soon.
I've done a lot of changes to the serial ports and how they work. In terms of your display wiggling back and forth, the data you feed it is the data it shows. There is a bit of smoothing. Just goes to show you how much retail products filter. I should have a setting for how many fixes you want filtered. Its tricky because with lower (like 1 hz) it takes forever to update and then at 10hz its way to fast. I'll add a setting.

I store the previous 40 fixes in a buffer. To average them all that happens is you take the average from the last 3 or 5 or 20 buffers depending on how filtered you want. Its basically a digital low pass filter. At the next fix, they get bumped down the line like a shift register as new values are added.

There is also on my git a pgm called AgSim that can simulate RMC and GGA. You can either use a virtual port emulator on 1 computer and you don't even have to go anywhere. Or, have two usb to Rs232 adapters just connected to each other via a null modem cable. Source included.

Edit. Remember a ways back the display wouldn't update the speed or screen if you were going slow but never moved when going slow? What it had was it needed a minimum distance to travel before updating the screen. I took that out so there was always updates. But this is no good either!

This was to prevent spinning in circles like it does now when standing still. I will have to put back in, easy fix.
 

·
Registered
Joined
·
3,825 Posts
Yes, a moving average makes sense I think. Regardless of how many fixes you average, it shouldn't affect the speed of update. If fewer samples are in the buffer, you can just average over what you have. Haven't dove into the code yet, so you probably are already doing this. An option to specify how much averaging you want may be a good thing, like you say.

I've been wondering if a Kalman filter would be the best way to go to smooth out the heading data. It responds a lot quicker than a moving average, though it has the same effect. I just spent a few hours this afternoon watching some very good lectures on Kalman filters. Very enlightening. A Kalman filter will not only have the effect of a moving average, but it can also track the rate of change of a value and make pretty good predictions. Also applying a kalman filter to the actual position fix would let you get more fix updates per second if that was ever required.

As for the minimum speed thing, I think you could do this still. If the machine drops below the threshhold, just stop processing updates. In other words, once you're stopped the heading would just stay at its last value. That way the tractor won't spin in circles. It might not be pointing the right way on the screen, but it shouldn't matter.
 
61 - 80 of 4139 Posts
Top