The “down” vector looks really weird in there. I’m going to have to look into that.
Got some swings, but not from when running. This is from boot while SD was mounting to computer:
Wait, that last one with the saber sitting still?
It has lots of very high gyro values!
All dumps are the board sitting untouched on the bench. serial monitor control only.
Hasn’t moved in a week.
Well, I have a few ideas to test out to see if I can figure out what’s going on. Most importantly, I need to hook up the digital analyzer and actually read the values from the i2c bus.
If you want to experiment, I’d be curious to see how the problem is affected by disabling the display.
Seems to be the same with OLED not enabled.
13:46:42.031 -> gyro extrapolator data:
13:46:42.031 -> 198438171 {-742.31, 400.27, 1373.66}
13:46:42.031 -> 198438753 {900.02, -1536.68, -1191.96}
13:46:42.031 -> 198439443 {246.70, -91.98, -1020.08}
13:46:42.031 -> 198439957 {-1377.26, 1406.49, 1480.96}
13:46:42.031 -> 198440558 {140.50, -382.08, 517.46}
13:46:42.031 -> 198441165 {1471.62, -1292.91, -1648.32}
13:46:42.031 -> 198441762 {-535.83, 804.26, 52.92}
13:46:42.031 -> 198442786 {-1020.20, -7.45, -356.81}
13:46:42.031 -> 198443451 {1.53, 506.41, 1132.02}
13:46:42.031 -> 198444145 {247.13, -396.97, -172.61}
13:46:42.031 -> 198444637 {268.86, -397.71, -937.74}
13:46:42.031 -> 198445253 {271.00, -280.09, -375.12}
13:46:42.031 -> 198445870 {243.35, -490.54, -673.52}
Testing the latest checked in I2c code. Still randomly EVENT swinging and occasional push. Push gyro numbers look smaller though. see Pastebin.
Doing i2cstate yielded:
03:13:15.277 → current: 536880488 id= 60 next= 536881360
03:13:15.277 → last: 536881360 id= 106 next= 0
One thing I noticed is that when it does it EVENT swing, the sound plays a blip of the smooth swing loudly. I guess that shows it really does think it’s moving fast. Again, this is while at rest on the bench.
Again, I’m noticing that the “down” vector is very different from the “accel” vector, which really shouldn’t happen when the saber is just sitting still. So far I haven’t been able to trigger it on my test setup, but my test setup doesn’t actually have a speaker, so there is no vibrations. Although I don’t know if that’s what’s causing it or not. I should probably try exactly the same config and prop that you are using to see if that triggers it.
I have volume at 100 as I don’t even have a battery in and it’s playing testfont…my mouth saying huuuuuummmmmm lol.
Config and testfont2 is here:
Prop is in the master branch (Yay!)
Weirdness… I just tried swinging my test board around a bit, and I’m getting very low gyro values even when swinging around like a crazy person. There is definitely something odd going on with the gyro values.
Want to reciprocate ? I’ll try your config and prop over here. FYI This is a 1.5 board.
Right now I’m just testing the “default_proffieboard_config” configuration.
Where would I stick fusor.dump(); in saber.h?
I put fusor.dump() in prop_base.h::DetectSwings()
Then I uncommented the Loop() and DetectSwing call in saber.h, like this:
#if 1 // NUM_BUTTONS == 0
void Loop() override {
PropBase::Loop();
DetectTwist();
DetectShake();
DetectSwing();
SaberBase::RequestMotion();
}
#endif
I’m also using “monitor fusion” to see what’s going on.
Ok, I’m starting to see a pattern…
- We see no motion events for a small time.
- A timeout triggers and resets the motion chip (which looks different than it used to)
- gyro values go crazy for a little while
Now for the hard part: why ?
1 Like
There may be some slight time travel involved. “last_event_” seems to be greater than millis() sometimes, which the code doesn’t expect.
I don’t think anything would expect that. So adding some sort of
if last_event_ > millis() return false;
?
the problem is that on the very next line last_event_ may have increased.
The trick I think is to change lines like this:
if (millis() - last_event_ > TIMEOUT)
to
if ((last_event_ + TIMEOUT - millis()) >> 31)
It’s unfortunate that it’s kind of incomprehensible, but let me explain.
millis() and last_events_ are uint32_t, which means that they cannot go negative, even when you subtract them. So if millis() is less than last_event_ instead of getting -1, we get 0xFFFFFFFF, or roughly 4.2 billion, which is obviously bigger than TIMEOUT.
In the second case, we actually use the wrap-around as the trigger for the if statement. Basically we’re comparing last_event_ + TIMEOUT to millis(). If the result is negative (meaning that the first is smaller than the second) then the if statement is true. (Because when we shift down by 31 bits, only the top bit is set, and than one is only set if the value is greater than 0x7fffffff, which means that we had a wrap-around, which should only happen if the result was negative…)
Anyways, trying this now, will check in soon if it seems to work.
Checked in, quick try seems to work better.
Hmm, still seem to have some problems with OLED displays though.