Posts made by Eric Katzfey

@bendraper Edit /etc/modalai/voxl-vision-hub.conf and set "offboard_mode": "off"

@voxltester Great! Glad you got it working.

@voxltester In order to execute on the DSP side you have to have qshell before the command. When you have it you get the error that command is not found. That's probably because the driver has not been built into the DSP image. It only seems to be on the apps side.

@voxltester slpi_proc = SLPI = SSC = DSP. I think the only option at this point is to attach an oscilloscope and verify the signals.

@voxltester i2cdetect is looking for i2c ports on the apps processor so it isn't useful for this where we are trying to use DSP i2c ports. It shows an error message. Can you add the -X option to see if that resolves that error condition?

@voxltester And, in general, for all software engineers out there here is a helpful tip. ModalAI is not affiliated with Anthropic in any way but I do want to highlight their Claude Code tool. It can really help you not just write code, but to understand code that is already there. So, for example, in this post there is a question about how the -b option is parsed. It's a bit complicated how all of the pieces fit together but if you were to ask Claude this question: "I'm using the device driver in the file lightware_laser_i2c.cpp. I was told that the LightwareLaser class can take the command line option -b to specify the i2c bus number using the start command. Can you show me where in the code the -b option is parsed?". Claude will then give you this answer:

The -b option is not parsed directly in this file. Looking at the code:

  At line 450, the custom option parsing only handles -R for rotation:
  while ((ch = cli.getOpt(argc, argv, "R:")) != EOF) {
      switch (ch) {
      case 'R':
          cli.rotation = (Rotation)atoi(cli.optArg());
          break;
      }
  }

  The -b option (for I2C bus number) is handled automatically by the BusCLIArguments class, which is instantiated at line 445:
  BusCLIArguments cli{true, false};

  This class is included from <px4_platform_common/i2c_spi_buses.h> (line 47). The cli.getOpt() method internally processes standard I2C/SPI options like -b (bus), -a (address), etc., before returning custom options like -R to this driver's switch statement.

  If you want to see where -b is actually parsed, you'd need to look at the BusCLIArguments class implementation in the PX4 platform common library:

  src/lib/drivers/device/posix/i2c_spi_buses.cpp
  or
  platforms/common/i2c_spi_buses.cpp

  The PRINT_MODULE_USAGE_PARAMS_I2C_SPI_DRIVER(true, false) call at line 435 documents that this driver accepts I2C options (including -b), but the actual parsing is abstracted away in the shared bus infrastructure.

@voxltester Yes, bus 4 corresponds to pins 7 and 8 on J19. I would put an oscilloscope on the data pin and see if you detect any activity when you start the driver to verify.

@voxltester I tried to explain this in one of my previous responses. Let me add more detail. lightware_laser_i2c.cpp is C++ code. The class LightwareLaser has a couple of base classes. One of them is I2CSPIDriver, so it "inherits" the functionality of that class. That class is implemented in i2c_spi_buses.cpp. It uses BusCLIArguments to parse the command line options. That's where the -b option is dealt with.

@sansoy Can you please provide some details on your setup? What hardware are you using? Which software are you using (including versions)?

@Sarika-Sharma It's in the configuration file but you'll need a more recent version of voxl-mavlink-server. I would recommend updating to SDK 1.6.2 and then grabbing voxl-mavlink-server 1.4.13 from here: http://voxl-packages.modalai.com/dists/qrb5165/sdk-1.6/binary-arm64/voxl-mavlink-server_1.4.13_arm64.deb.

@Sarika-Sharma You can specify a different port to connect to at the GCS for each drone but their own port is hard-coded to 14550. https://gitlab.com/voxl-public/voxl-sdk/services/voxl-mavlink-server/-/blob/dev/src/gcs_io.c?ref_type=heads#L979

@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.

@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.

@jmltt For reference, here is a commit that will allow our fork to build for SITL on Ubuntu 24.04: https://github.com/modalai/px4-firmware/commit/8366d2e56c171230ee31c0856cb243d46f09de31

@schew The ESC states are as follows:
0: idle / not spinning or trying to spin
1: spinning up
2,3: unused
4: very brief transition between spin-up and full back-emf sensing mode (user's commands are not yet executing)
5: back-emf sensing mode (rpm or power control based on user's command)
If there is any issue that causes ESC to think it's stalled or communication timed out, it will go through state 0 and then to 1 if non-zero commands are sent via UART.
The typical start-up sequence is basically 0->1->4->5 and should stay at 5 until you send a zero command or stop sending commands.

@YUUJI-INOUE Can you send a PX4 log? If you can arm in manual mode then the PX4 IMU is working fine. The last voxl-px4 message sequence shows the IMU start correctly. If the parameters file does not yet exist (e.g. no PX4 parameters have been updated yet) then there will be no /data/px4/param/parameters file and you will see the error message: "open '/data/px4/param/parameters' failed". That is fine and to be expected. Once you have updated some parameters (e.g. running voxl-px4-param) then that file will be created and that error message will no longer appear.