I’m looking for a way to eliminate the magnetometer usage from my Minimu-9-AHRS board for comparative test purposes. That is, I want to see the ability of the system to report short-term yaw values without using the magnetometer. Any tips/suggestions would save considerable time trying to discern how to do this by studying the code. I guess you could say that I’m looking for a way to run the same software as would be the case if I only had a gyro/accel board in the first place.
You can cut the sda/scl traces to the onboard magnetometer or remove the piece from the board
Did this, board no longer communicates with the gyro/accel. Also then cut the CS trace, no change. Just wanted to verify that there’s not something else I’m missing. If necessary, I’ll just buy an LMS6DS33 instead and start over. Just looking for your suggestions.
Steve
Hi, Steve.
What you want to do requires some changes to the AHRS software. It is fairly straightforward to make a change that causes the magnetometer data to be ignored by commenting out lines 89-98 in DCM.ino. In this case, the program will still read the magnetometer, it will just not do anything with the data. Note that I don’t expect the AHRS to be very usable like this; you will probably find that gyro drift will throw off your yaw estimate after just a few seconds.
However, physically disconnecting the magnetometer (or using an LSM6DS33 carrier, where the magnetometer is not present) makes more code changes necessary, since this means the AHRS program will try and fail to communicate with the magnetometer, causing it to hang. You can work around this by commenting out all references to the magnetometer in the program so that it doesn’t try to access the magnetometer at all; if you want to do this but need to know the exact lines to remove, I can make a list for you. First, though, you should test your IMU board again with the Serial example from the LSM6 library to make sure you haven’t cut any traces that are used by the LSM6DS33.
Kevin
Kevin: Thanks; I’ll check all of this information as you pointed out. FYI, the reason for my alternative testing is due to the fact that I find an extreme interaction between roll/pitch and mag heading that makes this system totally unusable for my application. Even modest changes in roll/pitch cause significant changes in mag heading, which cannot be tolerated in my situation. This seems to go beyond calibration, which itself is apparently widely discussed in this community, with no apparent “common” resolution as far as I can tell, though I have no doubt it’s possible to do this accurately with some effort. This is not the problem, however, as I said. I don’t know if this interaction is due to software or the sensors themselves. The software can probably be fixed, but not the sensors. Without a clear understanding of the problem source, I’ll be unable to continue with this level of product, and will have to seek a “higher grade” system for continued development. Unfortunately, this project is cost sensitive, which may force me to terminate it. FYI, it’s an aviation-grade project which has no need for mag heading, other than the fact that this is used to assist in the accurate determination of yaw. Be advised that your definition of yaw is different from that defined by the aviation community. Your definition includes any rotation about the vertical axis, whereas a pilot’s definition only defines yaw in the case where the aircraft’s turn is uncoordinated. That is, where the amount of rudder used in a turn isn’t proportional to the angle of bank. This causes the “ball” in the inclinometer to move away from the center, indicating a slip or skid condition. Just like going around a curve in a car where the speed/curve radius doesn’t match the “bank angle” of the road. To summarize, a coordinated turn in an aircraft produces no yaw. Pitch/roll and yaw must be totally independent to “line up” with the needs of my project.
I hope this explains my position more clearly. I had planned to use products such as yours to manufacture a unit for a specialized purpose in the aviation field, but am not hopeful at this point in time. If you have any further light to shed on this subject, I’ll certainly consider it. The LSM6DS33 works OK, so the traces are good. You could send me the list you mentioned if you don’t mind.
Addendum: Since writing the above, I’ve decided to change my approach. The only requirements are the detection of a predetermined maximum bank angle limit and a maximum yaw limit (“skid” condition). The latter is easily achieved through the use of a completely independent inclinometer, either commercially available or designed in-house, a very straightforward situation where yaw is detected by means of a hardware-only solution. This avoids all the complications of the current approach. I’ll retain the gyro/accelerometer solely for determination of the bank angle.
Thanks for your help,
Steve
Kevin: Have changed the code as you suggested (no list required) and retested without the magnetometer, results:
Pitch/roll no longer affect yaw, which drifts rapidly at a constant (measurable) rate, and responds instantly/predictably to pitch/roll inputs.
This known “zero-input” yaw rate could be added to/subtracted from the reported rate to provide a reasonably good correction, as long as the goal is simply to determine the total number of degrees of yaw, without worrying about the mag heading.
This independence of yaw on pitch/roll is the key to all of the above. FYI, my proprietary “hardware-only” approach is much more “solid” than this and will still be used in my application.
Obviously, this situation is unique to me and will not work for anyone who needs mag heading.
Steve
Sorry I didn’t get around to giving you the list of lines to change, but it sounds like you figured it out. I’m glad to hear you found an approach that’s working better for you. Thanks for the update.
Kevin