Configuring Orel for particular motor

Support Sapog motor control
1

Greetings Pavel!
So here is the thing, I would like to use the Orel ESC (or shall I say, Sapog, because I assume Orel is hardware, Sapog is software, right? Btw, very curious, does Sapog name have something to do with russian word sapog, as in shoe? :smiley: )
with my custom made motor to fly a copter. Iā€™m using 4 cell battery Li ion battery pack, and the motor parameters are following:

950KV
Height 23.5
Diameter 41.8
Rated current 20A
Rated output power 225W
no load current (10V/A) 0.5-1A
no load speed (10V/rpm) 9450 rpm
winding resistance 50mOhms
14 poles

So when I connected the motor to the ESC on default settings, I was getting some unstable spinup, and sometimes the rotor would stall even, if I tried to spin it up to a certain RPM. I was experimenting with tweaking the configuration according to the documentation but, still havenā€™t achieved satisfying results.

Also, Another thing, I have noticed is that is you spin up the motor really fast (~4k rpm) and then put the throttle down, and while rotor is still spinning, go up with throttle again, the motor might fall out of synchronization and stall. This is something you donā€™t want on copter, right. But this behavior I noticed on all kind of escā€™s, even commercially sold, so perhaps it has to do something with the back emf not being large enough when the rotor is freely spinning, thus why esc loses synchronization, but not sure about that.
Another observation that Iā€™ve made, is that if you change rotation speed drastically, letā€™s say from a 1k rpm to 5k rpm, quite often the esc would produce a current spike, and my battery protection circuit would cut off, which again is a major issue. In fact, the whole research Iā€™m doing now is due to several crashes due to esc producing current spikes.

So my question, would be: ho to configure the ESC properly, specifically all the timings? Iā€™m guessing my current spikes issue is mainly due to synchronization fails.
Perhaps you could guide me to some literature, or articles, because I am relatively new to sensorless bldc motor control.

This post may be a little chaotic, so if any extra details about the nature of problems or trials that Iā€™ve been conducting is needed, please do ask.

2

Hi,

Truth be said, yes, Sapog is Russian for ā€œbootā€, itā€™s a long story. Your assumption that Sapog is the name of the software and Orel 20 is the hardware is correct.

You can combat current spikes by slowing down the acceleration ramp (see parameters mot_dc_accel and mot_dc_slope), and/or limiting the current (see mot_i_max).

Concerning the reliability, we have Sapog v2.0 coming up, it should be available quite soon - Iā€™ll make a public announcement when itā€™s ready. It will bring improved stability and a much better spinup algorithm. You can follow the progress here: github.com/PX4/sapog/pull/22

Re literature, once the version 2.0 is out I will attempt to expand the documentation in order to make it more comprehensible for a person not familiar with electric drive theory.

Thanks!

3

Hi Pavel,

Thanks for pointing out that there is beta 2.0 version of sw, somehow I didnā€™t even notice that there were branches in the git, silly me.
It works just splendidly compared to the 1.0-1.8 that Iā€™ve been using previously. It solved the issue with rotor stalling completely, spinup is just perfect, and I wasnā€™t yet able to shut off the battery! Great improvements. And it was all on the default settings. So I will continue tests with the 2.0

It would be great if you will expand the documentation, but I also would like to learn about control, so maybe you could point me in the right direction (some books, forums, articles etc) I have electronics background, so Iā€™m able to take in any level of material difficulty, itā€™s just that the motor field is new for me.

P.S. I would indeed like to hear that story, you can even tell it ŠæŠ¾ руссŠŗŠø :slight_smile:

Thank you for your time.

4

I must warn you that currently the beta has known startup difficulties in certain operating conditions, especially if the rotor is loaded at the time of starting. A fix should be coming within the following few days.

Re the naming story, it will remain classified for a while, since we donā€™t speak Russian on this forum. :wink:

5

Hello again Pavel,

Another issue just arose, as I go further with integration of sapog into my application.
Previously I was configuring all the parameters via command line over uart interface. Now, as I got usb-can adapter, particularly USBtin I was able to connect to the esc via can. ESC panel works fine, and I had no problems plotting any of the parameters, however, when Iā€™m trying to fetch all the parameters, I get ā€œrequest timed outā€ message. Also CAN Adapter Control Panel doesnā€™t work, as it says that the adapted does not support CLI extensions. So my main question is, is it because of my can adapter? Or is it hardware, or software problem?
Another weird thing is that the name of the node in the list is almost always a question mark, and only sometimes changes to io.px4.sapog, under some circumstances which nature I did not yet understand.

Also Iā€™m testing everything without pixhawk yet - that shouldnā€™t be an issue here?

And again, any advice would be very much appreciated,

Best regards

6

AFAIK USBtin is quite buggy, so it could be losing frames due to RX queue overflow while receiving the responses. You should use a real CAN adapter, such as Zubax Babel, or 8devices USB2CAN, or Peak Systems, et cetera. The CAN adapter control panel only works with Zubax Babel, since other SLCAN adapters do not offer any features that might require additional configuration. The node name thing can also be caused by your adapter losing frames.

Pixhawk is not required for testing.

I must also suggest you that if youā€™re running the beta 2.0, you really should upgrade it with the newest changes I merged yesterday.

Thanks!

7

I see, so it is mos likely the adapterā€™s fault. By default there was no terminator resistor, so once Iā€™ve enabled it, it became slightly stabler, but still, I canā€™t get full parameters list. Sometimes it would fetch up to 6-8 parameters.
So, excuse me my incompetence, but perhaps lowering the baudrate could help? If this possible at all, that is.

