@voxltester Why are you not adding -b 4?

@voxltester It's all done in the base class. See: https://github.com/modalai/px4-firmware/blob/main/platforms/common/i2c_spi_buses.cpp

@Sarika-Sharma How are you setting up your network? Are you using WiFi? Station mode or AP mode? If you are using WiFi and station mode then you want to set the primary_static_gcs_ip of each drone to the IP address of the computer that is running QGC. Since each drone will have a different IP address you don't need to specify different UDP ports.

@voxltester We have never used the device that you are connecting so I am only offering suggestions to help out. When speaking of i2c addresses it is related to the device being attached to the bus, not the bus itself. You can attach multiple i2c devices to the same i2c bus if they have different addresses. But, there are multiple i2c buses to choose from. So, address 0x66 (which is default for that device and doesn't need to be specified on the command line) is for the device and port 4 specifies which i2c bus it is connected to. Also, please look at this file: https://github.com/modalai/px4-firmware/blob/main/src/drivers/distance_sensor/lightware_laser_i2c/parameters.c. There are 2 parameters that need to be set properly for the driver to work. If the default values are not correct then you will need to set them accordingly. For SENS_EN_SF1XX it should be set to 6 for LW20/c.

Hello @Richa,

The documentation states the following: (https://docs.modalai.com/micro-coax-user-guide/)

• ModalAI uses Hirose DF56 series micro coaxial connectors for our adapters and cables

The part number for the coax mating connector is the following : DF56C-26S-0.3V(51).

If you are designing a carrier board for VOXL2, you could request some help from our engineers to help review the design before you send it for manufacturing.

I hope that helps.

Alex

Hello @HsinSWT ,

When i see results like this, i would say there is probably 90% chance that the motor is bad. Unfortunately, there is a chance that the ESC is bad as well, and there is no good way to check the ESC without a known good motor (however the ESC failure is unlikely).

As I mentioned in the previous post, if you had a milli-ohm meter, you could test the motor winding resistance to confirm whether the motor is good or bad. A tool like that measures resistance with high precision (similar to a regular Ohm meter). However, if you don't have one, it may not be worth buying it..

You will not be able to measure the winding resistance of these motors correctly with a regular Ohm meter. However, you will be able to detect a complete open circuit (which could be the case, maybe worth trying). If testing resistance using a regular Ohm meter, any two connections between the 3 motor phases will read 0 ohm (or close to that). If a wire is broken, then you can detect it.

The Starling 2 motor (3000kV) has around 0.360 - 0.370 Ohm phase-to-phase winding resistance.

In order to confirm that the ESC is working properly, you could temporarily connect one of the working motors to the ESC Channel 0 and do the same spin test (using voxl-esc tools), just to confirm that the ESC Channel 0 is working fine.

In order to fix the issue, you could order a new motor and replace it yourself (will be a lot cheaper): https://www.modalai.com/products/starling-2-replacement-parts?variant=49707605393712

You could also send the whole drone back for repair (https://www.modalai.com/rma)

Alex

@voxltester I would try qshell lightware_laser_i2c start -b 4

@YUUJI-INOUE I'm very confused by the voxl-px4.log file you attached. It is filled with a bunch of -- Reboot -- lines. Where do those lines come from? How did you generate voxl-px4.log? The only Accel #0 fail: TIMEOUT! I see is after a shutdown command has been issued to PX4. The Command failed is normal. The startup script attempts to do some auto-configuration by looking for devices that may not be attached to the drone and will produce those messages. Same with the i2c probe failed messages. The fact that you can fly in manual mode means that the IMU is fine.

@tom , what would be the right course of action here? Thanks!

Hello @Dronodev ,

The other side of the M0166 PCB has a picture of a tiny figure which shows the nominal "up" orientation. You will see the little guy in the image below (coax cables are going up):

So if you flip the camera around to point away from you, then reference frame will be (right-handed):

• X : right
• Y : down
• Z : out of the camera lens

So your first diagram (on the left) is correct.

Here is specifically what en_rotate flag in voxl-camera-server.conf does for AR0144 camera:

• it sets the camera configuration / register such that the image is read out backwards (rotated 180 degrees) from camera to VOXL2
• no rotation is done in software (voxl-camera-server)

If you enable the rotation this way, you will need to either re-do the camera calibration or rotate your intrinsics manually, which I guess is trivial.

In terms of extrinsics (in /etc/modalai/extrinsics.conf file), you will need to update the camera rotation by 180 degrees along the Z-axis, if en_rotate flag is used (assuming you had it already configured for the non-rotated configuration).

Alex