<div dir="ltr"><br><div>As an crude but potentially revealing test to isolate potential effects of mechanical vibration vs. effects of EMC -</div><div><br></div><div>If the error is growing so large in a short span like 30 seconds,</div><div><br></div><div>why not find a way to spin the lidar by hand at approximately the right rate?</div><div>can you spin it with your finger?</div><div>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..</div><div><br></div><div>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...</div><div><br></div><div>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...</div><div><br></div><div>Carl</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 22, 2021 at 11:34 PM David P. Anderson via DPRGlist <<a href="mailto:dprglist@lists.dprg.org">dprglist@lists.dprg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Chris,</p>
<p>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.</p>
<p>David</p>
<p><br>
</p>
<div>On 7/22/21 9:20 PM, Chris N via
DPRGlist wro<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default">It looks like I missed a
great meeting this week! I watched the recording of course.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">On the topic of how
vibration (in my case induced by my spinning lidar), impacts
BNO085 measurements: it's bad!</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Without the lidar spinning,
the yaw drifted only by 0.3 degrees over the course of one
hour.</div>
<div class="gmail_default">With the lidar spinning, the
yaw drifted by >1 degree every 30 seconds!</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">The robot was stationary in
this test.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">I should probably also try
some of the other reporting modes that the BNO085 has.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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. </div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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. </div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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.</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">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. </div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">Chris</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
DPRGlist mailing list
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div>