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.

9 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:

@runger @JorgeMaker @Antun_Skuric

Just so you know, Iā€™ve put quite a bit of effort on the data logging side. I chose to go separate way from the commander interface since I aim for real-time data logging performance, probably on a separate, outbound-only. data link. I wonā€™t be needing SimpleFOCStudioā€™s connectors. I tried, but I then found a solution thatā€™s both simpler and much, much higher performing. I should be ready for a little demo by monday or tuesday.

Beware, itā€™s Pyside6-only (pyqt5 is GPL, btw), uses QtQML, and it parses C-code sunch as ā€œArduino-FOC/src/common/foc_utils.hā€ to genrate parsers automatically. Itā€™s going to be a bit nasty at first, but donā€™t worry, I hate nasty code.

for example, to send a struct from MCU, it becomes as simple as:

    Serial.println("PhaseCurrent_s");
    Serial.write((uint8_t*)(&pc), sizeof(pc));

from python side, my architectural aim is to have not a simple loc to add to support a new C struct.

I use pyclibrary to parse c structs definition, and then convert them to numpy structured arrays.

I have a POC, but Iā€™m to proud to show it as it is :blush:

Hi @Jason_Kirsons ,

I had some time today and I have decided to implement your suggestion to add a Jogging control.

Captura de pantalla 2021-05-20 a las 19.27.38

The fast reverse button reduces the current target by 2 times the specified increment, the reverse button reduces the current target by the specified increment ā€¦ etc. Stop button, in angle control mode, sets the current angle as target angle and in velocity control sets the target to zero.

Regards

4 Likes

Thatā€™s great! I love it! It makes it so much quicker to use.

1 Like

Hi @Jason_Kirsons,

Just got time to implement your second suggestion os something similar. Each custom command has a name and a value as yoy can see at the bellow.

Once you have defied each custom command in rder to execute each of them you have to select it and once selected press the space key (āŽµ) or right arrow key (ā†’).

customCommands-1

Regards

Hi @JorgeMaker

Thanks, Iā€™ve tested with a few custom commands:
image

And then the controller has some custom commands (changing parameters from @runger 's DRV8316 driver)

void doCustom(char* cmd) { 
  switch(cmd[0]) {
    case 'S':
      printf("Slew Rate: %i\n", atoi(&cmd[1]));
      driver.setSlew((DRV8316_Slew)atoi(&cmd[1])); 
      break;
  }
}


command.add('Z', doCustom, (char*)"Custom");

It looks like itā€™s working well!

Would it be possible to save the custom commands in the JSON file when we save the config?


Also, is it possible to save this in the JSON? Or always default to ā€œMā€?
image

Hi @Jason_Kirsons,

You are right, Itā€™s a bit annoying having to add the custom commands every time yo execute the application. I will add the functionality of being able to save custom commands in the JSON file and also saving the ā€œMā€ o whatever parameter of the engine. When I have it done I will let you know, it is a minimal change that adds quite value :slight_smile:

1 Like