ModalAI Forum

Hello,

We have been testing the 4-in-1 mini ESC using our VOXL2. Running from testing scripts in python we are able to set the RPM to our desired quantity and measure the board current.

However, we are having trouble when using PX4. When I go into actuator test mode and request a power of 1.0 (so max in the px4 world) on the test stand, the ESC status topic returns that the ESC power is 50 which is too low to lift the drone. Modifying the ESC parameters to lift the max RPM has no effect on this behavior.

We would also like the monitor the ESC current, but the ESC status topic does not seem to have any fields for the board current and the mini does not return individual ESC current measurements. Will this be added in the full 1.0.0 release?

Thank you!

@Alex-Kushleyev

Ah, thank you. That makes sense. We are currently using 2 of the ESCs and want to record the total current. I see how we could do that now through the testing script, but I am still running into trouble. We would like to be able to monitor our usage in flight through PX4, but looking through the message definitions I don't see anything that would supply the board current And all currents are reported as 0 as I would now expect.

Has the ability to get this total board current been implemented in ModalIO?

struct esc_status_s {
	uint64_t timestamp;
	uint16_t counter;
	uint8_t esc_count;
	uint8_t esc_connectiontype;
	uint8_t esc_online_flags;
	uint8_t esc_armed_flags;
	uint8_t _padding0[2]; // required for logger
	struct esc_report_s esc[8];
}

struct esc_report_s {
	uint64_t timestamp;
	uint32_t esc_errorcount;
	int32_t esc_rpm;
	float esc_voltage;
	float esc_current;
	float esc_temperature;
	uint16_t failures;
	uint8_t esc_address;
	uint8_t esc_cmdcount;
	uint8_t esc_state;
	uint8_t actuator_function;
	int8_t esc_power;
	uint8_t _padding0[5]; // required for logger
}

We are testing the 4-in-1 esc (mini) with the VOXL2 (not mini). After connecting the J18 port to the ESC with the described pinouts we are able to spin our motors and interact with them through PX4. All metadata expected is available. The only problem is that the current measurement is always 0.

I have included some output of the voxl-esc spin command

Found voxl-esc tools bin version: 1.2
VOXL Platform: M0054
Detected VOXL2 M0054 or M0104!
Found previous connection information in .voxl_esc_cache ..
Prioritizing /dev/slpi-uart-2 @ 2000000
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_uart_bridge_slpi.so
Received standard error event 2
Sending initialization request
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000
INFO: Detected protocol: firmware
INFO: Additional Information:
INFO: ---------------------
	ID         : 0
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555304003D001F
	Firmware   : version   38, hash 83faccfa
	Bootloader : version  184, hash 10bf24c8

	ID         : 1
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555304003D001A
	Firmware   : version   38, hash 83faccfa
	Bootloader : version  184, hash 10bf24c8

	ID         : 2
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555304003D001C
	Firmware   : version   38, hash 83faccfa
	Bootloader : version  184, hash 10bf24c8

	ID         : 3
	Board      : version 40: ModalAi 4-in-1 ESC (M0129-3)
	UID        : 0x2039333557555304003D0021
	Firmware   : version   38, hash 83faccfa
	Bootloader : version  184, hash 10bf24c8

---------------------
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00)
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.2
VOXL Platform: M0054
Detected VOXL2 M0054 or M0104!
Found previous connection information in .voxl_esc_cache ..
Prioritizing /dev/slpi-uart-2 @ 2000000
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_uart_bridge_slpi.so
Received standard error event 2
Sending initialization request

Output when testing ESC 1 (which has a motor attached)

[2.665] (1) RPM: 2830, PWR: 5, VOLTAGE: 12.384V, TEMPERATURE: 37.71C, CURRENT: 0.000A
[2.676] (1) RPM: 2830, PWR: 5, VOLTAGE: 12.384V, TEMPERATURE: 37.71C, CURRENT: 0.000A
[2.684] (1) RPM: 2835, PWR: 5, VOLTAGE: 12.385V, TEMPERATURE: 37.72C, CURRENT: 0.000A
[2.695] (1) RPM: 2836, PWR: 5, VOLTAGE: 12.381V, TEMPERATURE: 37.74C, CURRENT: 0.000A
[2.707] (1) RPM: 2836, PWR: 5, VOLTAGE: 12.381V, TEMPERATURE: 37.74C, CURRENT: 0.000A
[2.714] (1) RPM: 2866, PWR: 5, VOLTAGE: 12.391V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.725] (1) RPM: 2834, PWR: 5, VOLTAGE: 12.373V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.736] (1) RPM: 2834, PWR: 5, VOLTAGE: 12.373V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.744] (1) RPM: 2834, PWR: 5, VOLTAGE: 12.376V, TEMPERATURE: 37.75C, CURRENT: 0.000A
[2.755] (1) RPM: 2831, PWR: 5, VOLTAGE: 12.378V, TEMPERATURE: 37.77C, CURRENT: 0.000A
[2.767] (1) RPM: 2831, PWR: 5, VOLTAGE: 12.378V, TEMPERATURE: 37.77C, CURRENT: 0.000A
[2.774] (1) RPM: 2826, PWR: 5, VOLTAGE: 12.369V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.786] (1) RPM: 2828, PWR: 5, VOLTAGE: 12.375V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.796] (1) RPM: 2828, PWR: 5, VOLTAGE: 12.375V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.804] (1) RPM: 2838, PWR: 5, VOLTAGE: 12.376V, TEMPERATURE: 37.76C, CURRENT: 0.000A
[2.814] (1) RPM: 2832, PWR: 5, VOLTAGE: 12.377V, TEMPERATURE: 37.77C, CURRENT: 0.000A

