There was an AOG version that did this. V4.0 and V4.1 if I remember correctly. The feature was removed in V4.3.
@BrianTee_Admin said to update to 4.3, many bugs in previous, don’t know if it was related to the mapping.
Brian also mentioned that the feature used al lot CPU, so removed to allow lover spec tablets to still run AOG
The number in the pink circle is calculated by (Total area of the field) - (Treated area including overlaps) = Area left to treat if you wouldn’t have overlapped anything. Which means at least for me that it’s kind of useless since I always overlap some. I just know that it will be slightly negative when I finish the field but I don’t know how much.
Not exactly sure what you mean, but I’m after a version that would not count the overlapped parts to the treated area. So the calculation for the number in the pink circle in CVX’s picture would be (Total area of the field) - (Treated area excluding overlaps) = Untreated area on the field.
I.e. that number could never be negative so you would know how much of the field is still untreated.
As others have explained, one would need to calculate overlapped areas to know the true unworked area of the field. Others already explained the related problems. Life is a compromise. I’m not aware of any commercial screen supporting overlap detection. An older version of AOG seems the only one so far that can do it.
Either calculate the overlapped areas as you say or maybe it would be possible to directly calculate the area of the field which hasn’t been worked? If the biggest issue was the need of CPU power then why not make it optional so that you can choose if you want it on or off depending on your laptops capabilities? Don’t you think it would make all the difference if you could see exactly how much you still have undone?
I’m not able to suggest our software experts how to implement this but I don’t think they need instructions on the way to implement this.
There are so many useful features and overlap calculation could be one and could indeed be optional if it helps. Then again, most of us use RTK with auto-steer and overlap does not happen much except at the headlands.
Now if an accurate figure for the undone area is important, should we be able to estimate the overlap for that too?
You’re right, I didn’t understand what you meant. I suppose the total area is calculated with the limit of the plot, if the treated area includes overlaps, what remains to be treated will be greater than the figure indicated by the pink circle. It could be a good option to calculate the overlap to be able to subtract it from the treated area and really get what remains to be treated.
If you use automatic section control, even though its not hooked up, it will prevent counting overlap. It will only paint the first time the ground is covered.
Not quite the same as unapplied area but closer.
Working on it. Top of the screen A is applied area, C is covered area.
Brian had most of this built in a previous version.
Edit: Development Team is way ahead of this. Wait for Version 6.
That’s great news! Can’t wait for version 6!
Farming will likely take priority until late fall. Look for it mid winter or early spring when it is too cold to do anything else in Canada.
So what i understood is to post feature requests here when we have them?
I have a request aswell, my machine is working in a offset to the tractor, meaning it treats the part 1,5 meter besides the tractor instead of straight behind it.
For as far as i could find there is no side offset for implements yet?
Forget that question, it excists, but on the page with the clock on implement settings instead of the measurements symbol.
I put in a max autosteer speed in the Machine control module code. GitHub - AOG-addendum/esp32-autosteer: ESP32 code for autosteer machine control interface Since the code is a fork, the instructions may not work for you.
The max autosteer also activates a buzzer, which doesn’t shut off until a secondary ‘road’ switch is deactivated which kills all power to the autosteer circuit…
The machine offset does exist. Have a look at all the implement settings, perhaps not the most logical place for the parameter.
There used to be some issues with line AB-line selection if the implement offset was very significant relative to the implement width but that issue may have been solved. Try it.
I found it now, indeed it’s not on the spot where i expected it.
Thanks alot!
Hi, I thought of two small improvements:
1: clicking on the tractor when it is in reverse on the screen puts it back in forward gear. wouldn’t it be possible and advantageous to be able to do the opposite?
2 when you open the window for setting WAS, power, etc. by default the window opens on the WAS setting. out often have the rule only once and you don’t touch it anymore. it might be wise for the 1st tab to be Power, which we use more regularly.
I also agree with this, the motor tuning should be #1tab. I’ve accidentally reset the WAS a few times during tuning due to this.