I was planning on using a separate nano than the steer module. Seperate nano, separate box, then usb to tablet .
Yes then use the one called IMU_USB in the Arduino folder. I use it - works great. Was written about a year ago and is rock solid tested as it did all the testing for v5.
This method using a separate nano is the best method to get the imu data into AOG fast and without waiting for the autosteer module to reply.
I just downloaded V5.3 for the first time. Canāt find the arduino folder or the IMU_USB
Download this source code, inside in support folder.
Thank Vili, that helped
Thanks had mine on the board and it worked good %98 of the time but it would randomly jump say 15 degrees, so hopping a separate box will fix the jump.
For test I mounted one in the cab floor in the middle above the axle. Tilt works very nice and solid, compass is a little nightmmare. ItĀ“s like you said degrees are jumping more than 5. I think on newer tractors you canĀ“t find a place in cabin without electric wires and metal, so direction is always disturbed. But maybe someone knows a trick or something .
It was with V4.3.1. So I use my IMU Brick on the rooftop for direction, works very stable and the cmps14 down the seat for tilt.
I used a CMPS first and found the same problem.
So I changed to a BNO085 and both roll and direction has been rock solid. ( admittedly only about 100 acres, but promising)
I have it sat in a small plastic enclosure on top of the main box with a hole drilled through to enable the wires to go in the sda/sda etc. (So short wires)
Hello!
What causes the continuous zero change of the slope? I have to reset it every day! Cmps14
Thank you
me not yet, but sounds promising
Just did a quick test, if you run the tare in the game rotation vector mode it seems to do it based on the initial orientation. So if I want to twist the IMU box by 90 degrees, power on with the known orientation and then twist by 90 degrees and tare - voila roll and pitch change places. Also tested with the loose box by placing it in an angle of 45 degrees on the side and works equally well.
Some tests on saving the tare: when saved in gaming rotation mode, it saves everything else but the yaw, so when you reboot as it has no reference of the north, it starts with orientation of zero degrees, but the rest of the axes are saved!
Hello
@nut , @GoRoNb no never tryed: to make my life simplier with BNO code, I prefer to physically orient it with the default orientation.
In Game Rotation Vector, with ou without the tare function, yaw is never referenced to north: because in this mode BNO doesnāt use magnetometer, he cannot know where north is. So at every startup, Yaw will be 0Ā° regardless of the orientation of BNO.
Math
Just tested today with a tared BNO085 with the box tilted 45 degrees and tare in game rotation vector. Works like charm and IMU heading seems rock solid. Also very easy to implement into the code.
The manual is bit vague, but you can save the tare also permanently for game rotation orientation (but not for heading as pointed out above)
A pic of the heretic install:
In therm of code, yes, sending TARE Command to BNO is not very difficult with the library: we just have to feed the shtpData array with good Px data and then use the sendCommand(uint8_t command) function.
I was more speaking about the fact that like for qualibration we need a additionnal .INO dedicade to TARE. The user shall send this special .INO to the arduino. And we need interaction between Arduino and the user : at least the user shall command a āTARE NOWā and a āPERSIST TAREā command.
Perhaps we can add together with a calibration .INO.
Agee. Manual is not clear about Game Rotation Vector: āNote that this only persists the tare applied to rotation vector and geomagnetic rotation vector.ā.
So you confirm that for tilt in Game Rotation Vector, TARE can also be persistant ?
Math
Yeah, I get you. I cheated a bit and just edited the code temporarily into V5 ino so that it tared when I changed the steer settings, that way I could easily see the tilt orientation correct and tare, then change back to normal ino.
And yes, the tare stays even in game rotation vector! Left the thing unpowered overnight to be sure and it still was tared in the morning.
I saw the tare mentioned in literature. A very useful feature by the sound and could make heading even more accurate as it will be referenced on a completely horizontal plane.
I really do fail to see why the CMPS is considered better with all the possibilities of the bare BNO085.
Hello
Ok nice cheat. And if we provide to the users the possibility to tare the BNO085, we also need to provide the possibilty to erase the Sensor Orientation FRS to reset the orientation, if they want to reuse the BNO085 in a standart orientation.
What do you mean by literature ? BNO085 datasheet ?
If fact, I think the tare function of BNO could replace the roll zeroing inside AOG. But for that it will requiered that AgOpenGPS send a command to the Arduino and a modified INO to interpret this command and tare the INO.
But AgOpenGPS will be dependant of the BNO085: not a good solution too.
Perhaps the solution will be to write a sperate software and dedicated INO than can allow the user to:
- Easily launch a calibration procedure, displays calibration status and store calibration
- Then display the angle measurement of BNO085, allow to do a Tare and then store the tare.
But Iām completely incompetent in software development.
Math
Maybe it could just be a calibration ino that shows the 3 axis values on the serial and you send serial commands directly from command line to tare etc.
And yes, gotta check how to clear the tare, if I understood correctly you just write all zeros to the table but havenāt had time to try it out yet.
Can the tare function take some kind of arbitrary zero vector data? Seems to me the ideal way to zero out the IMU would be to do what John Deere does where you drive the tractor straight, stop, measure the IMU, then turn the tractor 180 and place it in the same tracks about at the same position, and take another reading. That way you can determine the IMUās position relative to the tractor without having to find a perfectly level piece of ground.
Caseās method is similar but more annoying. You drive one way on an AB line, have it take a reading, then turn 180 on the same AB line, and then measure the offset on the ground of the two tacks. Then it calculates from that the offsets of the IMU. Deereās method works way better. Maybe they patented it, so Trimble and Case had to do this other method.