@Alex-Kushleyev Thanks Alex. Graphs look good. I am yet to stress test with these parameters but I was able to takeoff my drone with these parameters and it seemed to be very smooth. Will perform more tests in upcoming days and get back to you.
Posts made by Aaky
-
RE: M0117 ESC rough control
-
RE: M0117 ESC rough control
@Alex-Kushleyev Thanks Alex for such a detailed response and explanation. I will flash the parameters and check the response in flight and get back to you over this. Thank you once again!
-
RE: M0117 ESC rough control
@Alex-Kushleyev Following up over my query. If you have good tune and how you achieved it with the above mentioned motor and propeller set, please let me know.
-
RE: M0117 ESC rough control
@Alex-Kushleyev Sure Thanks Alex. Will follow this procedure for our current tests. Regarding calibration part, We generally do something like putting propeller in reverse direction where air is pushed upwards and not downwards and then run voxl-esc-calibration script. This also should yield good results for a0,a1 and a2 parameters to be derived?
-
RE: M0117 ESC rough control
@Alex-Kushleyev Thanks Alex for the information.
My propeller configuration is 6x4x3 as shown on this link. Please let me know if you can provide the tune.I will correct my num_cycles_per_rev parameter also min and max rpm.
Strange part is, last year when I tested my drone with these parameters it worked well around June 2023 was the timeline.
I actually caliberated pwm_vs_rpm_curve_a0, a1, a2 with propeller on motor and got those values in above xml files.
@Alex-Kushleyev said in M0117 ESC rough control:
the proportional and integral control is disabled, i assume you did this on purpose
How do we tune propotional and integral control? Please provide a tuning guide for these parameters.
-
RE: M0117 ESC rough control
Please have a look at RPM plots of my UAV while in air. There seems to be lots of fluctuations.
-
M0117 ESC rough control
Hello community,
I have been working with VOXL2 and M0117 VOXL ESC for controlling my custom drone. I started using this ESC when PX4 was on 1.12 version on VOXL2 old SDK. Then the drone used to fly nicely. This project was on pause for few months post which now I upgraded VOXL2 to latest SDK 1.1.2 and also M0117 to the latest available firmware which comes with SDK. Now the aircraft seems to be having extremely rough control where I can see motors struggling to keep aircraft in air and also occasionally maxing out as well as can be seen in the logs. This is the same motor, propeller and battery setup which worked beautifully on PX4 1.12 with old VOXL ESC firmware (I dont know the hash for that firmware version)Please check logs of my aircraft which shows unstable behaviour and also check the ESC configuration parameters. Btw I also caliberated the ESC again with propeller just to eliminate any issues from old parameters. I also successfully flashed and verified the parameters on all four ESC which went well.
Logs : https://review.px4.io/plot_app?log=fd6a4fdb-bc99-431b-b56d-b5288a3e6f91
ESC Parameters :
<?xml version="1.0" encoding="UTF-8"?> <!-- Copyright (c) 2020 ModalAI Inc. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. 4. The Software is used solely in conjunction with devices provided by ModalAI Inc. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. For a license to use on non-ModalAI hardware, please contact license@modalai.com --> <EscParameters> <IdParams> <param name="id" value="127"/> <!-- 0-7 .. 127 means use hardware ID pins to read ID--> <param name="dir" value="2"/> <!-- 0=fwd, 1=rev, 2=fwd id-based, 3=rev id-based --> </IdParams> <UartParams> <param name="protocol_version" value="2"/> <!-- reserved for future use --> <param name="input_mode" value="0"/> <!-- reserved for future use --> <param name="baud_rate" value="250000"/> <!-- communication bit rate --> <param name="char_timeout_ns" value="0"/> <!-- not used --> <param name="cmd_timeout_ns" value="100000000"/> <!-- timeout for incoming commands before ESC will stop the motor --> </UartParams> <TuneParams> <param name="pwm_frequency" value="48000"/> <!-- switching freqency of PWM signal going to motors. 24Khz and 48Khz are only options for now --> <param name="vbat_nominal_mv" value="14800"/> <!-- used for sanity checking and limiting of voltage-dependent funcions --> <param name="num_cycles_per_rev" value="12"/> <!-- number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm --> <param name="min_rpm" value="200"/> <!-- minimum RPM that will be attempted, otherwise capped --> <param name="max_rpm" value="25000"/> <!-- maximum RPM that will be attempted, otherwise capped --> <param name="min_pwm" value="50"/> <!-- cap for minimum power to be ever applied. max is 999 --> <param name="max_pwm" value="999"/> <!-- cap for maximum power to be ever applied. max is 999 --> <param name="pwm_vs_rpm_curve_a0" value="643.33705555"/> <!-- this is actually motor_voltage vs rpm curve.. using legacy naming --> <param name="pwm_vs_rpm_curve_a1" value="0.762820572544"/> <!-- Emax RS1306 3300KV with tri-blade 3x3x3 --> <param name="pwm_vs_rpm_curve_a2" value="0.000110277717331"/> <param name="kp" value="0"/> <!-- RPM controller proportional gain --> <param name="ki" value="0"/> <!-- RPM controller proportional gain --> <param name="max_kpe" value="00"/> <!-- maximum proportional erorr term (max is 999) --> <param name="max_kie" value="00"/> <!-- maximum integral error term (max is 999) --> <param name="max_rpm_delta" value="3000"/> <!-- cap for maximum rpm error used in RPM controller --> <param name="spinup_type" value="0"/> <!-- 0: traditional, 1: sinusoidal --> <param name="spinup_power" value="250"/> <!-- power used to during spin-up procedure --> <param name="latch_power" value="80"/> <!-- power used during latching stage of spin-up (out of 999)--> <param name="spinup_power_ramp" value="1"/> <!-- it will take ( 4096 / (spinup_power_ramp*10000) ) seconds to ramp sinusoidal start-up power from 0 to spinup_power --> <param name="spinup_rpm_target" value="1000"/> <!-- Desired RPM at the end of the sinusoidal spin-up procedure --> <param name="spinup_time_ms" value="1000"/> <!-- Duration of the sinusoidal spin-up procedure --> <param name="spinup_bemf_comp" value="1"/> <!-- 0: disable, 1:enable back-emf compensation in sinusoidal spin-up procedure --> <param name="motor_kv" value="1500"/> <!-- kV value of the motor. used in back-emf compensation during spin-up --> <param name="min_num_cross_for_closed_loop" value="50"/> <!-- exit latching mode of fixed power after this number of zero crossings --> <param name="protection_stall_check_rpm" value="1000"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor --> <param name="brake_to_stop" value="0"/> <!-- apply brake when stopping motor (or not) --> <param name="stall_timeout_ns" value="20000000"/> <!-- after spin-up, if no zero crossing is not detected for this amount of time, motor is considered stalled --> <param name="require_reset_if_stalled" value="0"/> <!-- require sending an array of zero commands to reset before next spin-up, if motor stalled --> <!-- The Entertainer --> <param name="tone_freqs" value="[118, 132, 105, 88, 99, 88, 83, 78, 1, 235, 0, 0]"/> <!-- 200 is 2000Hz, max 255 --> <param name="tone_durations" value="[30, 30, 30, 60, 30, 30, 30, 60, 60, 60, 0, 0]"/> <!-- duration of each tone in units of 10 milli-seconds. Poor naming!!! --> <param name="tone_powers" value="[100, 100, 100, 100, 100, 100, 100, 100, 0, 100, 0, 0]"/> <!-- max is 255 --> <param name="dt_threshold_ns" value="150000"/> <!-- during start up, ignore inter-commutation times less than this val, probably noise --> <param name="max_dt_ns" value="2500000"/> <!-- min and max values for time between two commutations. these are used as caps --> <param name="min_dt_ns" value="10000"/> <param name="dt_bootstrap_ns" value="2000000"/> <!-- filter bootstrap value for commutation dt during start up --> <param name="spinup_stall_dt_ns" value="60000000"/> <!-- during spin-up, if no zero crossing is not detected for this amount of time, motor is considered stalled --> <param name="spinup_stall_check_ns" value="30000000"/> <!-- time after beginning of spinup to start checking for spinup stall --> <param name="alignment_time_ns" value="0"/> <!-- alignment time before spin-up --> <param name="timing_advance" value="0"/> <param name="sense_advance" value="0"/> <param name="demag_timing" value="0"/> <!-- unused --> </TuneParams> </EscParameters>
ESC firmware version :
Firmware hash : eb6fb500
Bootloader hash : 25317f42
Mo117-1 ESC firmwareI am using Tmotor F2203 motor 1500 kv with 5 inch propeller. Also I am using 4S battery.
Does my ESC configuration file looks correct for given motors?
Please help debug this ahead. -
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Thanks for all the information Alex. Actually I got it solved, the problem was with my VOXL Power cable coming from VOXLPM. After changing this wire the reboot stopped. I am wondering if there was some loose connection which was causing the problem when GPU acceleration started over VOXL. I was monitoring the current consumption of my system with voxl-inspect-battery and I noted, that before running ML model it was 0.9 Amps and after ML acceleration it was rising to 1.2 Amps.
Few observations from voxl-inspect-cpu while ML acceleration started was temperature rising from 70 (No ML acceleration) to 80 (with ML acceleration). I am using YoloV5 over GPU and 50% GPU consumption I was able to see post acceleration. Maybe my video decoding is also hardware based with some GPU usage over there causing more GPU usage. -
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Apologies for trailing messages. Any update over this problem?
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev One more update in this respect, I am using libmodal-pipe version 2.10.0 on my SDK 1.1.3, this version of libmodal-pipe is I guess supported on next SDK 1.2.0. Can this be a problem? This came as dependency while installing voxl-mpa-tools I guess.
Say I update to SSDK 1.2.0, what should be exact voxl-opencv and voxl-mpa-tools version to be installed? I think they are conflicting somewhere leading to hardfaults.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev This issue is extremely urgent for me for some demonstration. My request is if you can provide me solution for this problem as soon as possible it would be really helpful.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Update: FPS changing dosent help. Still I am facing failure. On my above google drive I have uploaded my latest failing rtsp decoding python script, voxl-opencv debian, my startup service for kickstarting the RTSP decoding script and also voxl-mpa-tools debian. Please install them and see if there is any problem over SDK 1.1.3. voxl-mpa-tools I have cloned from here with branch pympa-experimental and voxl-opencv I have downloaded from this thread. There is some incompatibility causing this failure. Please let me know your analysis.
I even tried with tracking camera skipping RTSP decoding entirely and providing tracking camera feed to tflite model and then RTSP streaming, that is also having hard time. I am clueless about these failures. Also VOXL keeps rebooting and never comes out of reboot cycle randomly when tflite is active. Please help.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Thanks. One more observation, I tried setting FPS to 30 in the rtsp_rx_mpa_pub python script and those faults have stopped for moment. Is the FPS or any other parameter important in the RTSP MPA -> Tflite -> streamer pipeline?
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Can you try to play the same python file which I have attached above?
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev I tried disabling tflite. I ran rtsp_rx_mpa_pub.py with tracking camera rtsp url, went to voxl-portal and viewed rtsp-debug mpa pipe, then did some back and forth with home page of voxl-portal, voxl rebooted again. We are powering voxl with standard power supply with one end to 4S battery and other end to ESC and regulated power supply to VOXL2 in standard configuration. Culprit is multiple times opening of mpa pipe/rtsp url creates problem. Sometimes this fault comes at first time or sometimes randomly at n'th time.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Alex I confirm when I tried the local stream with tracking camera (since I dont have hires on my voxl), I am still getting hardfault even if I try to do "voxl-inspect-cam -a". Can you please urgently send me the deb files which you have installed over SDK 1.1.3 on your setup and also guide me further? Can this be hardware issue?
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Update: I was trying with 640x480 with hardware encoded stream and this time I opened RTSP stream over QGC and parallely opened tflite mp before rtsp over voxl-portal and voxl had some hard fault where it had reboot. There seems to be some memory leak/corruption happening in mpa publish pipeline (just an assumption). Please advise ahead.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev I tried 640x480 resolution and its working consistently across multiple reboots. I am still stress testing this but not sure when I might fail. Now I shifted back to hardware decoding with 640x480 resolution.
-
RE: VOXL2 RTSP decoding fails
@Alex-Kushleyev Thanks for quick response. I tried only viewing rtsp to mpa over voxl-portal and it failed once, on next reboot it didnt failed there and failed when I opened tflite mpa. So my suspicion is on the mpa publishing. Failure even happens if I close rtsp mpa by clicking on "VOXL-PORTAL" icon and again opening the mpa. Also on tflite I am using YoloV5 and passing IMAGE_FORMAT_RAW8 1920x1080p stream after RTSP decoding.
-
VOXL2 RTSP decoding fails
Hello community,
I am using SDK 1.1.3 with VOXL2. I have usecase where I need to decode RTSP stream from my gimbal camera and pass it to voxl-tflite-server for inferencing. I referred to this thread and was able to run the example code rtsp_rx_mpa_pub.py. I had to modify the python code a bit to provide it as input to voxl-tflite-server. All works fine now except sometimes randomly VOXL reboots while I open tflite stream on voxl-portal. I have also installed voxl-mpa-tools and voxl-opencv with python3 bindings provided on above mentioned link still this failure happens sometimes.Here is link to my modified rtsp_rx_mpa_pub.py and dmesg log file. I have tried both hardware decode and software decoder but problem stays the same. I think something related to mpa publishing is not compatible/incorrect since visualization services are failing. I am also getting failure over RTSP stream after generating the same via voxl-streamer.
Link : https://drive.google.com/drive/folders/1hfWALmpOEE3ouGyjCPUfFD0jJuGnKjsH?usp=drive_link
@Alex-Kushleyev Please help over this problem. This is bit urgent for me.