[Dprglist] BNO085 and vibration
Carl Ott
carl.ott.jr at gmail.com
Fri Jul 23 06:44:03 PDT 2021
As an crude but potentially revealing test to isolate potential effects of
mechanical vibration vs. effects of EMC -
If the error is growing so large in a short span like 30 seconds,
why not find a way to spin the lidar by hand at approximately the right
rate?
can you spin it with your finger?
That's how I found the issue on HoverSim - simply setting the robot on a
lazy susan, applying power to the Mega 2560 but not the H-bridge (hence
greatly reducing any chance of EMC issues), and then gently and 'smoothly'
(except for any bearing noise) moving the lazy susan..
You wouldn't catch things like tiny micro-impulses deltas that I imagine
exist for a motor, but you should be able to simulate bearing or imbalance
issues. Even if your manual test vector is uneven compared to a motor
drive, and you see higher variance in drift, that of itself could be
revealing...
Or - maybe you could mount things in a fixture, attach another / much
longer drive 'belt' to a motor far away from the robot chassis, which is
powered by a completely separate/ isolated power supply, and try it that
way...
Carl
On Thu, Jul 22, 2021 at 11:34 PM David P. Anderson via DPRGlist <
dprglist at lists.dprg.org> wrote:
> Chris,
>
> Are you sure that the yaw error is being caused by the vibration of the
> lidar? Rather than the magnetic effects of the spinning motor and
> electronics? I've seen normal servos alter the yaw when driven back and
> forth if they are too close to the IMU.
>
> David
>
>
> On 7/22/21 9:20 PM, Chris N via DPRGlist wro
>
> It looks like I missed a great meeting this week! I watched the recording
> of course.
>
> On the topic of how vibration (in my case induced by my spinning lidar),
> impacts BNO085 measurements: it's bad!
>
> Without the lidar spinning, the yaw drifted only by 0.3 degrees over the
> course of one hour.
> With the lidar spinning, the yaw drifted by >1 degree every 30 seconds!
>
> The robot was stationary in this test.
>
> The BNO085 operating / reporting mode I'm using is called "Game Rotation
> vectors". I'm not 100% sure what degree of sensor fusion - if any - is
> taking place in that mode, because this mode is optimized for quick
> response as I understand it.
>
> I should probably also try some of the other reporting modes that the
> BNO085 has.
>
> I'm also wondering if I can address this via my own filtering. I'm
> already post-processing the yaw output from the BNO085, because it is
> consistently off by about 2 degrees for every 360 degrees worth of
> rotation.
>
> So what I'm doing to compensate for this strange
> 2-degrees-per-every-360 error, is the following: I look at the delta
> between the reported yaw from t(now) and the yaw from t(now-1), multiply
> that with a constant to compensate for error issue, and then I integrate
> the new delta over time to produce my own yaw output.
>
> What I was thinking of trying is to simply throw out very small delta
> measurements, since they are likely to be due to vibration rather than
> actual robot rotation. Of course I would be throwing away information
> and hence accuracy. My guess is what I'll find is that this is too
> simplistic of an approach and I end up with an error in yaw over time
> because I'm throwing out too many small measurements.
>
> Last week I talked about using foam etc to dampen the vibration. The
> other solution that I read about online was to eliminate the source of the
> vibration - which most often is an imbalance with these spinning lidars.
> Somebody managed - with a lot of trial and error apparently - to find the
> right spot and the right weight to attach to the rotating part of the
> lidar, and the vibration was mostly eliminated.
>
> Chris
>
> _______________________________________________
> DPRGlist mailing listDPRGlist at lists.dprg.orghttp://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20210723/b3d975f5/attachment.html>
More information about the DPRGlist
mailing list