In our project we are using 4 peace of T200 thrusters and Basic ESCs for positioning and navigating our floating robot. Unfortunately the SW guys had a problem with the propulsion system while implementing the control loop. It ends in a bang-bang with 10 degree in yaw. The identified root cause is comes from the ESC reaction time and min trust.
minimum thrust:
Do you know any possibility to reduce the minimum generated thrust by the T200?
timing:
Our electronics generate 100Hz 1-2ms signal for commanding the ESCs based on an USB interface. it has a maximum 20msec delay in generating the new value for the ESC.
I measured the time between the ESC gets the first command to move and starting to change anything on its output and the time vas something around 110msec (plus/minus 10msec). I think it is a slightly large delay in the ESC reacting on 1500us to 1700us signal.
Is it a really known behavior?
Can it be reduced somehow?
Our T200 technical details have detailed information on the thrust characteristics, including performance charts showing thrust vs input signal for a given powering voltage. At a guess, is your control loop failing to account for the dead band around the stopped point?
This may also be a dead band issue - how are you measuring it? I expect the ESC should update its output speed based on each pulse it gets sent, but understandably those updates only noticeably occur when the thruster is actually able to move.
Our BasicESC detects inputs with a pulse duration between 1100-1900us, but you’re providing those pulses at 100Hz, so the ESC receives an update every 10ms. It may be a bit faster to run at 400Hz (the ESC’s max input PWM frequency), but if the ESC does in fact update every pulse then that would change the expected ~30ms delay into ~22.5ms, since there’s already the 20ms delay from your PWM generator.
Blockquote
Our T200 technical details have detailed information on the thrust characteristics, including performance charts showing thrust vs input signal for a given powering voltage. At a guess, is your control loop failing to account for the dead band around the stopped point?
Let me ask the responsible guy.
Blockquot
This may also be a dead band issue - how are you measuring it? I expect the ESC should update its output speed based on each pulse it gets sent, but understandably those updates only noticeably occur when the thruster is actually able to move.
I prepared 2 measurement.
1 for testing my system with the PWM generation. In this measurement I made a test SW to indicate the start of the PWM generation. I set a microcontroller pin to high if the command was received to start the generation of the PWM signal. So basically a no generate->generate signal state transition was used for the measurement. The white signal indicates the command received time and the blue signal indicates the generated PWM signal for the BasicESC.
Another test were performed to measure the reaction time of the BasicESC.
In this measurement the white signal is generated by my microcontroller (in the test SW) to indicate the 1500us to 1700us transition and back. It is high if the signal is 1700us and it is low if the signal is 1500us . The blue signal indicates one of the phase of the T200. I think it is more accurate way to identify the delay of the BasicESC.
I already identified if I increment the PWM generation frequency to 400Hz instead of 100Hz the delay of my system will be reduced. So this measurement were made with 400Hz to reduce the complete delay.
It may be a bit faster to run at 400Hz (the ESC’s max input PWM frequency), but if the ESC does in fact update every pulse then that would change the expected ~30ms delay into ~22.5ms, since there’s already the 20ms delay from your PWM generator.
I don’t understand what the image is showing. The stated Time Delay appears to be from the rise of the white signal to the fall of the constant part of the blue signal, but if the blue signal is supposed to be motor phase then I’m not sure why it’s so inconsistent once it’s engaged - there shouldn’t be a gap of several milliseconds where it’s stopped.
If you’re specifically interested in the delay between ESC input and output it may make more sense to replace the white signal with the ESC’s input PWM signal. It should be visible when the 1500 vs 1700us pulses occur, especially if your PWM frequency is 400Hz.
You said your PWM generator has a 20ms delay from when it’s commanded to change to when it actually changes. The ESC determines speed by pulse duration within each PWM cycle, so if it’s receiving pulses at 100Hz then it gets one pulse every 10ms, and if it’s receiving pulses at 400Hz it gets one pulse every 2.5ms. Adding 20ms to the PWM cycle times gives 30ms and 22.5ms respectively.
My calculation didn’t take account of the fact that the pulse itself needs to complete before an update can occur, so depending on how that’s done it could either require two cycles before an update is possible, or it could require one cycle plus one pulse (1.1-1.9ms), so the expected delay for your system is perhaps more accurately 40ms/31.1-31.9ms at 100Hz, or 25ms/23.6-24.4ms at 400Hz.
As I mentioned before, it makes the most sense to me if the ESC updates speed after every pulse, but it’s possible that intuition is wrong - I haven’t looked at the source code so don’t know for sure. I’ve asked our engineering team in case someone else has further insight
The stated Time Delay appears to be from the rise of the white signal to the fall of the constant part of the blue signal, …
The stated time is measured from the rising edge of the white signal ( command received by the microcontroller) to the rising edge of the blue signal ( one of the motor phase).
If the ESC should react on the first PWM signal than I expecting the following measurement:
1, white signal goes high as indicating new command was received to set 1700us instead of 1500us as the PWM signal
2, I am expecting some delay on microcontroller level between the command received and PWM signal generated with the new value. This delay was measured as maximum 20ms on 100Hz.
3, Blue signal starts to change as indicating the thruster is started
Instead of the expected behavior the seeable behavior is the following based on the measurement:
1, white signal goes high as indicating new command was received to set 1700us instead of 1500us as the PWM signal
2, I am expecting some delay on microcontroller level between the command received and PWM signal generated with the new value. This delay was measured as maximum 20ms on 100Hz.
3, Blue signal not indicating the change for about 100ms.
4, Blue signal starts to change as indicating the thruster is started
If you’re specifically interested in the delay between ESC input and output it may make more sense to replace the white signal with the ESC’s input PWM signal. It should be visible when the 1500 vs 1700us pulses occur, especially if your PWM frequency is 400Hz.
Basically you are right. We run these rounds internally. It would be the best measurement. But unfortunately our oscilloscopes are not able to trigger a measurement for PWM signal changes from 1500us to 1700us. (I even not sure there are any which can.)
So the used measurement was divides this problem to 2 part. The first part is measuring the delay between the command received by the uC (indicated by the white signal). It was max 20ms on 100Hz. The second part is measuring the ESC output reaction on the command received. It was measured maximum 130ms. So if we conclude the two measurement we can calculate the time delay of the ESC: ~130ms - ~20ms = ~110ms.
As I mentioned before, it makes the most sense to me if the ESC updates speed after every pulse, but it’s possible that intuition is wrong - I haven’t looked at the source code so don’t know for sure. I’ve asked our engineering team in case someone else has further insight
I spoke with our software team about this, and they echoed my sentiment that starting from stationary (a “cold start” so to speak) may not be representative of the behaviour for changes while the thruster is already moving.
On the “triggering on PWM change is difficult” front, could you perhaps just try recording for a set period (instead of triggering) and scrolling through the recording to find where the PWM duty cycle changes, and take a timing measurement there? With that kind of approach you could presumably use PWM durations of say 1600 and 1700us, and use cursors on the time axis to see the changeover point (where the PWM pulses get thicker/thinner).