And yes, I saw and read the commits, and already am using the latest version.

8

Yes lowering the bit rate should help, try that. Sapog supports the following bit rates: 125k, 250k, 500k, 1M. In order to detect the new bit rate they need to be rebooted.

9

And it did help, after lowering bit rate down to 125k, I was able to successfully fetch all the parameters from all escā€™s, and name issue also resolved itself.

Also, I made another interesting observation while testing. The esc had firmware 1.8, and at one point, when I made step from 5000rpm to 8000rpm the rotor stalled for a split of a second, and an electric arc formed between C35 +VBAT lead and current shunt. I immediately disarmed the esc. Oddly enough, battery didnā€™t cut off right away, there was some delay. But what is more concerning - the escā€™s own current cutoff didnā€™t work at all.

We were testing some other off the shelf escā€™s by manually stopping the rotor, and most of them were just heating up, but none caught on fire. So Iā€™m thinking to perform the same test as well.

10

Normally there should not be an arc under normal operating voltages. Perhaps there are some debris on the board that caused it?

11

Well, I also thought so, however it happened not just on one board. Well, I think, since on firmware version 1.8 there were some commutation issues, that rpm rapid change which stalled the rotor caused excessive voltage on C35.
Moreover, my friend with whom we work on this project decided to test the ā€œoveral robustnessā€. On a newest firmware he spun up the rotor up to 8k rpm, and stopped it by hand (obviously propeller was not involved). What happened was the following: we observed an arc forming in the same spot, shortly after what the whole thing bursted into flames :smiley: Needless to say that it was as spectacular fireshow. The result of that show you can observe on the picture.

And no, there was no debris, nor soldering shorts, that I can fully assure.

12

Wait, these boards arenā€™t Orel 20. This is what Orel 20 looks like: docs.zubax.com/zubax_orel_20

These are either early prototypes, or they were not made by Zubax. Where did you get them from? :wink:

13

Indeed they are not made by Zubax :slight_smile: I took hardware reference design from PX/Hardware repository, where it resides under CC-BY-SA-3.0 license, and ordered it at our local PCB manufacturer. Appropriate copper thicknesses were used, 70um if Iā€™m not mistaken.

Judging from the pictures, I donā€™t see major differences, if any, layout seems to be the same, only mounting holes are add and some different parts are used.

14

That explains a lot! See, your capacitor seems to have exploded. Capacitors normally shouldnā€™t do that, unless they are tantalum and over-voltaged. Please review your BOM choices in the next batch.

15

Exactly over-voltaged or overheated, but capacitor that Iā€™ve used is rated 35V, and as I see, in the Orel 20 25V capacitor is even used. So either voltage was greater than 35V, or the arc that formed heated up the capacitor. Then rises the question - why that arc appeared in the first place.
Sadly, I didnā€™t log parameters on the one which exploded, I did not expect my friend would decide to conduct suchā€¦ ā€œtestā€. But I wonder why over-current protection didnā€™t cut off, or over-temperature? Because, if my battery shuts off, it means there are current spikes over 60A and one esc is rated to 20. Is there any power cutoff mechanism in case of over-current? I yet need to study your software more closely.

Have you considered using snubber circuits on the phases?

16

Our motor control guru has suggested that an arc can be sometimes formed due to residual flux being left on the surface of the board. There can be about a dozen of other possible reasons, but that talk would go outside of the scope of this forum, so Iā€™m not going to expand on this now. We could not reproduce the problem on our production boards.

Yes there is an over-current protection, but it is implemented in software and it is not designed to protect against very short spikes. The over-voltage protection is implemented with the TVS diode seen on the right; make sure yours are working well.

The snubber circuits are not required for this low-power design.

17

I think I found the problem. As you mentioned, that TVS diode is over-voltage protection, so I took closer look at what kind of TVS Iā€™m using, and I found out that I mistakenly put TVS with clamping voltage of 52V.

I will replace TVS diodes the escā€™s and will continue my research.

Meanwhile, thank you for helpful tips.

18

Hello again, Pavel.

As the problem with TVS resolved itself, I stumbled into a new one. Iā€™m not sure if itā€™s worth starting new topic, so Iā€™ll write here.

So the thing is, that when I run my copter, attached to the ground, there are certain throttle values at which the motor stalls, and simply isnā€™t moving until I move throttle at least a little.

Sapogā€™s are controlled via pwm.

Any ideas what could cause that?

19

Yes, the most likely reason for that is that the flight controller is outputting very low setpoints on some channels, hence some motors just stop.

On an unrelated note, you should upgrade to the latest firmware v2.2, unless you havenā€™t done so yet. It has nothing to do with the observed behavior though.

We also have a new reference manual published here: files.zubax.com/products/io.px4 ā€¦ Manual.pdf

20

Yes, I already updated to version 2.2, and have skimmed across the new manual. Btw, manual looks really cool, nice work there, very in depth.

So, I also thought that flight controller is outputting very low setpoints, and hooked up oscilloscope. What I saw, was that setpoints were never below the limit of 1030, which is standard 1000+3% usec. However, when the motors were stalling, I noticed some disturbances on the signal, which I assume might have been interpreted by sapog as low setpoint, or too long pause between impulses.

What is different on this setup, from one that I was successfully flying on earlier, is that I didnā€™t connect GND form sapog multipurpouse connector, and relied just on common ground through power wires. Could that have caused this problem?