SimpleFOCStudio 2.0 a tunning and configuration tool

Hi all,

We have a new version of the SimpleFOC Studio app updated to work with SimpleFOC 2.1 thanks to @Antun_Skuric who took the previous version and pushed it to the next level :slight_smile:

The main features are:

  • Plug and play with the SimpleFOClibrary version 2.1
  • Real-time tuning and configuration of the motors
  • Real-time plotting and monitoring of motor variables
  • Code generation for easier integration of the tuned parameters in your code
  • Built on PyQt5 and a standardized SimpleFOCConnector interface that can be used as a gateway form python to the SimpleFOClibrary device as it is shown in the simple example.

8 Likes

Woohoo - very nice!

Maybe you could add in the documentation that the letter listed here:

command.add(‘M’,doMotor,‘motor’);

Needs to be entered here:

Screenshot 2021-04-25 232844

( I was trying to enter it in “Conn ID” )

Good work!

2 Likes

Thanks for you suggestion, just modified the documentation :slight_smile:

This is great, you can test out property changes really quick to see how they change performance.

I have a few ideas :slightly_smiling_face:

  1. Add a “Jog Dial”, eg:
    image

In velocity mode, it has preset speeds. In angle mode, it has preset positions.
Then you could just click the button and sends the command to go to that speed/position.
This would make it even faster to see the effect of changing settings.

  1. Custom commands:
    image

Where you could specify a Name, Command, Value and Response text.

Then we could extend the commander interface on the controller to do things like change register settings for SPI devices.

  1. Help
    Maybe a help button beside each setting where it links to the online docs explaining the setting, and what typical values might be.

Anyway, just some thoughts…

3 Likes

Thanks a lot for your suggestions @Jason_Kirsons … great ideas for the next version :slight_smile:

Hi @JorgeMaker,

Thanks for the simplefoc studio. I have it running and it helped me tune my pid.

I have a lot of experience with pyhton + Qt, and I was considering creating a new gui based on QtQML, which would bring a lot of flexibility.

What do you think?

I would, of course reuse as much stuff as possible.

2 Likes

Thanks for your nice words :slight_smile: I have never used QtQML … it would be nice to see a project like this, surely we can all learn something together:wink:

Hey @JorgeMaker and @malem,

That sounds awesome!
I’d be in to support any further development as well both in python and on the library side. There is still a lot to optimize for the efficient communication, we should probably introcude the Verbose:::studio or Verbose:::python ( or Verbose:::echo_command similar to what @malem already suggested an approach for that in the PR) mode in the commander as well and echo the command instead of a lot of text that we need to parse. The same is true for the monitoring.
This would allow tuning multiple motors a bit more easily and less overhead in communication.

Now I’d like to suggest to you guys and everyone else that feels interested to try to use the same python connector class for both applications.
What do you think of making the python connector a separate repo and even a pip package?
This way we can easier support all the library changes that might occur.

yeah a different package for the connector would, I think serve other people’s needs

Also, SimpleFOC-side, should/could we go async with the reporting?

The loop could be put on a timer, with the data to send out put in a buffer that is emptied interrupt-based.

just an idea…

I will try it later

1 Like

I have pending to investigate the use of asyncio to implement the interface between the tool and SimpleFOC device.

the bottleneck is more MCU-side.
I think it would be possible to prevent the monitoring from affecting the control loop.

The idea would be to setup a e.g. 10khz timer (like paul gould did) where the control loop happens and put readings in a FIFO buffer. Then buffer would then be emptied when the MCU idles, or interrupt based.
in the main loop() function, we could e.g. listen for commands

1 Like

Hey, my thoughts on this…

asyncio on the GUI side might be interesting for other reasons, although my impression is the GUI is very responsive despite the constant serial comms.

On the MCU side, I think there is a lot that could be done, but I think care should be taken to keep it separate from the “simple and generic” interface we have now. Any Arduino has a Serial object, but not all of them have timers that work in the same way, etc…

I know you like SAMD :wink: - I think on SAMD it should be possible to drive the SERCON using DMA, with almost no overhead to the main loop. But this will hardly be portable to other MCUs. So I think a good approach here could also be to write alternative “monitoring backends”, which can be kept separate from the main code (not wasting space and confusing the people not using them). The “pros” that want DMA-based monitoring for their MCU can then select from the available backends, or code their own.

I’m sure some people have been thinking about other channels than Serial (UDP on ESP32 for example, or MQTT, etc…). There could be backends for that too!

In terms of the existing SimpleFOC implementation, I would keep it simple, and keep it on Serial. This will be what 90% of users want when first testing it out, and what the less advanced users can realistically manage.

A possible optimization might be a binary mode for monitoring.
At the moment we send a bunch of 32 bit floats as ASCII. This incurs a penalty both in terms of ASCII conversion of the data, and sending some extra bytes.
I think converting to a binary format might improve the performance somewhat.
The ASCII format could be default, and we could keep it for the commander, but the binary format could be used by the monitoring when called from the SimpleFOC Studio…

1 Like

On the MCU side, I think there is a lot that could be done, but I think care should be taken to keep it separate from the “simple and generic” interface we have now. Any Arduino has a Serial object, but not all of them have timers that work in the same way, etc…

Agreed, also with your backend idea. the default could be a backend that synchroneously write via the configured Stream. I think it would still be doable to keep the FIFO idea without losing generality.

I know you like SAMD :wink: - I think on SAMD it should be possible to drive the SERCON using DMA, with almost no overhead to the main loop. But this will hardly be portable to other MCUs. So I think a good approach here could also be to write alternative “monitoring backends”, which can be kept separate from the main code (not wasting space and confusing the people not using them). The “pros” that want DMA-based monitoring for their MCU can then select from the available backends, or code their own.

Well it’s the dev board I have in stock, and my initial plan was to reproduce Paul Gould’s controller. Lots have happend since. I’m more and more interested with the SMT32G4. But yeah, I do want DMA-based/async monitoring. And I totally agree we should design a binary protocol. Another thing I’d like to see are timestamps which would become crucial it we go async

Couldn’t agree more. I discovered it recently, and I’m now trying to decide between three chips for my next board design:

  • RP2040
  • STM32G4
  • ESP32 Pico D4
    I’m happy to share once I’ve got something worth looking at :slight_smile: