Hello @SKA,

Thank you for the details. I can't think of anything right now, but will double check this.

I know that there is one potential issue in voxl-camera-server - the SPS header (which is part of the H264 / H265 stream) is only sent by the video encoder once (at the beginning of the stream). I believe that voxl-streamer will cache the SPS packet (which contains things like resolution, etc) and i think when clients connect to voxl-streamer, then it will send that SPS header to the clients. However, if voxl-streamer does not get that first header, it will not be able to forward it to the clients. This is a guess for now, but could be related to the issue that you are seeing.

I can look into this issue. Can you please let me know how exactly to set up VLC for 0ms cache? I want to make sure that my test is the same. Also, which version of VLC are you using?

Also, i noticed one thing - you are using hires_misp_color stream from camera server, which is not actually encoded, but YUV. Then voxl-streamer will take those YUVs and encode them (using hardware encoder). Is there a reason why you are not using the hires_misp_encoded stream to get H264 directly from camera server and serve it using voxl-streamer without re-encoding? I wonder if in the old SDK you were using _color or _encoded stream?

Alex

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

@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"

@Piyush-Singh, please double check that you have the imx214 sensormodule bin for slot 0 in /usr/lib/camera/ (since you have M0084 connected to J6 and the IMX214 camera connected to the "lower" port (JL) of M0084, so the resulting connection of the IMX214 camera will be mapped to VOXL2's J6L (slot 0)).

You can find all the sensormodule files in /usr/share/modalai/chi-cdk/

Alex

Hi @JoonaR,

Yes, the Starling 2 drones are shipped with the lepton adapter (M0187), but Lepton sensor itself is not included.

https://docs.modalai.com/M0187/

Alex

0cb77fc6-242f-4477-a15d-3c89f43d8f69-image.png

Hello @Sarika-Sharma ,

Do you have all these cameras already and are asking how to connect them, or are you looking to purchase them?

If you do have the M0169, can you please post the picture of the TOF module and attached adapters that came with it? I just want to make sure I know exactly what you have, since there are several adapter options.

Also, are you open to any updates to the camera selection, as I can make suggestions to use better cameras (both tracking cameras and hires cameras).

Alex

@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