Great ! That’s just what i need to test bno080 on my sprayer …
Andreas discovered the CMPS14 which is a custom programmed BNO080. IT uses a dead simple I2C read structure, no library, just sends out heading, roll, pitch in decimal degrees.
In doing some reading from them, the 085, 080, and even the 055 have the same hardware. What is different is the firmware. They custom calibrate the CMPS14 from the factory and allow both the 080 default and factory zero cal to be loaded. I’m getting mine Tuesday in the mail hopefully, and i am super duper pooper excited to try this thing out. A few have been set up in Europe and are working very well.
Hopefully this thing can replace the DOGS, MMA, and brick/055.
4 Likes
Hi
For the desktop tests I used a level shifter for 3v3 I2C to 5v sda / scl from nano. On the autosteer diagram, The mma should also be used in 3v3, but only 330ohm on the lines, Should I do the same for the BNO? or rather use the level shifter …? I plan to pull a wire from the autosteer card to the waterproof box on the roof of my sprayer about 2-3m wire. 5v or 3v3 in this wire? will this have any impact? can anyone answer these questions? or should i be surprised to see if it works or not?
I did a fair bit of work on how to have an I2C link over a few meters. The best and current way I found to do it reliably is with an I2C bus extender. The one I used is the P82B96. You need one on the AOG PCB in the cab and another one in the waterproof box on the roof. I posted a schematic and pictures of the setup a few days ago :
You can use 5V instead of 12V on the bus. The level shifting is also done by the driver, so you can have 5V on one side and 3.3V on the other. Also, I only had unshielded cable at my disposal, but if you can, use a shielded cable grounded at one end to get a better immunity against noise.
With that, you can run I2C anywhere you want on the tractor !
3 Likes
You can also hook in a pair of these and use cat5 or 6 cable to interconnect. The new autosteer board will have something like this. For 10$ pretty good. One at each end and you are good for 30 m or more.
https://www.sparkfun.com/products/14589
1 Like
Worked with the BNO080 this autumn, roll is great. Had a lot of trouble with vibrations with the MMA, but the BNO doesn’t seem to be influenced by them.
Direction stable but I didn’t have enough time to make it point north when I was driving north.
Ended up using the pitch for roll because of the mounting position of the BNO. When I get the
calibration right for the compass, I’ll have to adjust that. Did one calibration and switched off the auto calibration. Should try once with autocalibration perhaps, see what happens.
I bought one when I saw CQuick’s post (Hillside combine installation and the BNO080 IMU)
He calculated the Euler angles in the ino , but the Sparkfun library will give you these as well:
//BNO080 init
if (aogSettings.BNOInstalled || aogSettings.InclinometerInstalled == 3)
{
Wire.setClock(400000); //Increase I2C data rate to 400kHz
myIMU.begin();
myIMU.enableRotationVector(50); //Send data update every 50ms
}
if (aogSettings.BNOInstalled)
{
if (myIMU.dataAvailable() == true)
{
float pitch = myIMU.getPitch();
float roll = myIMU.getRoll();
float yaw = myIMU.getYaw();
yaw_degrees = yaw * 57, 3; //180.0 / 3.14159265
if ( yaw_degrees < 0 ) yaw_degrees += 360.0;
yaw_degrees = 360 - yaw_degrees;
yaw_degrees16 = int(yaw_degrees * 16);
}
}
Works on a Nano with 4.3.10, with 1.5mtr cable and a levelshifter on the BNO side.
2 Likes
I just ordered a bno080 sparkfun board to evaluate as well. I had a very first original 080 - but could never get it to work properly, had lots of firmware issues.
Is there any reason to get the BNO080 when the BNO085 is available with the latest firmware? Of course the only breakout board I’ve seen with the 85 is from Adafruit currently.
The 085 is the same chip i am pretty sure but with all the “consumer” algorithms like step tilt shake etc.
Hey Simon - did you try the serial Robovac mode that comes out on serial? it spits out exactly what we need 100x per second in 1/100 decimal accuracy. HEading, roll, pitch…
Header: Each report is prefixed with a 0xAAAA headerIndex: A monotonically increasing 8-bit count is provided (0-255) per reportYaw: The yaw is a measure of the rotation around the Z-axis since reset. The yaw has a range of +/-180 ̊and is provided in 0.01 ̊ increments, i.e. a report of 8734is equivalent to 87.34 ̊.Pitch: The pitch is a measure of the rotation around the Y-axis. The pitch has a range of +/-90 ̊and is provided in 0.01 ̊ increments, i.e. a report of 1072 is equivalent to 10.72 ̊.Roll: The roll is a measure of the rotation around the X-axis. The roll has a range of +/-180 ̊and is provided in 0.01 ̊ increments, i.e. a report of 1072 is equivalent to 10.72 ̊.X-axis acceleration: The acceleration along the X-axis, presented in mgY-axis acceleration: The acceleration along the Y-axis, presented in mgZ-axis acceleration: The acceleration along the Z-axis, presented in mgReserved: The message is terminated with three reserved bytes, currently set to zeroChecksum(Csum): The Index, yaw, pitch, roll, acceleration and reserved data bytes are addedto produce the checksum.To determine the actual orientation of the module, the rotations should be applied in the order yaw, pitch then roll.An example complete message and checksum calculation is as follows:Message: 0xAAAADE 01 00 92FF 25 08 8D FE EC FF D1 03 00 00 00 E7Where: Index = 0xDE = 222Yaw = 00.01 ̊ (1= 0x0001)Pitch= -1.10 ̊ (-110 = 0xFF92)Roll = 20.85 ̊ (2085 = 0x0825)X-acceleration = -371mg= -3.638 m/s2(-371 = 0xFE8D)Y-acceleration = -20mg= -0.196 m/s2(-20 = 0xFFEC)Z-acceleration = 977mg= -9.581 m/s2(977 = 0x03D1)Checksum = 0xE7
Is the ol’ Nano going to handle 100hz? Maybe the new pcb is moving to something faster…
No Brian, didn’t try the Robovac mode.
I really didn’t pay much attention to it, because I read in the datasheet:
For general applications that require motiontracking in a relatively stable magnetic field it is recommended to use 9-axis sensor fusion outputs (Rotation Vector –see section 2.2.4) from the BNO080.
Because I thought the magnetic field was very imporant, I opted for the Rotation Vector option.
Since that seemed to work quite well, there was no need (and time) to try anything else.
Perhaps I was too focussed on the magnetic field, probably if you place the sensor near electric
leads in the cabin that’s not such a good option, but mine is outside in the open.
Directly into aog is an option…
Do you know if auto calibration is by default on or off with the sparkfun library?
By the calibration example ino I would guess it’s not on by default but I’m not sure.
I’ve added .calibrateAll() and .endCalibration() to the BNO installed part of the machine header AogSettingsFound code.
if (bitRead(sett,0)) myIMU.calibrateAll(); else myIMU.endCalibration();
Pretty certain this will allow me to enable or disable calibration from AOG.
I’ve removed the MMA and BNO055 code so BNO085 heading and roll data is sent whatever the setting in AOG.
I’ve kept the x or Y axis and roll invert options.
I’ve got some tuning to do yet but my first impression is VERY stable roll with no damping or filtering needed.
My test field is that wet and rutted it is hard to tell how well the compass is working.
Alen, Having read the BNO080 Sensor Calibration Procedure sheet (https://xdevs.com/doc/CEVA/BNO080-BNO085-Sesnor-Calibration-Procedure.pdf) again, if I’m correct there’s
actually no autocalibration at all, it states:
The magnetometer is most important when using the Rotation Vector BNO080 output (which
aligns the quaternion output to magnetic north). When using the Game Rotation Vector output
(which aligns the quaternion output to an arbitrary orientation and is not affected by magnetic
perturbations), accurate calibration of the magnetometer is less important.
The magnetometer calibration process will calibrate for the unique magnetic field affecting the
environment in which the calibration process takes place. This includes components that affect
the magnetic field in the headset itself (soft iron effects) like batteries, and objects that affect the magnetic field around the user (hard iron effects) like metallic furniture or speakers. For best
performance, it is recommended that the end-user performs a similar magnetic calibration
procedure when they start using the device in their home and any time that they significantly
change their environment (e.g. after moving the device to a new room) if Rotation Vector is used by the applications.
So you will have to start and stop the dynamic calibration just once in the environment the sensor is used. It should be OK then, so you shouldn’t repeat it everytime you start AGopen,
but:
Hillcrest
recommends that dynamic calibration for the gyroscope and magnetometer be disabled to avoid new calibrations being created during gameplay which can cause unwanted motion artifacts.The gyroscope is automatically calibrated when the device is stable, and the magnetometer calibration is not likely to change significantly if the user uses the device in the same general
There is also the “SH-2 Reference Manual” (https://cdn.sparkfun.com/assets/4/d/9/3/8/SH-2-Reference-Manual-v1.2.pdf) where the BNO is part of the Hillcrest board with some info.
I calibrated mine once with the example code in the Sparkfun package that comes with the library , but found out that if you yaw it very fast (by hand) , it goes off, but there’s no way you can do it that fast with a tractor.
The advantage of the CMPS is it is factory calibrated in a special jig. You can’t come close to that cal doing it by hand.
Hi,
@BrianTee_Admin
As we discuss on Telegram, in my post number 27 (sorry long post but I tried give as mutch as details that I can): I tried UART-RVC mode with an Arduino Due. Also very stable when I do test on the desk by “punching” the desk to simulate vibration.
Adafruit code available to use this mode, realy easier than SHTP over I2C.
I didn’t go futher because I was thinking that we cannot interface this mode with Nano, du to the absence of additional UART on Nano.
In this mode:
- Heading not referenced to magnetic north: heading is zero when you start BNO, so 0° correspond to where “BNO was looking at start”.
- Background calibration is running a specific mode for accelerometer call “planar calibration”: don’t know if it’s better or worst for our application
@Alan.Webb @Simon_1
When you enable the Rotation Vector, the background magnetormeter and accelerometer autocalibration are enable and gyro background autocalibration is disable. You have to enable gyro calibration if you want with: calibrateGyro() or calibrateAll().
HillcrestLab said about the gyro caliibration in Rotation Vector : “For general applications that require motion tracking in a relatively stable magnetic field it is recommended to use 9-axis sensor fusion outputs (Rotation Vector – see section 2.2.4) from the BNO08X. If the device to which the BNO08X is attached provides sufficient tremor then the gyroscope calibration can be enabled. However the user should verify performance with their specific motion profile.”
I’ve edited Sparkfun library to add the possibility to display which calibration is enable. Hop I can post the code soon.
Did you succed to have both magnetometer and GameRotationVector (accelerometer + gyroscope) calibrate ? Both with a status to “High” ?
I never succed to have magnetometer to an other status than “Unreliable” despide repeating the calibration procedure: BNO080: impossible to have a complete calibration - SparkFun Electronics. No problem with gyro+accel: calibration status “High”.
Math
I got medium and high. It did require a bit of lively driving around!
I tried with calibrate all enabled and tonight I have had the old BNO055 compass drift again. Drifting downward whilst completely stationary. It doesn’t always happen but then it didn’t with the 055 either. Sometimes it was perfectly fine.
@ Math:
I had no problem to get three “Highs”, the magnetometer takes a bit more time, but still within a
minute. I think you can’t get it done with the sensor mounted on the tractor, unless you roll it a couple of times.
@Brian:
I believe that when you use Rotation Vector , calibration has to be done in the environment where the sensor has to live to do it’s job, because of the magnetometer. If the CMPS only uses the gyro and accelerometer, I think the factory calibration on the breakout board should be
hard to beat.