Community Improvement: MPS Mag Alpha optimization

[Jason_Kirsons]

Hi, in MagneticSensorSPI.cpp
it always sends the command, waits, then reads the angle.

For Mag Alpha sensors, this block of code is not needed:

/*
  //Send the command
  digitalWrite(chip_select_pin, LOW);
  digitalWrite(chip_select_pin, LOW);
  spi->transfer16(command);
  digitalWrite(chip_select_pin,HIGH);
  digitalWrite(chip_select_pin,HIGH);
  
#if defined( ESP_H ) // if ESP32 board
  delayMicroseconds(50);
#else
  delayMicroseconds(10);
#endif
  */

Because the sensor does not require a command to read the angle. Every 16 bit read contains the angle - unless it is the response to a register read/write request.

For me - commenting out this block improves main loop performance from 4kHz to 9.6kHz.

Could we have a flag in MagneticSensorSPIConfig_s for “Don’t write command”, where it skips this block?

[Owen_Williams]

@Jason_Kirsons - good idea - maybe you could do a PR?

Something similar was discussed whereby the library remembers the previous command (register) and if new read is for same command then it know that the SPI read contains correct data so only one transfer16 is needed. There were concerns that this might lead to sample read being prepared on last loop/sample and thus being ‘old’ but this was speculation.

[runger]

Hi Jason!

I’m about to launch into a refactoring of the sensor code. MagneticSensorSPI will be refactored in this process. There is also a problem with STM32 chips in that code.

Thanks for finding that - I will try to include that change, but the MagnetSensorSPI class has to be kind of generic and general, so it probably won’t be the optimal solution for any given sensor.

I have a bunch of sensors lined up for testing (either on my desk or arriving from PCBWay or Mouser this week ):

• MA702
• MA730 (probably too slow as we’ve found out)
• AS5047P
• AS5048A
• AS5047D (thanks to @Adam_Donovan)
• TLE5012
• AEAT-8800-Q24
• AS5048B (I2C)
• AS5047U
• AS5147U

I also wanted to test sensors from Allegro Micro (like the A1333) but could not obtain them anywhere.

My plan was to make them all work with specific drivers, and then test the generic MagneticSensorSPI class until it works well with all of them.

So even if your change can’t make it into the general class there should be a chip-specific class for the MA702/MA732/MA730 by the time I’m done.

Hope you can wait a bit though, because I think this will take a while

[Jason_Kirsons]

Hey that’s great! Yeah, I can wait - no rush.

It would be great to see a comparison of all the sensors and see how much difference a sensor makes to SimpleFOC. Maybe run them all with the same motor, and also have the most precise known sensor also attached to the motor - recording jitter, velocity?
(2021 SimpleFOC sensor roundup )

[runger]

@Jason_Kirsons

2021 SimpleFOC sensor roundup

Yeah!

@Jason_Kirsons

Maybe run them all with the same motor, and also have the most precise known sensor also attached to the motor - recording jitter, velocity?

I was planning to use the same MCU, same driver, same motor and same magnet throughout the tests. The code has to necessarily be a bit different for each sensor, but that is part of what gets tested in the end. A sensor will only be as good as the code that reads it.

I will try to make the sensor diagnostic information available in the driver implementations, so obviously the sensors own diagnostics and error measurements are one data-point to collect.

The maximum attainable speed in open-loop and in velocity mode would also be interesting, to see if the sensor introduces any limitation (e.g. like the MA730 seems to).

But I’d really appreciate it if people have ideas for what/how to test and measure.

For example, I was thinking about whether the jitter could be measured optically, for example with a laser pointer or mirror attached to the motor. I haven’t come up with a good plan for that yet though.

I think a ΔAngle-ΔTime scatter-plot might be interesting, kind of showing the discretisation and error on the time and angle at the same time. I would expect certain characteristic patterns to emerge depending on the control-mode, MCU loop speed, MCU timer resolution, sensor resolution and sensor stability.
For example good sensors in position mode would have all the points near zero, probably in 2 small clouds to either side, as the motor vibrates around its set-point. Bad sensors would have this cloud more random and spread over larger areas.
Discretization problems might show as visible bands/concentrations of the points. And “outliers” would indicate communication issues, timer issues, numerical precision issues, and other things that cause unexpected zero or out-of-band values.

I’m really interested in the ideas people have, and would be more than willing to run people’s code on a bunch of different sensors - so if anyone wants to send me something that they want tested, please feel free!

[Owen_Williams]

@runger - I’m very excited to hear you are taking this on!

A couple of ideas.

• effective resolution - whilst a sensor may say it is 14 bit, sometimes the last 2 bits are just noise!
• max sample rate - related to spi/i2c clock speed but there might be some faster sensors. Can sensors speed be traded with resolution.
• hardware velocity register - some sensors e.g. ma730 allow you to read velocity. This has the potential of being less noisy. Unfortunately the scale is often not great e.g. rubbish resolution at slow speed.
• Lowest stable Tf whilst when PID is tightly tuned. Some sensors seem to work with 0.0001 Tf others (AS5600) is more like 0.05.
• Look at measured velocity standard deviation at constant speed 5 rad/s with fixed or zero Tf.

[malem]

Ok this is very “from the left field” but, here’s a a idea: use a mouse sensor for quasi static tests. Some mouses have awesomely precise optical sensors.

To evaluate sensors you need a gold standard.

For dynamic tests, optical encoders are great but that implies a complicated quadrature decoding setup

[runger]

@malem

Ok this is very “from the left field” but, here’s a a idea: use a mouse sensor for quasi static tests. Some mouses have awesomely precise optical sensors.

That’s a good idea! I will look into that.

[Daan87423]

Any update on this topic? Looking into using either the AS5048A, AS5047U, or AS5047D for accurate angle measurement. Is the code for reading the data and configuring the sensor using SPI roughly the same?

[VIPQualityPost]

@Daan87423

Looking into using either the AS5048A, AS5047U, or AS5047D for accurate angle measurement

These are in the drivers library: https://github.com/simplefoc/Arduino-FOC-drivers/tree/master/src/encoders
You should be able to write/config to the sensor the same way as reading.

[Daan87423]

Great, thanks!

In terms of reliability and performance, are there people here that have used both (or all 3) and have a preference?

[runger]

I’ve used all three, and they all worked well and were easy to use. There’s some differences between them, I believe the AS5047U is the “best” due to its filtering features.
The AS5047 in general has the advantage of also offering ABZ as well as SPI…