ModalAI Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. John Nomikos 0
    3. Posts
    • Profile
    • Following 0
    • Followers 0
    • Topics 14
    • Posts 61
    • Best 0
    • Controversial 0
    • Groups 0

    Posts made by John Nomikos 0

    • Possible bug when calibrating ESCs on ModalAI's custom 1.14 flight core v2 firmware

      Good afternoon,

      Today I was attempting to calibrate my ESCs when I ran into a strange issue. I press the "Calibrate" button to calibrate the PWM escs, but nothing happens. I tried this on multiple versions of QGC.

      I am using the custom 1.14 firmware available here: http://voxl-packages.modalai.com/dists/fc-v2/sdk-1.1/

      As a note, this FCV2 serves as an external flight controller for the VOXL2, and the ESCs are plugged into the flight core.

      Also, I was following the regular instructions for calibrating ESCs. I plugged into the FCV2 via USB.

      Interestingly enough, I flashed the stable release 1.14 firmware and did not see the same issue. I was able to calibrate the ESCs with no issues on the stable 1.14 firmware.

      --

      Another (slightly) related question. What is the difference between the custom Flight Core V2 firmware that ModalAI provides and the stable release? I am curious if it is a bad idea for me to use the 1.14 stable release.

      posted in Flight Core v2
      John Nomikos 0J
      John Nomikos 0
    • Connecting to Flight Core V2 stalls and fails with one of our flight core V2s

      Good afternoon,

      We are running into an issue with a Flight Core V2 that a client ordered.

      In our setup, the Flight Core V2 is connected to a VOXL2 as an external FCU.

      Whenever I connect to the Flight Core V2 through the VOXL2 via Ethernet or the Doodle Radio on QGroundControl, the connection stalls in the middle. Then I get this error message:

      1fda4ed5-2b3c-4b87-bc41-f76ca972f3d6-image.png

      This connectivity issue also occasionally happens when connected over microusb, but it is not consistent like ethernet or doodle. Sometimes it connects fine on microusb.

      This Flight Core V2 is using the Modalai Flight Core V2 firmware provided here:
      http://voxl-packages.modalai.com/dists/fc-v2/sdk-0.9/

      But we also tried modalai's 1.13.2 firmware as well.

      After every firmware flash, we would reset params to factory defaults.

      What I've Tried:

      We have a few flight core v2s we have in-house that do not have the same issues, and they are on the exact same firmware version.

      1. Swapped the flight core v2 with a working one and tested. Could not replicate the issue. This working one had a yellow JST while the one that had issues had a white JST on J12. Tried a working one we have that has a white JST and also could not replicate the issue.

      2. Swapped the non-working one's SD card with the working one's SD card. Could not replicate the issue on the working one.

      Why I think this is possibly a kernel/hardware issue:

      I flashed the exact same firmware on the flight core v2s we have in-house and made the parameters the exact same as well. However, I could never recreate the issue with the ones in-house.

      Firmware Version Information:

      VOXL2 - SDK 1.0

      FCV2 - 639b1e40-7a41-4117-97c9-30d74aa137de-image.png

      posted in Flight Core v2
      John Nomikos 0J
      John Nomikos 0
    • RE: Issues Getting voxl-streamer video stream working through RTSP stream on Doodle Labs Helix Radio

      @wilkinsaf I completely agree. We can compare to a normal USB camera as well to see if the issue is with specifically streaming from the HDMI to USB capture card

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: We need more UART ports. Could we use the UART ports on the VOXL2 board?

      @John-Nomikos-0

      I found this info about DSP UARTs being available for use with external flight controllers starting in SDK 1.1.

      https://docs.modalai.com/voxl2-external-flight-controller/#dsp-uarts-via-apps-proc

      So I will try upgrading to SDK 1.1, connecting an external flight controller to DSP UART, and then connecting the gimbal to the UART on top of the 5G hat.

      I wonder if it will work if my external FCU is on Ardupilot and I'm using mavlink_router instead of voxl-mavlink-server

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: We need more UART ports. Could we use the UART ports on the VOXL2 board?

      @John-Nomikos-0

      I do see that there is info on doing this with the VOXL1 using libvoxl_io:

      https://docs.modalai.com/voxl-serial-io/

      I did find libqrb5165_io. Is this used for the same purpose?

      https://gitlab.com/voxl-public/voxl-sdk/core-libs/libqrb5165-io

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • We need more UART ports. Could we use the UART ports on the VOXL2 board?

      Good afternoon,

      On our setup, we are using a VOXL2 with a 5G hat which is connected to an external flight controller (cube). That external flight controller uses Ardupilot. All of our telem ports on the external flight controller are being used. The UART port that the 5G hat has is being used to communicate with the external flight controller.

      What are your best recommendations on getting another UART port to use with a gimbal?

      I notice that there is both port J18 (UART ESC) and J19 - External Sensors (2x UART/ 2x I2C). Can any of the UARTs be used with a gimbal and be intractable through linux? I know that the UARTs on the bare board are supposed to communicate with PX4 through the DSP but I was wondering if there is a way to expose these to be used just like any other UART port?

      Thank you,

      John Nomikos.

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • Issues Getting voxl-streamer video stream working through RTSP stream on Doodle Labs Helix Radio

      Good afternoon,

      Recently, I've been attempting to configure a setup on the VOXL2 that uses a doodle labs helix radio and a gremsy gimbal.

      HDMI from the camera on the gremsy is routed through an HDMI capture card to USB-C on top of the naked 5G expander board. And USB from the doodle is going through USB-2 on the board.

      I have been able to successfully get the camera going on voxl-uvc-server and it is outputting frames. I have also been able to view the stream through Ethernet and it looks smooth. It is running on a 640x480 stream at around 1 mbps.

      However, when using the doodle radio, the stream will cut out immediately to the point where it is unviewable.

      I've tried both decreasing and increasing the bitrate and ran into the same problems. I also tried moving one doodle further away from the other and the stream kept cutting out. However, I can still control the gimbal fine.

      Also, here is the output I was getting from voxl-streamer when the stream kept cutting out and not connecting on ATAK:

      voxl2:/$ voxl-streamer --standalone --port 8903 -i gremsy
      Waiting for pipe gremsy to appear
      Found Pipe
      ERROR: object missing width
      WARNING: Failed to fetch one or more of width, height, into_format, framerate from pipe info file
      WARNING: going to connect to the pipe for 1 frame to inspect it now
      WARNING: grabbed the data from the actual pipe and closed it
      detected following stats from pipe:
      w: 640 h: 480 fps: 0 format: YUV422
      Stream available at rtsp://127.0.0.1:8903/live
      A new client rtsp://10.223.0.150:46914(null) has connected, total clients: 1
      Camera server Connected
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      ERROR:   New frame rejected, status = -2
      rtsp client disconnected, total clients: 0
      no more rtsp clients, closing source pipe intentionally
      A new client rtsp://10.223.0.150:46916(null) has connected, total clients: 1
      Camera server Connected
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      ERROR:   New frame rejected, status = -2
      rtsp client disconnected, total clients: 0
      no more rtsp clients, closing source pipe intentionally
      A new client rtsp://10.223.0.150:46918(null) has connected, total clients: 1
      Camera server Connected
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      rtsp client disconnected, total clients: 0
      no more rtsp clients, closing source pipe intentionally
      A new client rtsp://10.223.0.150:46920(null) has connected, total clients: 1
      Camera server Connected
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      gbm_create_device(156): Info: backend name is: msm_drm
      ERROR:   New frame rejected, status = -2
      rtsp client disconnected, total clients: 0
      no more rtsp clients, closing source pipe intentionally
      

      This "new frame rejected" error would continue on and on, over and over again.

      This is on platform 1.0.0
      voxl-streamer is version 1.7.1
      voxl-uvc-server is version 0.1.3

      I was wondering if there are recommended camera settings I should set on voxl-streamer to work with the doodle radio, or if there is insight on the errors voxl-streamer is running into.

      Thank you,

      John Nomikos.

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      Apologies, this file is not up to date from when I left off. I changed spinup_bemf_comp to this
      <param name="spinup_bemf_comp" value="1"/>

      and power back to 80.

      Everything else on this file should be the same. Here's updated:

      <?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="2000000"/>     <!-- 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="6"/>      <!-- number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm -->
          <param name="min_rpm"             value="2000"/>   <!-- minimum RPM that will be attempted, otherwise capped -->
          <param name="max_rpm"             value="35000"/>  <!-- maximum RPM that will be attempted, otherwise capped -->
          <param name="min_pwm"             value="70"/>     <!-- 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="366.028455487"/>  <!-- this is actually motor_voltage vs rpm curve.. using legacy naming -->
          <param name="pwm_vs_rpm_curve_a1" value="0.267931384448"/> <!-- Emax RS1306 3300KV with tri-blade 3x3x3 -->
          <param name="pwm_vs_rpm_curve_a2" value="5.77024053745e-06"/>
          <param name="kp"                  value="0"/>    <!-- RPM controller proportional gain -->
          <param name="ki"                  value="0"/>     <!-- RPM controller proportional gain -->
          <param name="max_kpe"             value="0"/>    <!-- maximum proportional erorr term (max is 999) -->
          <param name="max_kie"             value="0"/>    <!-- maximum integral error term (max is 999) -->
          <param name="max_rpm_delta"       value="2000"/>    <!-- cap for maximum rpm error used in RPM controller -->
          
          <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
          <param name="spinup_power"        value="80"/>     <!-- power used to during spin-up procedure -->
          <param name="latch_power"         value="70"/>     <!-- power used during latching stage of spin-up (out of 999)-->
          <param name="spinup_power_ramp"   value="8"/>      <!-- 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="3300"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
          <param name="spinup_time_ms"      value="500"/>   <!-- 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="2400"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->
      
          <param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
          <param name="protection_stall_check_rpm" value="700"/> <!-- 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 -->
      
          <param name="tone_freqs"          value="[100, 115, 225, 250, 0,0,0,0, 0,0,0,0]"/> <!-- 200 is 2000Hz, max 255 -->
          <param name="tone_durations"      value="[30,  10,  10,  10,  0,0,0,0, 0,0,0,0]"/> <!-- duration of each tone in units of 10 milli-seconds. Poor naming!!! -->
          <param name="tone_powers"         value="[60,  60,  60,  60,  0,0,0,0, 0,0,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="6000000"/>     <!-- 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>
      
      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Alex-Kushleyev

      Sure thing. Here's the entire XML file of params I was using on the new firmware that I could not take off with:

      <?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="2000000"/>     <!-- 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="6"/>      <!-- number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm -->
          <param name="min_rpm"             value="2000"/>   <!-- minimum RPM that will be attempted, otherwise capped -->
          <param name="max_rpm"             value="35000"/>  <!-- maximum RPM that will be attempted, otherwise capped -->
          <param name="min_pwm"             value="70"/>     <!-- 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="366.028455487"/>  <!-- this is actually motor_voltage vs rpm curve.. using legacy naming -->
          <param name="pwm_vs_rpm_curve_a1" value="0.267931384448"/> <!-- Emax RS1306 3300KV with tri-blade 3x3x3 -->
          <param name="pwm_vs_rpm_curve_a2" value="5.77024053745e-06"/>
          <param name="kp"                  value="0"/>    <!-- RPM controller proportional gain -->
          <param name="ki"                  value="0"/>     <!-- RPM controller proportional gain -->
          <param name="max_kpe"             value="0"/>    <!-- maximum proportional erorr term (max is 999) -->
          <param name="max_kie"             value="0"/>    <!-- maximum integral error term (max is 999) -->
          <param name="max_rpm_delta"       value="2000"/>    <!-- cap for maximum rpm error used in RPM controller -->
          
          <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
          <param name="spinup_power"        value="130"/>     <!-- power used to during spin-up procedure -->
          <param name="latch_power"         value="70"/>     <!-- power used during latching stage of spin-up (out of 999)-->
          <param name="spinup_power_ramp"   value="8"/>      <!-- 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="3300"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
          <param name="spinup_time_ms"      value="500"/>   <!-- Duration of the sinusoidal spin-up procedure -->
          <param name="spinup_bemf_comp"    value="0"/>      <!-- 0: disable, 1:enable back-emf compensation in sinusoidal spin-up procedure -->
          <param name="motor_kv"            value="2400"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->
      
          <param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
          <param name="protection_stall_check_rpm" value="700"/> <!-- 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 -->
      
          <param name="tone_freqs"          value="[100, 115, 225, 250, 0,0,0,0, 0,0,0,0]"/> <!-- 200 is 2000Hz, max 255 -->
          <param name="tone_durations"      value="[30,  10,  10,  10,  0,0,0,0, 0,0,0,0]"/> <!-- duration of each tone in units of 10 milli-seconds. Poor naming!!! -->
          <param name="tone_powers"         value="[60,  60,  60,  60,  0,0,0,0, 0,0,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="6000000"/>     <!-- 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>
      
      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      Successfully was able to arm and fly with older esc firmware on default params. Thank you for all the help

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Alex-Kushleyev Thank you. Successfully uploaded params

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Alex-Kushleyev said in (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm):

      python3 voxl-esc-upload-params.py --params-file

      So I successfully flashed the firmware on all 4 ESCs. But uploading params gave me this error

      voxl2:/usr/share/modalai/voxl-esc-tools$ python3 voxl-esc-upload-params.py --params-file /esc_params_modalai_4_in_1_revb.xml 
      Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) 
      [GCC 8.4.0]
      Found voxl-esc tools bin version: 1.2
      
      INFO: Params file name : /esc_params_modalai_4_in_1_revb.xml 
      INFO: Params file size : 6971 bytes
      
      
      VOXL Platform: M0054
      Detected VOXL2 M0054 or M0104!
      Found previous connection information in .voxl_esc_cache ..
      Prioritizing /dev/slpi-uart-2 @ 2000000
      INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
      Sending library name request: libslpi_uart_bridge_slpi.so
      Received standard error event 2
      Sending initialization request
      INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 250000
      INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 921600
      INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 230400
      INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 57600
      INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 57600
      INFO: ESCs detected:
      INFO: ---------------------
      ID: 0, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
      ID: 1, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
      ID: 2, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
      ID: 3, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
      ---------------------
      ERROR: ESC firmware version 36 is incompatible with params supported by this utility
             Acceptable ESC firmware versions are:  [38]
      

      I think voxl-esc-upload-params is checking for the version. I could modify it and try again, unless there is an earlier tool meant for this firmware

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: lightware i2c lidar - voxl m500 with flight core v2

      Tested on 1.12.2, seeing same issue

      posted in Ask your questions right here!
      John Nomikos 0J
      John Nomikos 0
    • RE: lightware i2c lidar - voxl m500 with flight core v2

      @Eric-Katzfey

      So it's possible that there is a race condition in that the unit powers up but is not yet ready when px4 attempts to communicate with it.

      I tried powering the lightware lidar via microusb and keeping all else the same to see if there was that race condition.

      I found that even if the lightware lidar is already on and continually getting power from the microusb, the flightcore v2 still will not detect it unless it gets plugged in after the flightcore v2 turns on

      posted in Ask your questions right here!
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Alex-Kushleyev Thank you so much for the help. I will try this next week. Have a great weekend!

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Alex-Kushleyev said in (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm):

      Yes i can provide you with old firmware for m0117 (the original firmware you had before). You will need your old ESC params. All this can be done right from voxl2 without unplugging. I will follow up tomorrow morning.

      Sounds good. I don't think we ever changed the ESC params on the old firmware version. So they would be whatever the ESC came out of the factory with. I'm assuming there are default parameters available for the old firmware, right?

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      @Eric-Katzfey Maybe there's something with my ESC firmware parameters that's causing issues?

      I'm going to try to flash an esc config that is used on a modalai drone to see if it's any different

      Also, is there an easy way to go to the previous ESC firmware version without manually plugging in? I want to go back to see if this is due to the firmware flash in a time-efficient manner. I'm pretty sure there isn't but I wanted to make absolute sure

      Also it is on a custom drone, but we got our drone flying with the exact same parameters on the previous ESC version on 1.0.0. Really is seeming like an ESC firmware issue to me.

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0
    • RE: lightware i2c lidar - voxl m500 with flight core v2

      Also running into problem where device is not detected unless plugged in after FCV2 is already powered when running
      lightware_laser_i2c start -X

      This is on PX4 1.13.2 as well

      posted in Ask your questions right here!
      John Nomikos 0J
      John Nomikos 0
    • RE: lightware i2c lidar - voxl m500 with flight core v2

      I am running into this issue as well. I found there is an active issue on PX4 related to this sensor not starting automatically on startup here:

      https://github.com/PX4/PX4-Autopilot/issues/17308

      posted in Ask your questions right here!
      John Nomikos 0J
      John Nomikos 0
    • RE: (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

      Just to clarify, I am still unable to fly with the most recent ESC firmware. All of the motors are mapped correctly and the props are on right, but the drone still seems to eat dirt whenever I throttle it up. It even completely flipped over once. I tried in manual mode and same story.

      Any other suggestions? I'm starting to run out of ideas 😢

      posted in VOXL 2
      John Nomikos 0J
      John Nomikos 0