Blade Detection and Spinning Motors

ProffieOS
1

No bugs this time (at least I don’t think so) but most likely something I’ve done (or not done).

Two issues:

The first concerns blade detect. I’ve not used blade detect much, so I’ve almost certainly done something silly, but it’s not doing what I thought it would.

Setup is thin-neck hilt with removable chassis with neopixel blade disc in the grenade section. The idea is I want the Proffie to know when the chassis is inside or outside the hilt.

I’ve setup two separate bladestyle arrays which are identical apart from the fact that the spinning motor is set to spin with the chassis out and set to not spin with the chassis in. Blade detect pin is wired to RX (pad 8) and defined in the config.

The Proffie is correctly registering chassis insertion or removal as it plays the bladein / bladeout wavs. But it doesn’t seem to flip to the opposite bladestyle arrays, as evidenced by the fact that the motor spins regardless of whether the chassis is inside or outside the hilt.

My guess is there’s some little step I haven’t done.
Config is below.
What have I missed?

The second issue concerns a spinning crystal chamber motor affecting the sound. If I have a blade preset with the motor spinning, I get all sorts of horrible artefacts - not so much false clashes (although there is some of that) but false swings. If I switch to the same preset and font without the spinning motor, it sounds fine? Video is below.

Battery is charged, have tried swapping SD card, file structure is optimized for fast SD access. I’ve tried it with and without the #define PROFFIEOS_DONT_USE_GYRO_FOR_CLASH line, and I would say it’s worse without it.

Anyone else known motors to upset things before? It’s wired positive to batt + with a 10 ohm resistor, and negative to an LED pad. I’m guessing the motor vibration is causing the board’s motion sensors to think they’re moving when they’re not (The motor is very close to the board). The question is what, if anything, can be done about it?

As always, any thoughts welcome. :slight_smile:

2

Well the first one is simple.
Both your blade entry arrays start with 0, one should say NO_BLADE.

3

Doh!
Thanks Prof. I knew it would be something silly like that! Apologies for not spotting it myself. (First time doing blade detect). Appreciate the help as always. :slight_smile:

That just leaves the false swings. Although I have a feeling there won’t be a proper answer to that one as it seems to be the chassis layout at the root of it. :confused:

4

The second problem is harder, and not really my expertise. I don’t actually have any hilts with motors in them, so my help will be mostly theoretical.

Motors are tricky, and there are at least three ways they can cause problems:

  1. mechanically
  2. electrically
  3. magnetically

Now, these are listed in the order of probability of causing problems. Magnetic issues are probably very unlikely. For one thing, the motor casing usually shields the surrounding from most of the magnetic field. Also, proffieboards, wires and chassis don’t usually contain a lot of magnetic parts that can pick up a magnetic field disturbance. Now if magnetic fields were causing a problem, then the best way to fix it would probably be to find a motor with better casing. Alternatively it could be fixed by putting something with iron in between the motor and whatever is picking up the magnetic signal. But as I said, I really don’t think you need to worry about magnetic interference.

Electrical interference could be a problem though. The coils and the brushes in motors tends to cause quite a lot of electrical noise. Proffieboards already have a lot of filter capacitors, so it should be be fine, but it’s not hard to test if adding more capacitors helps. All you need is a large-ish (say 100uF or so) capacitor, then add it in parallel with the motor and see if it helps.

That leaves mechanical, and there are no real easy answers here. You could try adding some electrical tape or foam tape around the motor if you have space for it. Other options include trying a different motor, or putting some drops of silicon oil in the gears.

Once the motor has been dampened as much as possible, it all comes down to tweaking the config to make it less sensitive so that false clashes (or swings) happen rarely. There are a bunch of defines for this, so I think I’ll write a separate post about that.

5

Actually, before we get into tweaking all the gyro and accelerometer defines. I suggest checking the serial monitor to see what these false effects actually are. (swings, clashes, or something else?)

6

I guess the other question is if you’re sure that the problems come from the motor. Have you tried turning the motor off and see if the problems go away?

7

Thanks as always for the detail Prof.

To answer your question, yes if I set it so the motor stays off when the blade is lit, the problem goes away. I’ve also tried slowing the motor right down on the config, and although it helps, it doesn’t fix it completely.

This is the serial monitor:

Unfortunately there aren’t many options for modifying the motor as the chassis was very much designed around it and there is almost zero spare space around the motor for any kind of damping material. I tested the motor before install and I have to say it is pretty powerful - quite a lot of torque. When I tested it in the loose chassis before assembly, I had the brass rods (pictured below) just dropped into their holes, and the motor was spinning them in their grooves, even though there was no mechanical connection (the rods are just intended to hold chassis parts together). Whether the spinning was caused by torque or vibration I couldn’t say for sure, but I suspected the latter. (Like you I don’t think it’s magnetism because the rods being brass aren’t especially magnetic). So my hunch is the motor is sending significant twisting moments through the chassis which is fooling the board into thinking it’s being swung when it isn’t.

I’m guessing there isn’t a swing sensitivity define, as presumably that would defeat the purpose of smothswing?

