Hi @Martin-Lukac ,

Thank you for the update. I am glad to see that your new tests went fine. As I mentioned before, i was quite surprised to see the ESC fail in such a way, which may suggest some kind of anomaly.

I will provide a longer answer soon, but for now some quick notes:

non-zero kp / ki parameters will speed up the ESC's RPM response. I will provide some examples you can test whether the ESC closed-loop controller is stable using voxl-esc tools, using step inputs, etc. if unstable, lower Kp. Then lower Ki to avoid slow overshoots. Ki will definitely not contribute to high frequency oscillations. assuming the ESC closed loop response is stable, if the Flight Controller is commanding noisy RPMs, the ESC with aggressive tuning (high kp) will try to track the noisy rpm commands, resulting in motor and ESC heating up. there are generally two main sources of oscillations: unstable attitude controller or vibrations / noisy gyro unstable attitude controller : characterized by lower frequency oscillations (in the range of 10-30Hz, depending on your frame, motors, etc) vibrations can result from drone frame twisting at the frequency of motor RPM, or loose flight controller board / IMU, if flight board is shock mounted, the connected wires can potentially carry vibrations or cause the board to flex due to the wires vibrating / moving (very quickly). These vibrations will be at the frequency of motor RPM. aggressive (high) values of ESC kp will amplify these vibrations, so you can end up in a situation when the ESC's closed loop RPM controller is feeding back and contributing to higher oscillations. by analyzing the gyro logs (will need to enable high rate logging), using FFT you can determine if your frame is mechanically unstable / noisy or the attitude controller is unstable. if you set kp and ki to 0, you still have the advantage of calibrated (and voltage-compensated) RPM control. However, the control will only have feed-forward term. So behavior will be close to response of a traditional ESC with added calibrated feed-forward rpm control with voltage compensation. regarding whether you need a bigger ESC.. it depends on the maximum total current that you plan to pull. The M0138 ESC has been tested with similar motor / prop combo (3110 motor, 900kV with a 10x4.5 tri-blade) . During bench testing, each motor could pull close to 40A at 6S, however in practice you are never going to have all 4 motors spinning at absolute maximum rpm (then you will not have any control margin for attitude). We have tested full punch-out flights for 100+ Amps for over a minute and the ESC was perfectly fine (airflow required for cooling). The mosfets on M0138 are rated for 100A+ continuous (each), so 40A continuous an issue. It will come down to the total current draw and cooling. For high power applications like this, you should definitely start at lighter loads and try to push the ESC to the limit. You will also need to worry about power connector(s) if you are drawing 100A+ continuously (battery connector may melt). px4 params: the min and max rpm params in px4 should match the min and max in your esc params. the px4 params do not override the limits in the esc params - the ESC will cap the incoming rpm commands if they are outside of the ESC params limits. Also, if you have incorrect px4 rpm limits, the thrust calculation in px4 will be incorrectly scaled from 0 to 100%, so you definitely want to get those rpm limits to be in sync between the ESC and px4.

Also, you can use our custom version of flight-review to display additional data specific to our ESC (rpm commands, actual rpms, esc temps, etc) : https://github.com/modalai/px4-flight-review (you can run it locally in docker).

Alex

Hi @SKA ,

Can you please clarify a few things:

using latest SDK, does rtsp streaming work, if you do NOT specify 0ms cache? what player are you using for receiving the video? have you tried ffmpeg (if so, what is the full command?) are you sure that you are actually have the hires_misp_color stream available from the camera server? you can check it using either voxl-portal or using voxl-inspect-cam hires_misp_color.

Alex

@Alex-Kushleyev how do I go about buying replacement parts for the Stinger and the additional boards and cables to add the Hadron 640r?

@bendraper Edit /etc/modalai/voxl-vision-hub.conf and set "offboard_mode": "off"

@cbay ,

As long as the Boson / Boson+ 640 (or 320) supports MIPI output, it should work. We believe that some Boson models do NOT have MIPI support (HW limitation) but all Boson+ do have MIPI support. Please check with your vendor to make sure MIPI output is supported.

Also, did you actually mean M0187, or something else? M0187 is an adapter for a Flir Lepton : https://docs.modalai.com/M0187/

Alex

Update:

I did some further testing and noticed a somewhat inconsistent but repeatable pattern related to SKU reconfiguration and power cycles.
After reconfiguring the SKU (MRB-D0014-4-V1-C27-T0-M22-X0) and then power cycling the VOXL2, the SoftAP network is broadcast as expected. After a second power cycle, the network is still being broadcast. However, after a third power cycle, the network disappears again and is only restored after reconfiguring the SKU once more.
In addition to that, client connectivity is inconsistent. In some cases I’m able to connect to the WiFi network from my PC without issues, while in other cases the connection attempt starts but eventually fails.

@YUUJI-INOUE ,

Yes the square glass piece is the IR cut filter. It should be glued to the lens assembly in the for corners of the square. You could remove it yourself, at your own risk. Please see a similar discussion and results in the following thread : https://forum.modalai.com/topic/4826/msu-m0149-1-ir-filter (this that case, the lens is slightly different and it was much more difficult to remove the IR filter). In your case, the filter may pop out without breaking, but it is likely to break. You may want to put some tape on the filter before removing it, which would help avoid having loose pieces of glass.

Alex

@john_t , you can use two AR0144 modules (M0166) in a stereo configuration. When connected to VOXL2 using M0173, the two cameras will be synchronized (start of exposure).

Even though we are not actively using dual AR0144 for DFS, we have tested and it works with voxl-dfs-server with some tweaks.

If there is interested in this, we can document how to set it up (using voxl-dfs-server.)

Would you be using your own DFS processing?

Alex