Topics created by Matthew Wellner

@Alex-Kushleyev Thanks again for the help. Unfortunately as it turns out, even though I have a Boson 640+ FLIR told me that the version I have is right before they started providing the MIPI output. I can still use the UVC interface, but it doesn't look like the Boson+ that I have can use the MIPI adapter after all. I don't know that many others will have my problem, but you guys might want to note that only the newest version of the Boson camera will support the MIPI adapter kit (https://flir.custhelp.com/app/answers/detail/a_id/6245/~/flir-oem---boson-software-versions).

Matt

I grabbed the /usr/bin/quectel-CM from another VOXL2 on an older SDK (1.4.1) and swapped out the one that came with 1.5.0 and everything is working again...

@Matthew-Wellner , I am glad you got it working! When you used M0076 single camera interposer connected to VOXL2 J7, actually you were connecting to the "lower" camera slot, so that would be J7L, meaning slot ID 2, not 3. That is why your camera was not detected in that case.

Regarding your M0084 not working, it could be a hardware issue in the flex cable or it's connectors. In order to figure this out, some more testing would be needed. Also, typically we suggest avoiding daisy chaining flex cables, so M0076 / M0135 allows you to do just that. It is possible that a combination of M0084 and another extension cable create sufficient signal distortion of the MIPI lines to cause CRC errors.

Alex

Hi @Matthew-Wellner
Yes, we sell some modem products as "stand-alone" which can be connected to any USB host.
We have not offered our popular M0090 5G modem in that mode, but we have offered it for the older Microhard and Sierra 4G modules, but right now we only offer it on Microhard:
https://www.modalai.com/collections/modems/products/mdk-m0048-2

@Moderator thanks for letting me know. I have a here 2 laying around. I'll just use that instead.

No @Matthew-Wellner , Our shipping dept is already done for the day and we missed UPS/FedEx drop-off times for next day delivery.

I can't offer anything other than consolation that we've had some of our customers be amenable to a demo with non-NDAA compliant stuff with our assurance we have a plan to switch over (especially yours since it is available and in-hand, but just not working at the moment).

I only wish I could probe your board remotely to help you figure this out... sorry.

@Matthew-Wellner , As we discussed offline, I am going to post the summary for the likely issue here:

By setting "demag_timing: 1" in esc params, it enabled some experimental feature, which fails to work correctly above certain rpm. It prevents motor from spinning faster when more power is applied (above a certain rpm). You can see from plots above, the desired command for motor 4 (purple) goes higher, but actual rpm is flat lined around 5700rpm (black). Also the current jumps up significantly for motor 4 (black) when it hits that ceiling.

For your motor, please disable this "feature" by setting demag_timing to 0. Depending on your current timing advance, we may keep that the same or increase slightly.

After disabling demag_timing-> 0, i would recommend performing rpm step tests to make sure the de-syncs still do not happen.

I am sorry about this, I will update documentation to not recommend using this feature.

9ac17b56-3431-408e-bd34-a7006eeb55ef-image.png

zoomed in
c12f7747-3523-416b-8467-f462ee7b7561-image.png

Alex

@Alex-Kushleyev That fixed it for me. Thanks again for the help!

@Matthew-Wellner,

The ESC params should have min_rpm parameter set to the minimum RPM that you obtained during your tests, specifically the RPM that motor spins when you send ./voxl-esc-spin.py --power 10 command, as 10% power is pretty much the minimum you would want to use on the ESC itself.

Then you make sure your PX4 params also use this value for min_rpm for the following param: VOXL_ESC_RPM_MIN , however you also want to make sure the max_rpm ESC param corresponds to VOXL_ESC_RPM_MAX in PX4 params, otherwise the rpm range will not work correctly in PX4.

You should also do some sanity checking. Knowing your propeller's thrust vs rpm curve helps a lot. Then you can check the commanded / actual motor RPMs versus your vehicles weight. It is possible to build a very lightweight vehicle, such that even small amount of thrust % would result in above hover thrust. You typically want to avoid those situations because it would be hard to achieve stable flight.

Finally, you should check your px4 log, you could load it here to generate plots, including actuator commands and reported RPMS and you can check if those RPMs make sense. https://review.px4.io/ . Please take note that this is a public site.

@Alex-Kushleyev I had a similar issue and this helped a lot. thanks.

@Alex-Kushleyev Awesome!! Thanks!