
Andy Roid

I have purchased a 4 in One Orientation Sensor. My desire is to use the compass function.
Once loaded and running, I view the compass heading values in the Variable watch window.. The value fail to read correctly. I find when I set the device in 90 degree directions ( 0 - 90 - 180 - 270 - back to zero ) I get value that do not even come close to the set position., nor do they repeat. I have changed my location, and even tried it in a wooden shed without any potential magnetic interferences, and still it did not work.
Has anyone use this sensor and has been able to get it to display correctly?
My reason for buying this was for the compass only and I am disappointed to see it not work.
Ron R
Upgrade to ARC Pro
Get access to the latest features and updates with ARC Early Access edition. You'll have everything that's needed to unleash your robot's potential!
Alan
Yeah I figured I would put it out there. I really wanted it to work. Lets hope we hear good news. I didn't really care about the other features, like I am sure many others.
Ron R
Hopefully the sensors will be better designed/engineered and all 4 functions work for the robot design I have in mind using the EZB-(V4) controller and Lidar with the Teensy controller.
Ron R
FYI the sensor you get may be updated anyway especially if you bought it from ez robot's store.... The affected sensors are probably from the initial batch of production?...
I read what you said in the thread, but even so, there should be some functionality. I expected this device to give at least basic values ( 0 - 90 - 180 - 270 - back to zero ) +- 10 degrees, and somewhat repeatable.
Ron R
Is there a way to calibrate it?
Ron R
Alan
I had hoped someone found a way to calibrate it and got it working.
Ron R
Thanks for the tutorial. Will vibration or movement screw up the readings, or will I have to stop to update readings?
Ron R
If not, does anyone know of a compass that I can get that will work with the EZB?
If something has been used in the past, is there any example code I can look at? My project is kind of on hold until I can get the ability of 8 readings from a compass. (about every 45 degrees +- 5 degrees will work).
Thanks,
Ron R
Ron R
Personally, I am going to wait for an EZ-B solution, but my project(s) are not on hold waiting for this, they just aren't as efficient as they will be once it does work.
Alan
Dj mentioned he would work on a tutorial. I will see how he makes out.
Ron R
Any other orientation has the same issue even if I move it as far away from the EZ-B and 2 servos as the cable will allow. It only works at all oriented one way.
OK, so with it in the position where it sort of works, comes the next problem. It isn't consistent in how far a degree is... If I turn face south, so it measures ~ 0 (it is very jumpy, but I can get it jumping between 355 and 5) and I turn 90 degrees to the right, it measures that I have turned 180 degrees. If I go back to 0, then turn 90 degrees to the left, it reads 300, thinking I have gone 60 degrees. It spends most of the circle in the 200's, with a big jump from 200 down to 0 in the last ~90 degrees or so.
All of this is with the default settings and using the default script. Increasing the smoothing just seems to make it react late to turns, but doesn't smooth out the jumpyness. Same with increasing or decreasing the time between reads in the script.
So, some progress, but still not really useful.
Alan
I ran a number of tests. I only used the compass on an ezb, nothing else connected. The compass and EZB was placed on my desk with my monitor and keyboard local to it. I don't believe they caused any interference. I placed the compass on the top slot of 3 stacked cubes. I ran the compass script, init. script. and Variable watch. I used the figure 8 motion to calibrate. I marked a base line on the pad below the cubes to set a zero point, which was south by a magnetic compass. Typical outputs shown on sweep display. I will re run tests later and monitor the variable watch display.
I rotated the block and ezb compass 90 degrees at a time and got the following results.
Angle turned (clockwise from top)
Pointed Degrees 0, 90, 180, 270, 0
Tests results 358-4 , 103-104, 208-220, 284- 290, 355- 6
Readout values were not stable and varied about +- 10 points at rest. Any movement caused additional lack of accuracy. Accuracy of coordinates to true value was not good, but without any movement seemed somewhat repeatable. The zero point value (south) seemed to repeat within tolerance +-10 points.
I don't know if I will have the opportunity to connect the compass to my adventure Bot until next week to see if it works while running. If I can sneak in some time later, I will try to do additional tests.
The results seems better than they were during my initial tests in the past.
Ron R
I see you are up early too (or late). I saw your update after I posted my test results. I look forward to your next release.
Thanks
Ron R
Does not seem to work, even if recalibrated, if the board is facing down, like you would if installing on JD's chest. Also does seem to pick up some interference and lose accuracy if too close to the EZ-B (or maybe too close to the servos). I am testing with adventure bot, and have it on a pair of extension cubes off the front and it works fine. If I put it on the cube closest to the body, it loses all sense of direction. But with careful placement, this will definitely do what I need it to.
Alan
Alan
Here's some code with will generate a file that you can load into excel and display what the compass values return. Notice how the Z axis is much less sensitive and really only used for tilt compensation,
Code:
Alan
Doing it like that, gives you the ability to keep "motion" so the compass points in directions.
Because you are only collecting 1 sample every X ms, you're own circular buffer would need to consider the sample frequency as to not appear "lagged".
Notice how the buffer is initiated at object creation, and all data added to it is circular. The average is returned upon each appended data call...
Code:
Alan
First i normalize the data because each sensor returns a different data range. Then calculate Pitch and Roll. Then, tilt compensation based on the normalized values. Finally, produce a heading degree from the 3 axis.
Prior to all of this is the calibration data calculations - which merely grabs an average of highest and lowest values and adjusts the range based on your physical location, and the sensor's environment.
If you calibrate the sensor while it is not in the robot - that's defeating the purpose.
Code:
This is something to consider for a new version of the compass module. Might be worth considering if we added a second IC that collects the data quickly, and filters it...
Alan
Am I missing something ?
Here's the manual page for the MPU 9150 All In One module:http://www.ez-robot.com/Tutorials/Help.aspx?id=213
Also, unless you wish to perform serious math, as in my previous posts, do not pay attention to the $compassx $compassy $compassz variables - that's a whole new world that you most likely don't want to experience.
Follow the manual page and use the $CompassHeading variable only.
yes, that would be helpful I think. I was going to use a if $bearing <= $heading (or >= depending on which way I am turning), but being able to have a target range would probably be better. Will have to figure out what happens when I cross the 0/360 boundary to keep from turning to far. Figuring out the target $heading (ie $bearing) is easy, but knowing I have hit it trickier. For instance, if I am at 270 and my new target is 5, I need to keep going until I am greater than 360, and then continue until I am up to 5, so probably move in two steps instead of one. I'll figure it out.
Alan
I was wondering about converting 360 degrees to 1 to 179 positive and 181 to 359 as 1 to 179 negative numbers. 0 and 180 unsigned. This would allow the numbers to become directional. I haven't fully thought it thru, but what do you think? It should simplify the math?
Ron R
I forgot to mention invert the numbers, i.e. count + 177, +178, +179,180, -001, -002,-003, etc. 180 for example = South 0=North
I know it took a lot of work to get it right. Thanks very much ! I am sure many of us will put it to good use.
Ron R
I have calibrated it flat by putting it in the slot between JDs legs and again vertically by putting it in the chest slot. When flat it does nothing as I turn JD. In the chest, it only works when I tilt JD side to side.
Did the figure-8 thing and all. That seemed to go well. Ran the calibration once when I placed the sensor in the flat position, and ran it again when I placed it in the chest. When the chest position didn't work either, I put it back in the flat position and ran the calibration yet again. It works in both positions but only when I turned JD such that the board is upright (vertical) and rotated the robot such that the sensor board was turning in a circle with the edge of the board leading the way. Only then did the pointer in the control rotate appropriately, 360 degrees. If I rotated JD around the vertical (Z) axis while he is standing, the pointer did not move.
I just tried it again with the new release. I started the init script., Hit the calibrate button and move it as was requested. Once the time zeroed, I placed the sensor flat on my desk. Rotating it on the horizontal plane I got the readings. I placed the sensor in three stacked ez blocks and found I could angle the sensor about 45 degrees from horizontal and still have it read.
If you get to close to the ezb it seems unable to work correctly.
Ron R
First, Again thanks for the upgrades of the compass.
The Quadrant displays are great. This will help with turns and direction.
Are we still able to get the "degree" numbers also? I want to experiment with both. I want to use them also as coordinates.
EDIT: Oops,, I messed with the setup and found the rounding works. This is great! Now I can go play.
Ron R
Thanks for the input.
Ok, I decided to start from scratch so I made a new project and tried the calibrate and run script with it. I even made sure the servos had no power going to them yet. And ... it worked perfectly! Progress! Set it to nearest 10 degrees and it still worked perfectly.
Then I imported the Auto Position control from the example so I would have a servo setup model from which I could load a servo profile to set and energize the servos. Still worked fine. Even tried another calibration with the servos energized, still perfect.
Finally I went back to the original project I was running last night. Went through the calibration process again and all went well this time.
I kind of hate it when that happens because now I don't know why it didn't work last night. I changed nothing in the project.
Anyway, now I'm going to try another unit (still in the original packaging) and see if the same thing happens with the project from last night.
All of which leads to a question .... Once calibrated, do the calibration values get stored on the MPU9150 itself or in the EZB project file?
Ron R
What can really screw the calibration up is large jolts or bangs. The compass will need to be re calibrated if that happens - this is due to the physics of a compass module and how it works - if they are jolted the calibration will be lost.
The drawing of how to calibrate does not imply the compass should be thrown in a figure 8 :). Simply gently wave it in a figure 8 motion like you do with an iPhone when prompted.
Ron R
Thanks
Alan
Are your tests with the adventure Bot or Roli?
My goal is to get my adventure Bot to track on a compass coordinate until a ping distance then go to next step in the sequence script. The bot compass also is used to trim the straight line track by trimming the wheel servos. The compass also confirms turns are complete. Is this similar to what you are doing?
Ron R
My mid term goal is to put it in or on Roli.
Long term is a custom robot.
Alan