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

@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

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 @SDSU_Drones
You bet.... emailing you now!
Thanks!
Vinny

@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

Hello @MattB69 ,

Sorry I made a mistake regarding the current rating of the step-up regulator. the 80mA number was for a very low input voltage (to the step-up regulator). with 3.3V intput to the step-up regulator, M0065 can support up to 350mA of output current at 5V, but we still do not recommend using it for powering servos.

So this means that our documentation for D0015 flight configuration is in conflict with documentation for M0065 board (which says use 5.0V for reference only).

Even though we have tested it in the D0015 configuration with "some" servos (i am not sure which ones were used), we still do not recommend powering servos using 5V from M0065. We will update the D0015 documentation.. Thanks for pointing it out!

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

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

Hi @wetherbeej
We still never actively pursued support due to lack of demand.
Additionally, one of our other customers that is very savvy with QC chips tried for a few months and then gave up... seems this may be a fundamental QC QRB5165 issue that we may not be able to solve or even push for resolution either. It would not be the first SoC feature that was promised but then never supported. I think the lack of UFS cards in the market is a key indicator this product segment is going to eventually be left to dry.
Sorry I do not have better news for you.

As we push towards a later Ubuntu release, we can try again, but those efforts have been slow going and tedious.

Our other customer went towards a SSD over PCIe using J5 PCIe interface. That seems to be also where the market is heading... PCIe and USB-C based SSD's, but predominantly USB-C.

@MattB69 ,

The 5V output on M0065 (10-pin connector with pwm outputs) should not be used to power any servos. The 5V signal is generated from 3.3V (coming from VOXL2) using a step-up converter, only capable of 80mA output).

https://docs.modalai.com/voxl2-io-datasheet/

the 3.3V (which is coming from VOXL2), also should not be used to power servos, as that would be risking bringing down a major power rail on VOXL2.

Alex