We only have a motor connected to ESC 1, but I do see some logging for non-zero current on ESC 3. The RPM values are obviously bunk because there is nothing attached, but I do wonder if something went wrong in the hardware for logging current with ESCs 0-2.

Logging for the test of ESC 3 (with no motor attached):

[4.930] (3) RPM: 991, PWR: 0, VOLTAGE: 12.343V, TEMPERATURE: 44.29C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.343V, BOARD_CURRENT: 0.024A
[4.935] (3) RPM: 991, PWR: 0, VOLTAGE: 12.343V, TEMPERATURE: 44.29C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.343V, BOARD_CURRENT: 0.024A
[4.951] (3) RPM: 1021, PWR: 0, VOLTAGE: 12.350V, TEMPERATURE: 44.31C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.350V, BOARD_CURRENT: 0.008A
[4.955] (3) RPM: 1021, PWR: 0, VOLTAGE: 12.350V, TEMPERATURE: 44.31C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.350V, BOARD_CURRENT: 0.008A
[4.971] (3) RPM: 1051, PWR: 0, VOLTAGE: 12.341V, TEMPERATURE: 44.32C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.341V, BOARD_CURRENT: -0.024A
[4.975] (3) RPM: 1051, PWR: 0, VOLTAGE: 12.341V, TEMPERATURE: 44.32C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.341V, BOARD_CURRENT: -0.024A
[4.991] (3) RPM: 1081, PWR: 0, VOLTAGE: 12.350V, TEMPERATURE: 44.30C, CURRENT: 0.000A, BOARD_VOLTAGE: 12.350V, BOARD_CURRENT: -0.016A

Is there a most likely reason for us to be seeing this behavior?

Hello,

We are looking to upgrade our flight controller to PX4 1.14. I know that the upcoming 1.0.0 release will use PX4 1.14. Is there a way to get access to beta versions for our testing?

Alternatively, can we build PX4 from the voxl-dev branch and run it with the SDK version 0.9.5 for our testing?

Thank you

@Eric-Katzfey Oh, ha. I could have sworn it wasn't outputting my custom module status message. Checking again I see it though. That's silly.

@Aidan-Dempster Also, if anybody is trying to get QuRT logs on a Mac, nano-dm does work. With the caveat that it must be from a remote computer over USB though.

