Posts made by ben grocholsky

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

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

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

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

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

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

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

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

@Chase-Riley Here's a debug deb to try while you're working out building custom voxl-px4 voxl-px4_1.14.0-2.0.50_DSMDEBUG_arm64.deb
It'll print out a bunch of info if you stop the service systemctl stop voxl-px4 and run voxl-px4 manually in a shell. If the 0x01 protocol byte is the issue you're having, then this version will start publishing RC data to uorb/mavlink. Otherwise, at least you'll be able to see what the raw data packets look like.

@Eric-Katzfey changing to accept 0x01 or 0x02 in rx_buf[1] appears to make my DX7 transmitter work. input_rc -> RC_CHANNELS shows up and starts/stops when powering the transmitter on/off. Any thoughts on if this is an acceptable change?

} else if (((newbytes != DSM_FRAME_SIZE) || ((rx_buf[1] & 0x0F) != 0x02)) && (! first_correct_frame_received)) {

to

} else if (((newbytes != DSM_FRAME_SIZE) || (((rx_buf[1] & 0x0F) != 0x02) && ((rx_buf[1] & 0x0F) != 0x01))) && (! first_correct_frame_received)) {

INFO  [muorb] SLPI: Spektrum RC: Read no bytes from UART
INFO  [muorb] SLPI: Spektrum RC: Read 16 bytes from UART
INFO  [muorb] SLPI: Spektrum RC: DSM message parsed successfully
INFO  [muorb] SLPI: Spektrum RC: Publishing input_rc
INFO  [muorb] SLPI: 0xff 0x01 0x06 0x08 0x17 0x42 0x0a 0x00 0x0d 0xfd 0x00 0xa9 0x10 0xaa 0x1b 0x57
INFO  [muorb] SLPI: Spektrum RC: Read no bytes from UART
INFO  [muorb] SLPI: Spektrum RC: Read 16 bytes from UART
INFO  [muorb] SLPI: Spektrum RC: DSM message parsed successfully
INFO  [muorb] SLPI: Spektrum RC: Publishing input_rc
INFO  [muorb] SLPI: 0xff 0x01 0x06 0x08 0x17 0x42 0x0a 0x00 0x0d 0xfd 0x00 0xa9 0x10 0xaa 0x1b 0x57

@Chase-Riley if needed, I can send you a deb file that will print out lots of debugs. Not safe for flying but hopefully it could help understanding what's happening.

@Darshit-Desai this is a more generic ROS tf transform network question than anything specific to ModalAI devices. You can get any result you'd like by adding appropriate frames to map or vehicle in the tf tree. For example, since rviz is hard coded to expect z axis upwards and everything is easier with z axis down, I'll attach an ENU frame to every fixed map NED frame and vehicle carried body FRD frame. That allows for all algorithms to be implemented in NED/FRD and still use ROS visualization by selecting ENU frames as fixed and view.

Check out the tf documentation http://wiki.ros.org/tf2

The static transform publisher is a quick way to test changes. Then you'll want to explore using http://wiki.ros.org/urdf

@Eric-Katzfey I've seen a similar issue with a DX7 transmitter paired to an off the shelf Sentinel. The binding worked but no data made it through the dsm parser. In that case the packets looked like:

INFO  [muorb] SLPI: 0x1c 0x01 0x04 0xb4 0x15 0xf0 0x09 0xfe 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57
INFO  [muorb] SLPI: 0x1c 0x01 0x06 0xef 0x15 0xf0 0x0a 0x2f 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57
INFO  [muorb] SLPI: 0x1c 0x01 0x04 0xc6 0x15 0xf0 0x09 0x0f 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57
INFO  [muorb] SLPI: 0x1c 0x01 0x04 0xe3 0x15 0xf0 0x0b 0x04 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57
INFO  [muorb] SLPI: 0x1c 0x01 0x07 0x56 0x15 0xf0 0x09 0xd7 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57
INFO  [muorb] SLPI: 0x1c 0x01 0x05 0x51 0x15 0xf0 0x08 0xa7 0x0d 0xfe 0x01 0xc2 0x13 0x56 0x1b 0x57

This line of the code never sees rx_buf[1] 0x02 bit high and first_correct_frame_received never goes true.

I'm not familiar enough with DSM to recommend a safe fix. (a minor change to the line above made data flow but was not robust when power cycling the transmitter...) Just confirming I've seen some spektrum transmitter hardware not work with the voxl2 parser.

rostopic hz /tracking should subscribe to the topic and work as you expected.
e.g. for me:

I've seen two things that might be happening:

1. The voxl-camera-service has stopped running. Check with voxl-inspect-services , voxl-inspect-qvio, systemctl status voxl-camera-service.

2. Your environment variables might not be set right for ROS1 remote message transport. Setting ROS_MASTER_URI on your laptop to point to the master running on the voxl is enough to discover ROS1 topic names. Two more variables are needed to be set to get message transport working ROS_IP and ROS_HOSTNAME

Here's an example that works for me. Adjust it to match the IP addresses for your voxl2, laptop, and the ROS1 version you're running on your laptop. Select the image you want to view in the rqt_image_view GUI.

Script on voxl2: start_mpa_to_ros1.sh

#!/bin/bash
source /opt/ros/melodic/setup.bash

voxlIP=`hostname -I | awk '{print $1}'`
echo "VOXL IP is: " $voxlIP
export ROS_IP=$voxlIP
echo "ROS_IP is: " $ROS_IP
export ROS_HOSTNAME=$voxlIP
echo "ROS_HOSTNAME is: " $ROS_HOSTNAME
echo "ROS_MASTER_URI is: " $ROS_MASTER_URI

roslaunch voxl_mpa_to_ros voxl_mpa_to_ros.launch

Script on laptop: start_rqt_imageview.sh

#!/bin/bash
# change these to match the computer connecting to VOXL ROS1
MasterIP=192.168.1.100
MyIP=192.168.1.101
ROS_DIST=noetic

# set environment variables and start rqt_image_view
source /opt/ros/$ROS_DIST/setup.bash

export ROS_IP=$MyIP
export ROS_HOSTNAME=$MyIP
export ROS_MASTER_URI=http://$MasterIP:11311

rosrun rqt_image_view rqt_image_view