Rods
Rods735×547 32.5 KB

8

This is interesting, and I don’t think it’s a problem I’ve seen before.
Normally, when we have problems with motion interference, it’s either the clashes, or swing events, not the smoothswing is causing issues.

The good new is that smoothswing is smooth, and we may be able to filter out some of these issues.

There isn’t a define for this, but you could try changing this line:

Instead of GYRO_MEASUREMENTS_PER_SECOND/filter_hz, you could try changing it to GYRO_MEASUREMENTS_PER_SECOND/10. This will make the gyro filtering stronger, and may help with this issue.

2 Likes
9

OMG!!! :open_mouth: Prof, I think you’ve cracked it!

I’ll need to do some more experimenting tomorrow when I have a bit more time and I can make some noise (daughter’s asleep in the next room now), but it’s definitely a huge improvement already! I’m absolutely gobsmacked!

Thank you so much! I really thought I would just have to live with this one and just put it down to chassis design, but as always, you seem to have found a software… if not solution, then huge improvement.

And sorry I keep managing to find such bizarre little problems! Thanks again so much for finding solutions to them. :+1: :ok_hand: :slight_smile:

10

This is The Way… to a better OS. Don’t be sorry.

1 Like
11

Just a quick update to say that having done a bit more testing, this hasn’t merely improved the problem, it has pretty much solved it. :smiley: Prof, as always, you are a total genius Sir! :ok_hand: :pray:

So just for my own interest, the line:
GYRO_MEASUREMENTS_PER_SECOND/filter_hz

that we changed to:
GYRO_MEASUREMENTS_PER_SECOND/10

what has that done exactly? I assume ‘filter_hz’ is a variable and ‘10’ is a constant, but is there a range within which the 10 fits to tweak swing sensitivity? Really just curious is all, as there’s a part of me that quite likes it being a wee bit less sensitive to very small, gentle movements.

12

I have not tested this, but what is the result? Like, if you do the ol’ wiggle wiggle, does the smoothswing react less at the onset of the motion?
Would this be equivalent to a smoothsw.ini setting as far as real-world performance?
I should probably read through the tread more thoroughly.

13

The issue was weird sounds, like the smoothswing was trying to work even when the hilt was still. It seemed to be caused by the motor fooling the board into thinking the hilt was moving when it wasn’t. The Prof’s modification seemed to tweak smoothswing sensitivity, but you almost wouldn’t notice any difference actually using it. But I don’t quite get the physics of it.

Anyway this is how it runs now:

:slight_smile:

1 Like
14

The calculation (GYRO_MEASUREMENTS_PER_SECOND/filter_hz) determines the size of the the extrapolator filter. By default, this filter has 1600/80 = 20 entries, because filter_hz is 80. The filter basically limits the frequency of the signal to roughly 80Hz. (80 back-and-forths per second)
When we change it to 10, the filter size becomes 160 entries, and the filter frequency becomes 10. For a gyro, that’s probably fine, because you’re not going to go back-and-forth more than 10 times per second anyways.

Now, using an extrapolator as a filter is a bit unorthodox, so the math might be a bit off, but the should be roughly correct at least. :slight_smile:

1 Like
15

edit: Saw @profezzorn already considered this.

I’m probably chiming in a bit late but just now seeing the thread, I wonder if you’re getting some sort of radio frequency issue there too? As in motor noise. Do you have a capacitor in place across the motor terminals? Here’s a quick reference. Capacitor sizing for small motors to reduce inductive voltage spikes - Electrical Engineering Stack Exchange

16

Thanks as always for taking the trouble to explain it Prof. I think I get the idea, although I’m surprised the standard OS is set to ‘resolve’ (if that’s the right word) such high frequency motion.

But anyway, the mod has done the job brilliantly. Will definitely keep it in the toolbox in case I come up against this issue again in future. :smiley: :+1:

17

Some types of motion (clashes) are better detected at higher frequencies, that’s why we poll the motion chip at 1600Hz.

1 Like
18

Picking this thread up again, Prof, is it possible to add the smoothswing tweak above as a config define to save anyone else with this issue digging through the OS?

Maybe something like:
#define ENABLE_SMOOTHSWING_PAD

I’m happy to write something up for the documentation if it helps.
Just a thought.
:slight_smile:

19

If it fixes a problem without negatively impacting anything else, I vote it just gets changed.
#defines are becoming as ubiquitous as Rgb values :upside_down_face:

20

If I understood the problem, it is a very particular problem where a rotary chamber introduces a coupling issue with smoothswing. So his solution was to increase the filter size on the gyro inputs. But, conversely, it increases latency and “jaggedness” on the gyro’s outputs. I think adding a couple extra “not really documented outside of code” defines would be fine. These are very core motion defines.
Adding 30 defines to customize a particular prop is not really an issue. Customizing the fusor is quite a delicate thing. If we document it, it is quite possible that we will have more support threads for bad use of the define than actual people having coupling issues between a motor and the smoothswing algorithm.
Doing a of defines is trivial to do, though.

1 Like