@Eric-Katzfey appreciate the help. related questions.

when starting up the voxl-remote-id service, noticing that hostapd was not connecting. identified that it was inactive, so started it, with no luck. for reference, using the m0213 botsunlimited sparrow.

traced the following:

In the hostapd.conf file, it operates at 5Ghz (hw_mode=a) and at channel 149. is this expected? Should remote-id operate at 2.4Ghz (hw_mode=g, channel=6)? noticed there is nothing telling hostapd to create a socket directory, added ctrl_interface=/data/misc/wifi/hostapd

Added those changes, and now remote-id successfully connects to hostapd, mavlink-server, and can enter active mode

However, that identified some other items during troubleshooting:

when attempting to register drone with FAA - receive invalid serial number - is there specific format that you register drones with faa? /persist partition on /dev/sda2 has a bad superblock or wrong filesystem type - it fails each time - without persist, RTC doesn't save and resets every reboot - is that expected behavior? wifi does not reinitialize on soft reboot - requires a full power cycle

Hi @qubotics-admin , a few comments:

you don't need to re-calibrate per motor -- one time calibration for the motor / propeller time is sufficient make sure to update the correct kV value in the spinup params. although it probably is not the issue here since your motor is 2300kV and the params you started with are for 2400kv, but it's good to make it right. This param affect the spinup procedure.

Questions:

the the motor connected to ID2 spin at all during the initial spin-up procedure? are you able to share a video? if you extend the spinup from 0.5s to 1.0 second, does the same issue persist? if you increase the spinup power a bit (i think it may be set to 100 right now (10%), make it 120 and test again? If the current spinup power is not 100 -- whatever it is now, increase by 20% for a test and see if that helps (change it back after the test if there is no improvement). note that if the motor does spin up, it is important to note the rpm at a specific commanded power and compare that rpm to other motors. Sometimes it is possible for a motor to spin even with a partially shorted windings or an issue in the ESC, but it would spin slower than normal, especially under load (with propeller attached). i know you said that swapping the motor did not help, but it would be good to test the motor that is not spinning now on ID2 by switching this motor to another ESC ID and making sure it spins ok.

Also,

please make sure that the windings of the motor are not damaged by the motor mounting screws. this is a common issue when the motor mounting screws are too long and they penetrate into the windings, creating a partial short if you have a milliohm meter, the winding resistance can be verified (it should be the same for any pairwise test of any phases for all motors of the same type -- within a few percent) inspect the ESC for any debris or any other objects touching the ESC board

Alex

@jon And you can find a lot of detailed information about the agent, including the start options, here: https://docs.px4.io/main/en/middleware/uxrce_dds

@RoyAzriel ,

you can back up your voxl-camera-server.conf and then run voxl-configure-cameras 29 and the following will happen:

all the existing sensormodule files will be wiped from /usr/lib/camera to avoid confusion only those sensormodules that belong in C29 config will be copied from /usr/share/modalai/chi-cdk to /usr/lib/camera the camera server config file (/etc/modalai/voxl-camera-server.conf) will be overwritten with the defaults for C29 configuration -- you can then see the config entry for TOF sensor and copy/paste that into your old config file, if you wish or use the new config file as is.

Alex

@Eyal , sorry for the delay. Here is some additional information regarding Stinger FPV:

https://docs.modalai.com/stinger-vision-datasheet/ base weight with battery : ~570g maximum thrust per motor : 650g @ 15V, 2600g total theoretical theoretical max thrust to weight ratio: 4.5:1, lots of extra margin, but if you add a LOT of weight, will need to check motor temps, etc. CAD model for stinger (may be slightly outdated) : https://forum.modalai.com/topic/5180/looking-stinger-fpv-cad-models -- you can attach your payload to carbon fiber I think that Stinger will be easier to tune up with additional payload because of more responsive and powerful propulsion system than Starling 2. i dont know what your sensor package is so, it is hard to comment about which platform is better. Starling 2 has landing gear that offsets it from the floor. Stringer is much lower to the ground.

Alex

@Alex-Kushleyev Thank you that fixed it for J6. Is there a reason the same config doesn't work on J7? Ideally was hoping to use J7 since it works better for our layout purposes.

I can get J6U-ar0144 and J6L-imx412 to work but not J7U-ar0144 and J7L-imx412 or J7U-imx412 and J7L-ar0144. For both it cannot find the lower sensor.

Also is there a reason the imx412 driver does not exist for J6 upper?

@Eric-Katzfey I’m looking for the voxl-emulator Docker image referenced in the documentation:

VOXL Emulator Documentation: https://docs.modalai.com/voxl-emulator/#install-the-voxl-emulator-docker-image

However, in the Development Sources / Developer Portal there doesn’t seem to be any Docker image available for voxl-emulator.

Could you please confirm if the image is still available, or if there is an updated download location for it?

Thanks @Eric-Katzfey ! Here is the pinout for the dev board "UART" port that includes i2C_SCL and I2C_SDA.

0cda71eb-2c0f-4b1b-ba91-8b3862fc9763-image.png

The dev board pins 1-6 matching to J19 pins 1-6

We will give the COMPASS_DISBLMSK parameter a shot and see if that works.

Hi @bschulzhf ,

voxl-inspect-cam -a command should not be generally used as it puts a lot of stress on the system. just use it to inspect the stream that you need, such as voxl-inspect-cam hires_down_large_color.

Also, in your camera config changes, it is not clear exactly what changes you actually made, since you did not provide a diff (but i can see that you probably disabled all the streams except for the preview stream). In any case, you should revert your changes and just inspect the stream you need to estimate the latency.

If you want to provide more information about your application, we can suggest appropriate camera server parameter changes. I do see that ae_desired_msv": 60 is potentially too dark (the target average pixel value for auto exposure control) - you can try increasing it and see if the image is too dark.

Alex

@Michael-Hatton When you arm the drone it is in flight mode and the motors start to spin. It's that spinning of the motors that you don't want while plugged into a power supply. Only use your battery to actually spin the motors and fly.

@Jskim This is the repo we use for support of UVC cameras: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-uvc-server. I don't think it will work directly with Seek cameras but you can try. In my experience each new camera requires a bit of integration work and updates to that code.

@bschulzhf Take a look at the voxl-vision-hub code. Specifically the vio manager: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-vision-hub/-/blob/dev/src/vio_manager.c?ref_type=heads

@mkriesel It's possible the kernel you're flashing is incorrect. Can you provide the full terminal output of the install?

Hi Cbay,
There is a small clock buffer on the edge of the PCB. An RMA can only replace the whole board, not replace a single device. The part to check would be here: image (1).png

@chinlee5 Which drone do you have? Which versions of software are you using? Are those messages appearing on QGC? Also, do not try to arm the drone or fly the drone while attached to a power supply. Only use a battery for that. If you take the drone outside with a full view to the sky so that GPS can acquire satellites do the messages go away?

Hi Kim,

There are a couple changes required here that will make this work:

1. Rebuilding Kernel with SPI14 enabled
You're going to have to rebuild and flash the kernel with QUP14 enabled as SPI. There is also a directional level shifter on GPIO67 that needs to be set to high in order for SPI on QUP 14 to work. I created this branch for you that should have the kernel changes that you need:

feature/voxl2-mini-spi-qup14 (link)

In order to actually build and flash the kernel please follow the instructions from our public docs on how to build the kernel

https://docs.modalai.com/voxl2-kernel-build-guide/

When building the kernel, after syncing but before building, make sure to go to the cloned meta-voxl2-bsp directory and checkout the branch that I created (feature/voxl2-mini-spi-qup14).

Also there is a chance you may need to build a kernel variant depending on your device so also make sure to check this document to see if you have a -2 device which would require building the kernel with the -v var02 flag

https://docs.modalai.com/m0054-versions/#m0054-1-and-m0054-2

2. Configuring Trustzone with Correct QUP
I would recommend using the devcfg binary that comes from the `voxl2-mini_SDK_1.0.0.tar.gz. In order to flash devcfg you'll want to run the following command

fastboot flash devcfg <path/to/voxl2-mini_SDK_1.0.0/devcfg>/devcfg.mbn

You should flash the kernel and devcfg (Trustzone) during the same fastboot session to avoid running into any issues with the device booting.

Let me know if you have any additional questions or run into any issues!

@Matt69 , Do you need the additional PWM outputs to be connected via PX4? If not, perhaps connecting M0065 to a cpu uart and communicating directly would be the simplest (i can help you with that).

Do you have spare SLPI UARTs?

Not sure if PX4 would support multiple voxl2-io drivers running, i guess that should work? I don't think we have tried it. if you have spare slpi uart ports, just give it a shot? There may be a problem with two actuator drivers having the same name.

Alex

Hi @mtcbj
That is the flex stiffener. Our older image modules used stainless steel. Some of our newer modules use laminate.
Those holes are likely just flex/FPC air escapes during the backer lamination process. They do not provide any functional purpose after assembly.
I see no issue filling them with epoxy.
Hope that helps!

@Plingaas02 Regarding odometry in voxl-mavlink-server, it will not modify timestamps on this message. There will be, potentially, VIO odometry messages going to the flight controller from voxl-vision-hub via voxl-mavlink-server and flight controller odometry messages being routed out to the GCS and to the onboard stream. The odometry messages coming from PX4 will have the DSP monotonic timestamp which is different than the Linux monotonic clock and these will drift with respect to each other over time. PX4 runs the timesync service so it can correct the incoming messages from VIO.

@james-emi ,

In our voxl-camera-server, we have a default intrinsics config for the IMX412 camera / lens as follows (focal length approximation is based on a several calibrations). Basically it is a fisheye lens with about 2000px focal length at full resolution (half of that at half resolution, etc). The camera full sensor width is 4056 (hence the x principal point is exactly half of that 2028). In some cases we use slightly trimmed frame (4040 in width). But in any case, that should be enough for a good starting point.

lens_cal.width = 4040; lens_cal.height = 3040; lens_cal.fx = 1999.0; lens_cal.fy = 1999.0; lens_cal.cx = 2028.0; lens_cal.cy = 1520.0; lens_cal.is_fisheye = 1;

Alex