One of the biggest challenges is knowing what direction you are going - but the vehicle is standing still with the heading spinning around in all different directions. Also, how to back up. This video goes into detail about finding the heading and a bit on using the debugging on code and stepping thru it. Its a 3 beer video for sure.
4 Likes
Wow, Great work!
For AGO to automatically find out if the tractor is starting forward or backward it would have to read acceleration from an IMU? And compare with his data to validate the direction.
Would this slow acceleration be detected by the sensor you are testing? BNO08x, CMPS14?
Should you add a value for acceleration in the IMU PGN if someone want to try to implement it later?
A button for switching direction is good enough for me if I start backward, but it’s just an idea for the future!
I worked with a JD GPS and sometime it was backward for a while at startup, eventually switching in the right direction.
2 Likes
But for people without an imu you would need all different code. Normally a tractor isn’t as slow as the sim shows for taking off, it appears almost immediately to move as it hits 2 kmh very quickly - and those 3 initial fixes are done in 1/3 of a second a 10hz.
Might be tricky figuring out whether it is decelerating in braking or actually backing up. Always a catch
Yeah looking for acceleration in these 3 first steps seem almost impossible to figure out.
And different sensors is also a big challenge.
It could be something in the code looking at the GPS step while moving and if it detect a great acceleration or braking it compare to the acceleration value. If it 10 time in a row in the false direction it would correct it. If no IMU acceleration data, no comparison and correction.
I am not saying you should try to, this just some ideas(again sorry for my bad English), it is probably better to just press a button to correct the direction instead waiting of the computer to make it.
The worst would be this data making switch the vehicle the wrong side!
I the commercial system I was using I know how this could be corrected, probably by braking and accelerating. It was just used for mapping the yield so it was just funny to see the little combine on the screen going backward while harvesting!
For the IMU PGN output it would be nice to have maybe two more data as provision (right now you are planning only heading and roll?), I am thinking for acceleration an yaw?(tilt forward/backward)(in my case for surveying), just two number set a 9999 by default that could be used for anything. In aog it could be stored as imuValue1, 2 even not used yet. So I could use the same arduino code for the real AOG or some modified. Just for me or other wanting to be dangerous and playing in the code!
In the video you are using Drive? If this available somewhere?
Thanks again for all your tremendous work!
IT will be once i finish the 8 million changes. The idea with Drive is to test ideas with not a lot of features to get in the way. Ideas exactly like you are talking about.
With the new PGN structure it is variable length so we can add as many bytes as needed.
Wow! Thanks for the video. I had no idea that visual studio would do all of that. I always did a console.writeline to fine out what values I had. Old school days in fortran. We never new what was going on until something busted. Thanks again.
2 Likes
Detecting whether the tractor is going forward or backward is fairly easy and can be done with 100% certainty. Nano still has free pins, you can use them:
- check the position of the reversing lever
- by means of 2 inductive sensors and a disc on the road wheel, it is possible to determine in which direction it is rotating
- with a cheap Doppler sensor the direction can be determined in relation to the ground
Mikrofalowy czujnik ruchu HB100 - efekt Dopplera Botland - Sklep dla robotyków
I know it takes a little bit of extra work, kables etc. But if it worked well it isn’t that much. For me, it’s easier to connect to the reverse lever than to build a dual GPS.
Well that is the point of the software, simple single antenna installation you need anyway to determine reverse without any extra parts. Totally realize that a sensor would “easy” but then you would need something different for every tractor.
3 Likes
My thought, for what it is worth:
Simple single antenna installation:
Always assume forward unless you know otherwise. You can allow the operator to reverse on the screen (most will not care if the screen is showing the tractor backward a few frames while at the end of the row or hooking up.) If the heading has changed drastically you could auto swap (setting in the buttons). For the very slow spins, do not check heading until the tractor has moved farther than the GPS accuracy will allow. There will be jumps in the screen. That is the price of using a single antenna. What you have done is great for single antenna.
Dual Antenna:
That is what the people use that don’t want to see that little jump in the screen. Or want real guidance in reverse.
When we buy software, it usually comes with a list of things that you need to do. You pay more for the more options that you get. On one side it has options and then columns of software and prices. Free, Business, Professional. What we would have is, Cheap GPS, GPS with Corrections, Dual GPS. In the options under Dual GPS there is a check in the reverse monitoring.
Just my thoughts.
3 Likes
Also wont cover cases where you turning on hills / ends etc where you just dip a clutch and let the tractor roll etc.
You don’t need reverse monitoring with dual antenna. It is always there.
So why wouldn’t you want autosteer in reverse or at least the ability to show on the screen you are backing up regardless of the antenna?
2 Likes
@BrianTee_Admin I think you are right, at least for me the ability to show on the screen I am backing up with a single antenna is awesome.
I was planning to build a dual antenna setup just to have the correct visual while backing up but no more needed soon!
You are also right about the software being able to run without a lot of sensors.
I was running autosteer all summer without IMU corrections(BNO055) only Ardusimple RTK.
Also used it as visual reference for spraying corn (just to find the correct row on headland) on an other tractor, just install the tablet, plug the GPS and put the antenna on the hood!(yes a metal hood)Easy!
1 Like
Correct, Dual it is always there.
Just stating that it should be fine or expected to have a screen jump or sometimes see the tractor backwards running a single antenna. Reverse guidance would be great with a single antenna. But it may take user input from time to time to correct the direction, may not. The video looks very promising that it already may be solved.
Would accelerometer output not be useful for low latency initial direction indication? We already have the sensor hooked up to the system.
…or am I missing something?
Only thing I think is missing is calculation to account for Magnetic variation for the specific location. MagVar is not static but “variable over space & time” so depends on level of accuracy required as to amount of code to correct the output from the IMU.
If you can figure out how, it can be used. Stuff like that is deceptively hard
I certainly don´t understand all in this and can´t program, but it seems that OpenCPN has the ability to handle manual input of heading, and use it together with NMEA 183 sentenses.
https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:advanced_features:nmea_sentences#opencpn_does_not_use_or_recognize_nmea_2000
Where they write this:
OpenCPN Core Program:
Normal prefix: “$” however AIS prefix: “!”
Recognized NMEA0183 Sentences
HDM - Heading, Magnetic
Heading Degrees, magnetic
M = magnetic
HDG - Magnetic heading, deviation, variation
Magnetic Sensor heading in degrees
Magnetic Deviation, degrees
Magnetic Deviation direction, E = Easterly, W = Westerly
Magnetic Variation degrees
Magnetic Variation direction, E = Easterly, W = Westerly
If HDG message also contains the variation and E/W flags then O will use that. If not then it will look in RMC message for a variation. If nothing there it will use WMM plugin unless user has selected the variation manually in options.
HDT - Heading, True
Heading Degrees, true
T = True
RMB - Recommended Minimum Navigation Information
To be sent by a navigation receiver when a destination waypoint is active.
‘’
14
1 2 3 4 5 6 7 8 9 10 11 12 13| 15
| | | | | | | | | | | | | | |
$–RMB,A,x.x,a,c–c,c–c,llll.ll,a,yyyyy.yy,a,x.x,x.x,x.x,A,m,*hh‘’
And this:
On the OpenCPN homepage they also have a link to this:
HCD - Heading and Deviation
Actual vessel magnetic heading, indicated compass heading and the difference (deviation) between them.
The use of $–HDG is recommended.
$–HCD,x.x,M,x.x,H,x.x,a*hh
Magnetic deviation, degrees E/W1
Compass heading, degrees
Magnetic heading, degrees
Found here: https://www.nmea.org/Assets/100108_nmea_0183_sentences_not_recommended_for_new_designs.pdf
Edit: I forgot this link: GitHub - ian5142/Arduino_CMPS14_NMEA: Connects via I2C to a CMPS14, outputs NMEA0183 HDM sentences via Serial (38400 baud)
All the (I think) recommended NMEA 183 here:
1 Like
I’m struggling with a simple port to ESP32 so I’m not holding out much hope!
EEPROM is causing me grief!
I’ve heard/read it’s different on the ESP, I have never tackled it.
Are you talking about the magnetic north declination (difference from geographic north pole)? I’m not sure that’s all that important. We can already compute the real heading from GPS. The difference between magnetic and true north can be calculated on the fly based on that, and then the magnetic heading just helps us determine changes in heading more quickly, does it not?