I want to see the output of a status command running on the QuRT side of PX4. I see in the documentation a method of accessing DSP logs from a connected computer with mini-dm (https://docs.modalai.com/build-environments/#dsp-development-tools), but it would be very helpful for us to access the logs from directly on the VOXL2.

Could we run min-dm directly from the VOXL2 to see these logs instead?

@AndriiHlyvko I just flashed firmware with a custom module to my VOXL2 using the SDK-0.9 branch of the voxl-px4 repo and the specific commit from the modalai px4-firmware repo that is included with that voxl-px4 branch. As far as I can tell this px4-firmware commit is the exact one used for the 0.9.5 platform release so it should have good compatibility with that firmware if you are using it.

@Aidan-Dempster I was able to fix this particular issue by performing a factory reset.

I do have a couple questions though. The Mavlink Console still does not work with PX4 saying it is unable to start a shell. I believe this to be normal behavior since PX4 is not running on a nuttx OS in this case, but I want to make sure it's not another issue.

Also, I want to clarify on the documentation. The setup video shows configuring voxl mavlink server with the wizard answers:
Do you want to reset the config file to factory defaults? - Yes
Do you want to enable the voxl-mavlink-server service to allow communication with an external PX4 flight controller? - Yes

However, if I use this configuration QGC never connects (and I never see px4 advertising ping as a remote topic). I need to answer no to the second questions for it to connect. Is this expected behavior and the documentation is out of date? Or does this speak to a deeper issue?

@AndriiHlyvko The instructions for that are actually on the voxl-px4 repository.
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-px4/-/tree/master

This contains the wrapper that runs px4 on the VOXL2, but also the packaging and deployment scripts that make it easy to install.

@Zachary-Lowell-0 Ah, yes I see what you mean. The secondary steps of updating gazebo's plugin path and loading a world with a model that uses the sitl plugins.

Ok, well in that case my only roadblock is building PX4 on my mac which, as far as I can tell, is a PX4 problem and not a VOXL problem so thank you for your help.

Hello,

We are flashing with the firmware version 0.9.5.
Full voxl-version output here:

--------------------------------------------------------------------------------
system-image: 1.5.5-M0054-14.1a-perf
kernel:       #1 SMP PREEMPT Fri Mar 24 00:48:55 UTC 2023 4.19.125
--------------------------------------------------------------------------------
hw version:   M0054
--------------------------------------------------------------------------------
voxl-suite:   0.9.5
--------------------------------------------------------------------------------
Packages:
Repo:  http://voxl-packages.modalai.com/ ./dists/qrb5165/sdk-0.9/binary-arm64/
Last Updated: 2023-03-02 12:58:25
WARNING: repo file has changed since last update,
	packages may have originated from a different repo
List:
	libmodal-cv              0.2.3
	libmodal-exposure        0.0.7
	libmodal-journal         0.2.1
	libmodal-json            0.4.3
	libmodal-pipe            2.8.2
	libqrb5165-io            0.1.0
	libvoxl-cci-direct       0.1.5
	libvoxl-cutils           0.1.1
	mv-voxl                  0.1-r0
	qrb5165-bind             0.1-r0
	qrb5165-dfs-server       0.1.0
	qrb5165-imu-server       0.5.0
	qrb5165-slpi-test-sig    01-r0
	qrb5165-system-tweaks    0.1.5
	qrb5165-tflite           2.8.0-2
	voxl-bind                0.0.1
	voxl-camera-calibration  0.2.3
	voxl-camera-server       1.3.5
	voxl-cpu-monitor         0.3.0
	voxl-docker-support      1.2.4
	voxl-gphoto2-server      0.0.10
	voxl-jpeg-turbo          2.1.3-4
	voxl-libgphoto2          0.0.4
	voxl-libuvc              1.0.7
	voxl-logger              0.3.4
	voxl-mavlink             0.1.0
	voxl-mavlink-server      0.3.0
	voxl-modem               0.16.1
	voxl-mongoose            7.7.0-1
	voxl-mpa-to-ros          0.3.6
	voxl-mpa-tools           0.7.6
	voxl-opencv              4.5.5-1
	voxl-portal              0.5.0
	voxl-px4                 1.12.31
	voxl-px4-imu-server      0.1.2
	voxl-qvio-server         0.8.2
	voxl-remote-id           0.0.5
	voxl-streamer            0.4.1
	voxl-suite               0.9.5
	voxl-tag-detector        0.0.4
	voxl-tflite-server       0.3.1
	voxl-utils               1.2.2
	voxl-uvc-server          0.1.3
	voxl-vision-px4          1.4.0
	voxl2-system-image       1.5.5-r0
	voxl2-wlan               1.0-r0
--------------------------------------------------------------------------------

We then follow the exact process laid out in the video on this page https://docs.modalai.com/voxl2-px4-quickstart/ aside from using softap and connecting to the voxl from the computer with QGC running.

The remote computer is assigned an IP of 192.168.8.35 while the voxl is 192.168.8.1.

The issue after that is when QGC is started. Given the setup in the video I cannot get QGC to connect even setting up a manual com link directed to the voxl's ip.

If I change the voxl-configure-mavlink-server setup to answer "no" to communication with an external PX4 flight controller (which makes more sense as far as I know we are not running an external flight controller unless running on the DSP counts as external) then QGC connects automatically, and the Mavlink inspector gets data from voxl2, but nothing else works. The Mavlink console is unresponsive and every page pops up an error message saying that SYS_AUTOSTART parameter is not configured.

Parameters are missing from firmware. You may be running a version of firmware which is not fully supported or your firmware has a bug in it. Missing params: 1:SYS_AUTOSTART

The voxl-vision-px4.conf is as follows:

{
	"config_file_version":	1,
	"qgc_ip":	"192.168.8.35",
	"en_secondary_qgc":	false,
	"secondary_qgc_ip":	"192.168.1.214",
	"qgc_udp_port_number":	14550,
	"udp_mtu":	512,
	"en_localhost_mavlink_udp":	true,
	"localhost_udp_port_number":	14551,
	"vio_pipe":	"qvio",
	"en_vio":	true,
	"en_send_vio_to_qgc":	false,
	"en_reset_vio_if_initialized_inverted":	true,
	"vio_warmup_s":	3,
	"send_odom_while_failed":	false,
	"horizon_cal_tolerance":	0.5,
	"offboard_mode":	"off",
	"follow_tag_id":	0,
	"figure_eight_move_home":	true,
	"robot_radius":	0.300000011920929,
	"collision_sampling_dt":	0.1,
	"max_lookahead_distance":	1,
	"en_tag_fixed_frame":	false,
	"fixed_frame_filter_len":	5,
	"en_transform_mavlink_pos_setpoints_from_fixed_frame":	false,
	"en_voa":	true,
	"en_send_voa_to_qgc":	false,
	"voa_upper_bound_m":	-0.15000000596046448,
	"voa_lower_bound_m":	0.15000000596046448,
	"voa_memory_s":	1,
	"voa_inputs":	[{
			"enabled":	true,
			"type":	"point_cloud",
			"input_pipe":	"dfs_point_cloud",
			"frame":	"stereo_l"
		}, {
			"enabled":	true,
			"type":	"point_cloud",
			"input_pipe":	"stereo_front_pc",
			"frame":	"stereo_front_l"
		}, {
			"enabled":	true,
			"type":	"point_cloud",
			"input_pipe":	"stereo_rear_pc",
			"frame":	"stereo_rear_l"
		}, {
			"enabled":	true,
			"type":	"tof",
			"input_pipe":	"tof",
			"frame":	"tof"
		}, {
			"enabled":	true,
			"type":	"rangefinder",
			"input_pipe":	"rangefinders",
			"frame":	"body"
		}]
}

and the voxl-mavlink-server.conf (doing exactly as is done in the video) is

{
	"px4_uart_bus":	1,
	"px4_uart_baudrate":	921600,
	"udp_port_to_px4":	14556,
	"udp_port_from_px4":	14557,
	"external_fc":	true
}

changing external_fc to false makes QGC immediatly connect, but with this screen and error

Again, the only thing that works in QGC in this state is the MAVLink inspector which is getting correct data.

Is this a known issue? Has the configuration process changed since that setup video?

@Zachary-Lowell-0 Ah, good to know that it works. Thank you for checking.

I think I know which cmake flags are necessary, but in case I missed something I would appreciate if you could post a tarball.

To clarify, when you say you built hitl, the make target for that is still DONT_RUN=1 make px4_sitl_default gazebo correct?

@Eric-Katzfey Thank you. Do you know if the HITL configuration files and the voxl-px4-hitl script will be moved into voxl-dev at that point or will those files be left in the voxl-dev-1.12 branch?

@Zachary-Lowell-0 I would be very grateful for a confirmation that HITL does in fact work if set up correctly. I have installed the FTDI drivers and see the FTDI usb device in /dev/tty* so if I could run gazebo with the correct plugins and modify the model sdf to use the correct /dev/tty device I assume it would work. I have gazebo9 installed and can run it, but the problem is that I cannot compile plugins.

I am not very familiar with HITL or SITL testing and all instructions list as a step building px4-firmware with the px4_sitl gazebo target, I assume to build SITL plugins, which fails with multiple errors related to recent changes made to the compiler on macos, even in a terminal with the i386 arch. However, I am able to build and run in an ubuntu docker image.

I plan to test an image that is building now, forwarding the device to the image and running the simulator there.

Thank you for your help
Aidan

The current published px4 firmware (built from this repo on the sdk-0.9 branch) appears to be building from a px4-firmware branch similar to voxl-dev-1.12. When building custom PX4 firmware should we fork off of this branch to ensure compatibility with the voxl-suite?

We are also using HITL testing for this drone, but the branch specified by the documentation is voxl-master which appears to be updated frequently and no longer has the files required in the instructions. Again, these files can be found in the voxl-dev-1.12 branch, but this branch also has errors when attempting to build the px4_sitl gazebo target so I am not sure which branch I should be using for that build. Is there a single branch that works for both uploading the HITL configuration files and also building the simulator plugins?

Thank you!

Our situation is a bit tricky. We wish to set up a testing environment for custom avoidance and control algorithms, but do not have a computer capable of both building and running all the components listed in the HITL documentation. We can build and upload custom PX4 firmware using a remote VM, but this is not helpful for our HITL simulation.

Has anybody found dug up a way to run the simulator on an M1 mac and connect the VOXL2 for a simulation? We have previously run SITL simulations for other flight controllers on our mac hardware and had success, but I haven't been able to figure out exactly how the HITL mode on the VOXL2 connects to Gazebo so I am not sure how to go about attempting a HITL simulation.

It would not be as useful, but we were also considering attempting a fully SITL test environment. It does not appear there is any explicit support for that and did not see any way to emulate the VOXL2 in a container or to perform simulation in hardware so we are focusing on trying to get HITL to work.