Topics created by Jeremy Frederick

@Jeremy-Frederick Okay, well then you will need to add support for such an external Mavlink enabled peripheral into voxl-mavlink-server. We don't currently support that.

@Jeremy-Frederick , the FPV ESC currently supports two pwm outputs, it can be tested using the following test script:

https://docs.modalai.com/voxl-fpv-esc-datasheet/#pwm-inputs--outputs (docs) https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/voxl-esc-pwm.py (test script) make sure ESC firmware is 39.18 or later, as specified in documentation

The python script tells you which ESC boards support pwm output:

# PWM support on ModalAi ESCs: # M0049, M0117, M0134, M0129 : IDs 0, 1, 2, 3 # M0138: IDs 0, 3 only # All boards use pin A2 for PWM output

by changing the --id argument between 0 and 3 you should be able to use this test script to control PWM outputs of the two test points of M0138 ESC . Please be careful soldering to the test points as they are small and avoid pulling on the wires (use strain relief).

We are also working on enabling a 3rd pwm output on the output that is currently used for the Neopixel LED (this output is also pwm capable).

In terms of integration, standalone testing can be done using this python script, but sending pwm commands have to go through PX4, and we are working on integration.

You can use the following tool which will send a message to PX4, which will get forwarded to the ESC:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/sdk-1.3.4/tools/voxl-send-esc-pwm-cmd.c . Note that this tool has been moved to another repo after sdk 1.3.4 , but you should be able to use this tool to control pwm from voxl2 command line while the px4 is running and talking to the ESC.

The new repo for the tools is here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-io-server/-/tree/dev/tools and I believe it should be doing the same thing, although i have not personally confirmed it yet.

Try it out!

Long term, we do plan to provide the support for this (this is not a temporary feature), so we are working on cleaning up the tools for that.

Alex

@Jeremy-Frederick Those aux channels are implemented differently when getting manual control messages from QGC. The only one that is mapped is aux1 that comes from the "buttons" field of the corresponding MANUAL CONTROL Mavlink message.

Absolutely! @Jeremy-Frederick
That is why we keep the 6A part to match our Power Module capabilities from M0041.
We need 6A to deal with inrush power-on for our VOXL 2, but then after that, we usually only pull 6-8W MAX in the most extreme use cases, so you have over 20W of "free" power to use on accessories.
Hope this helps minimize your system eBOM!
Let us know if you have any other questions.

I'll put a question here since it's open-vins documentation related. I also am successfully running nightly builds of open-vins, and it is working well for me.

I would like to add image masks to the tracking cameras to block out certain areas. I see the option "use_mask" in voxl-open-vins-server.conf, which I can set to true. I can't figure out where to put the mask files, or how to specify their path and file name?

If this should be a separate thread, please let me know and I can move my question elsewhere, cheers!

I was able to replicate your issue and also confirmed that the issue goes away if I move the AR0144 camera from the M0084 cable (connected to J7L) to J6L using M0076 interposer.

I believe the issue is related to potentially insufficient decoupling capacitance in the IMX214 camera, so running it on the same flex with another camera causes noisy pixels.

I hope you can work around the issue by moving the AR0144 camera to another port.

Sorry about that!

Alex

Hi @Jeremy-Frederick
Can you please provide some pictures?
It almost sounds as if you have a faulty RJ45 jack, but these are tested in factory before shipping.
If you can get some close ups of the non-working RJ45 and the LAN7500 chip, that may help.

And, can you clarify that you have Qty-2 M0062's and one works, yet one doesn't? Did the faulty one ever work for you? Was the faulty one in any type of handling mishap (like an accidental drop/fall)?
The RJ45 has integrated magnetics to save space (which is why it is so tall), but that makes them more vulnerable to shock failure than typical RJ45's.

One thing I do know that may also occur is the jack can be installed slightly tilted, making it hard to seat the RJ45 cable in firmly. There is an odd feature on the connector that sometimes allows it to seat at an off-angle, slightly pointing down making the cable slightly interfere with the PCB (but still ok to insert, since as I mentioned, we tested at the factory). Also, the metal along the sides of the RJ5 may also be stiff, preventing a smooth insertion, so sometimes just inserting the RJ45 cable a few times making sure you get that nice tactile "click" may be what is needed to ensure the contacts are engaged and kinda "breaking in" the stiff connector.

Hi @Jeremy-Frederick
This appears to be a fusing open of some (one or more) power signals on the flex, indicating that excessive current was demanded of the flex. A short at the image sensor module of a power rail could cause this, so a loose connector may have certainly been your culprit, and a voltage likely contacted a GND signal or component.

@Jeremy-Frederick, that is great!

Luckily (or by design 🙂 ) the camera connector reversal is typically not fatal, but DO NOT push your luck, please 🙂 . Technically, if damage occurs due to incorrect insertion of the camera connectors, this will void the warranty for the main board.

Always verify connector orientation when changing camera configuration.

Alex

@Jeremy-Frederick , If VIO is working, then there is a very high chance that you got the orientation correct 🙂 . If the camera to IMU orientation is off by something like 90 degrees in any direction, VIO is pretty much guaranteed to fail. So if you are getting normal VIO performance, quick initialization, across multiple tests, then I would say that your orientation parameters are correct for VIO.

Please keep in mind that if you flipped the board and if you are planning to fly with PX4, you will need to change the imu rotation params in PX4 (also keep in mind that PX4 is using a different IMU that is connected to the DSP)

@Moderator Great, I noticed in SDK 1.2 there is now support for dual tracking cameras in the camera server, can both feeds be fed into the QVIO service to allow for the use of both cameras in VIO?

@Vinny Appreciate the heads up

since voxl-streamer can provide RTSP streaming from VOXL2, ffmpeg can be used on the host machine for recording outside of QGC.

You can find some helpful information by searching ffpmeg save rtsp stream to a file . for example : https://medium.com/@tom.humph/saving-rtsp-camera-streams-with-ffmpeg-baab7e80d767

@Jeremy-Frederick No, it should not ever crash in mid flight! Can you provide the console output (journalctl -b -u voxl-px4), px4 log, and dmesg output from one of these in flight crashes so we can try to figure out what is going on?

@Jeremy-Frederick Can you try to lower the bitrate or resolution to see if it's a bandwidth issue?

I understand that, in theory, the rendering software (VLC or QGC) shouldn't matter for your issue. But, it typically helps to see if there is a config that will work reliably and then push it from there.

@Eric-Katzfey This is working great, been playing around with it for the last week or so. The next thing I'll be working on will be the order in which the cameras streams are displayed to QGC. It seems right now on boot the initial stream that comes up in randomized over the various camera being fed into QGC.

@Jeremy-Frederick

I would look at this being a radio thing. I would try

get some distance between the radios. if they are too close together there might be too much noise in the system monitor the radio health when you see the cut out (should be able to see that from the menu of microhard 192.168.168.2) see if this happens if you connect over straight ethernet (use this cable: https://www.amazon.com/USB-Ethernet-Adapter-Gigabit-Switch/dp/B09GRL3VCN/ref=sr_1_2_sspa?crid=1ZBIC6DOI8DB5&keywords=ethernet+to+usb+adapter&qid=1699997723&sprefix=ehternet+to+usb%2Caps%2C124&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1). If you dont see the issue, i would look closer into how the radios are configured antennas: make sure you have the right radio antennas suggested by microhard

@Jeremy-Frederick

Or, you can add this feature in PX4. but, this would take more time to implement