ModalAI Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. ben grocholsky
    • Profile
    • Following 0
    • Followers 0
    • Topics 0
    • Posts 15
    • Best 0
    • Controversial 0
    • Groups 0

    ben grocholsky

    @ben grocholsky

    0
    Reputation
    6
    Profile views
    15
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    ben grocholsky Unfollow Follow

    Latest posts made by ben grocholsky

    • RE: px4 service issue

      @tom that was from ubuntu 20.04. Looking back up the terminal history I see the install script stopped at:
      [ERROR] missing /data/modalai/sku.txt
      [ERROR] please run voxl-configure-sku to make a new one
      and didn't run the next setup steps. I didn't realize the flashing failed until seeing voxl-px4 couldn't start. And digging into that found this thread.

      posted in VOXL SDK
      ben grocholskyB
      ben grocholsky
    • RE: px4 service issue

      @Eric-Katzfey I saw a similar symptom last Friday on a voxl2 that seemed to have a corrupt partition for /dev/sda8.
      Flashing to 1.3.5 wrote /data to / without sda8 mounted.
      voxl-px4 failed depending on sscrpcd.service which failed depending on data.mount

      voxl2:/$ mount /dev/disk/by-partlabel/userdata /data
      mount: /data: wrong fs type, bad option, bad superblock on /dev/sda8, missing codepage or helper program, or other error.

      voxl2:/$ fsck.ext4 /dev/sda8
      e2fsck 1.44.3 (10-July-2018)
      ext2fs_open2: Bad magic number in super-block
      fsck.ext4: Superblock invalid, trying backup blocks...
      fsck.ext4: Bad magic number in super-block while trying to open /dev/sda8

      voxl2:/$ fdisk -l |grep sda8
      The backup GPT table is corrupt, but the primary appears OK, so that will be used.
      /dev/sda8 41480 16818695 16777216 64G unknown

      Reflashing with ./install.sh --wipe-persistent fixed sda8 and made everything work.

      @giladWDS could be worth checking /dev/sda8 is being mounted as /data without any errors.

      posted in VOXL SDK
      ben grocholskyB
      ben grocholsky
    • RE: gps_dump not recorded in .ulg, even when GPS_DUMP_COMM set

      @Eric-Katzfey I've seen this gps_dump uorb not get recored because the default is to request optional logging. https://github.com/modalai/px4-firmware/blob/8d26285b2362354092aca88716c70d48a3c62ea2/src/modules/logger/logged_topics.cpp#L73
      change to add_topic fixes that.

      @groupo if you want to do something like PPK processing on raw GPS phase data then you need to change the GPS driver submodule. Upstream default explicitly disables msgs such as UBX_RXM_RAWX. I don't know why. Would be useful functionality to have the dump param turn on raw data for devices that support it.

      Only other useful data without code change is satellite_info that will give carrier to noise ratio to diagnose GPS issues. But it's only published if GPS_SAT_INFO is set to 1 and recorded if bit 5 of SDLOG_PROFILE is high.

      posted in Ask your questions right here!
      ben grocholskyB
      ben grocholsky
    • RE: GPS never published

      @groupo From the description it's hard to tell if the GPS stopped communicating or stopped getting a usable solution. L1 GPS is very easily degraded by RF interference from high speed signals on wires or communications devices. Look at the jamming_indicator field in the sensor_gps uorb to get a better sense of if you have a RF interference issue. Value much above 40 indicate too much interference. Grounding and shielding the wires from the voxl2 to the GPS can improve this.

      There is a bit more confusion in that px4 health checks by default need > 7 satellites in use to say system has GPS (==> GPS working but not good enough), or EKF2 can reject good GPS and report no global position in situations where vibration or magnetic interference is the underlying problem.

      I'd recommend sharing more details from the sensor_gps output or a ulg file so folk can help further.

      posted in Ask your questions right here!
      ben grocholskyB
      ben grocholsky
    • RE: VOXL2 detected landing at ~27m altitude and cut motors

      @restore Unfortunately that looks to be a PX4 issue unrelated to VOXL2. Your vehicle is lightly loaded hovering below 20% throttle. The combination of low throttle and relatively high vertical acceleration vibration while descending in altitude mode triggered a false landing detection.

      posted in Ask your questions right here!
      ben grocholskyB
      ben grocholsky
    • RE: Voxl2 Spektrum Receiver error

      @Eric-Katzfey https://github.com/modalai/px4-firmware/pull/42

      posted in VOXL 2
      ben grocholskyB
      ben grocholsky
    • RE: Voxl2 Spektrum Receiver error

      @Eric-Katzfey the test deb file was just voxl-dev branch with the one line change to accept (0x02|0x01) protocol bytes with the error output shortened below 80 characters + debug print bools and macros in DSM parsing forced on. I can fly that one line change on a Sentinel to look for any unexpected consequences. It'd be great to coordinate on how to get such a change merged into the dev branch and a non-debug deb to Chase.

      posted in VOXL 2
      ben grocholskyB
      ben grocholsky
    • RE: Voxl2 Spektrum Receiver error

      @Chase-Riley I didn't realize that had changed in V1.0. If you have access to a an alternative px4 fmu you could use the QGC pairing function to change the spektrum mode connected to that fmu and then plug it back into the voxl2. That could help check if one of the three options is more reliable. I'm not sure why you saw different data packets on a restart. Need to resolve that or try a different transmitter.

      posted in VOXL 2
      ben grocholskyB
      ben grocholsky
    • RE: Voxl2 Spektrum Receiver error

      @Chase-Riley In the first of these two runs you were getting 0x01 protocol byte like I see on my DX7 transmitter. In that state with this binary you should see rc_input uorb messages and be able to try the Radio Calibration tool tab on QGroundControl.

      In the second run you're seeing 0x00 protocol byte and unfortunately I'm not sure what that means.

      If you can get the first case working repeatedly using one of the voxl-bind-spektrum options -t -f -s then we're on the path to a fix. Which did you use and have you tried them all?

      posted in VOXL 2
      ben grocholskyB
      ben grocholsky
    • RE: VOXL MPA_to_ROS rostopics not subscribing to anything

      @Darshit-Desai the recommendation to learn about tf, urdf, and xacro in ROS was because that's a way to achieve what you're asking for. If you get the launch and config files right then ROS tools such as rviz will do what ever you want without writing any code.

      posted in Starling & Starling 2
      ben grocholskyB
      ben grocholsky