# Connecting i2c device on voxl2

Source: https://forum.modalai.com/topic/2446/connecting-i2c-device-on-voxl2
Category: VOXL 2 and VOXL 2 Mini (https://forum.modalai.com/category/26/voxl-2-and-voxl-2-mini)
Tags: voxl-2
Posted: 2023-07-19 17:54:50 UTC by Aaky
Replies: 59 · Views: 34273

## Aaky · 2023-07-19 17:54:50 UTC

Hello,
 I am using voxl2 new SDK 1.0.0. I want to understand integration of i2c device to apps-processor. I am looking to integrate PCA9685 PWM driver IC with voxl2.

I am aware of using J3 and J5 on VOXL2 to expose i2c bus for integration. But in my current architecture we need to use Microhard add-on board over B2B interface on voxl2, so how to enable i2c bus over Microhard add-on board? Is it possible?

## Reply by Eric Katzfey (ModalAI staff) · 2023-07-20 15:37:40 UTC

@Aaky Depending on what you are trying to do with the PCA9685 you could use the PX4 driver and the spare i2c port coming from the DSP on J19

## Reply by Aaky · 2023-07-20 16:29:19 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Thank you for the response Eric.
I would love to utilise I2C bus on J19 and integrate pca9685 PWM driver. I want to operate single servo motor for gripper mechanism. Is it possible with PX4 1.14? Is there PCA9685 driver on PX4 available for driving servo which can run on DSP side of PX4?
If there is support for PCA9685 can you point me to relevant code with required configuration?

## Reply by Eric Katzfey (ModalAI staff) · 2023-07-20 16:49:47 UTC (in reply to Aaky)

@Aaky The code is here: https://github.com/PX4/PX4-Autopilot/tree/main/src/drivers/pca9685_pwm_out

## Reply by Eric Katzfey (ModalAI staff) · 2023-07-20 16:50:26 UTC (in reply to Aaky)

@Aaky I have no idea what it does or if it would work for a gripper.

## Reply by Aaky · 2023-07-20 16:58:45 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Okay. In order to run this driver on J19 free I2C bus ( Since I am using GPS + MAG on one I2C bus) what would be startup command?
Rest I guess I can manage by compiling the driver on slpi side.

## Reply by Eric Katzfey (ModalAI staff) · 2023-07-20 17:07:32 UTC (in reply to Aaky)

@Aaky The extra i2c bus is bus 4. So the start command would be something like `qshell pca9685_pwm_out start -b 4`. Not sure about the other options.

## Reply by Aaky · 2023-08-04 09:25:54 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Thank you for this info. Also apology for late response. 

On a seperate note, Can I connect I2C device to [this port](https://docs.modalai.com/voxl2-linux-user-guide/#i2c-4---i2c1---camera-group-1-i2c) by using some level shifter from 1.8V to 3.3V and get any I2C device connected to apps_processor with device ID /dev/i2c-4?

## Reply by modaltb (ModalAI staff) · 2023-08-04 20:08:24 UTC (in reply to Aaky)

@Aaky yes this is something we've done, I have used the M0076 interposer board that has test points that I've soldered to, e.g.:

![86214a96-531c-4b36-bc8a-b11d3dc5cee1-image.png](https://forum.modalai.com/assets/uploads/files/1691179672241-86214a96-531c-4b36-bc8a-b11d3dc5cee1-image.png)

## Reply by Aaky · 2024-02-22 05:55:21 UTC (in reply to modaltb)

@modaltb Hi, Sorry for late response. I got some time now to put my hands on VOXL2 new SDK 1.1.2 and installing it on my hardware.

I am integrating PCA9685 over I2C bus on J19 of VOXL2 (slpi-proc QUP3). I have made all the connection and followed your instructions to get PCA9685 driver running over my custom PX4 based on voxl-dev branch with PX4 1.14. 

While I try to connect with PCA9685 I get following error as shown in logs.

```
voxl2:/$ /usr/bin/voxl-px4
[INFO] Reading from /etc/modalai/voxl-px4.conf
Found DSP signature file
[INFO] Daemon mode enabled

*************************
GPS=AUTODETECT
RC=CRSF_RAW
ESC=VOXL_ESC
POWER MANAGER=VOXLPM
DISTANCE SENSOR=NONE
OSD=DISABLE
DAEMON_MODE=ENABLE
SENSOR_CAL=ACTUAL
EXTRA STEPS:
*************************

INFO  [px4] mlockall() enabled. PX4's virtual address space is locked into RAM.
INFO  [px4] assuming working directory is rootfs, no symlinks needed.
INFO  [muorb] Got muorb init command
Sending initialization request
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
Got topic data before configuration complete
INFO  [muorb] SLPI: muorb aggregator thread running
INFO  [muorb] muorb protobuf initalize method succeeded
INFO  [muorb] SLPI: Creating pthread test_MUORB

INFO  [muorb] SLPI: Successfully created px4 task PX4_test_MUORB with tid 2097656
INFO  [muorb] succesfully did ADVERTISE_TEST_TYPE
INFO  [muorb] SLPI: Creating pthread test_MUORB

INFO  [muorb] succesfully did SUBSCRIBE_TEST_TYPE
INFO  [muorb] SLPI: Successfully created px4 task PX4_test_MUORB with tid 2097655
INFO  [muorb] succesfully did TOPIC_TEST_TYPE
INFO  [muorb] SLPI: Creating pthread test_MUORB

INFO  [muorb] SLPI: Successfully created px4 task PX4_test_MUORB with tid 2097654
INFO  [muorb] succesfully did UNSUBSCRIBE_TEST_TYPE
INFO  [muorb] SLPI: Creating pthread test_MUORB

INFO  [muorb] SLPI: Successfully created px4 task PX4_test_MUORB with tid 2097653
INFO  [muorb] muorb test passed
INFO  [muorb] SLPI: Advertising remote topic log_message

______  __   __    ___ 
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

INFO  [px4] startup script: /bin/sh /usr/bin/voxl-px4-start 0
INFO  [parameters] Starting param sync THREAD

*************************
GPS: AUTODETECT
RC: CRSF_RAW
ESC: VOXL_ESC
POWER MANAGER: VOXLPM
DISTANCE SENSOR: NONE
OSD: DISABLE
EXTRA STEPS:
	
*************************

Running on M0054
INFO  [muorb] SLPI: Starting param sync THREAD
INFO  [muorb] SLPI: before starting the qshell_entry task
INFO  [muorb] SLPI: Creating pthread qshell

INFO  [muorb] SLPI: qshell entry.....
INFO  [muorb] SLPI: Successfully created px4 task PX4_qshell with tid 2097652
INFO  [muorb] SLPI: Init app map initialized
INFO  [muorb] SLPI: after starting the qshell_entry task
INFO  [param] selected parameter default file /data/px4/param/parameters
INFO  [muorb] SLPI: Marking DeviceNode(parameter_client_reset_request) as advertised in process_remote_topic
INFO  [uORB] Marking DeviceNode(parameter_client_reset_response) as advertised in process_remote_topic
INFO  [muorb] SLPI: Advertising remote topic parameter_update
INFO  [muorb] SLPI: Marking DeviceNode(parameter_client_set_value_request) as advertised in process_remote_to
INFO  [uORB] Marking DeviceNode(parameter_server_set_used_request) as advertised in process_remote_topic
INFO  [muorb] SLPI: Marking DeviceNode(parameter_server_set_used_response) as advertised in process_remote_to
INFO  [uORB] Marking DeviceNode(parameter_client_set_value_response) as advertised in process_remote_topic
INFO  [parameters] BSON document size 3781 bytes, decoded 3781 bytes (INT32:54, FLOAT:120)
INFO  [logger] logger started (mode=all)
Starting IMU driver with no rotation
INFO  [qshell] Send cmd: 'icm42688p start -s'
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: icm42688p start -s
INFO  [muorb] SLPI:   arg0 = 'icm42688p'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-s'

INFO  [muorb] SLPI: *** SPI Device ID 0x26000a 2490378
INFO  [uORB] Advertising remote topic sensor_accel
INFO  [uORB] Advertising remote topic sensor_gyro
INFO  [muorb] SLPI: ICM42688P::probe successful!
INFO  [muorb] SLPI: on SPI bus 1
INFO  [muorb] SLPI: icm42688p #0 on SPI bus 1
INFO  [muorb] SLPI: 

INFO  [muorb] SLPI: >>> ICM42688P this: 3176cf40
INFO  [muorb] SLPI: Ok executing command: icm42688p start -s
INFO  [uORB] Advertising remote topic qshell_retval
INFO  [muorb] SLPI: >>> ICM42688P this: 3176cf40
INFO  [qshell] qshell return value timestamp: 630951289, local time: 630954493
INFO  [muorb] SLPI: >>> ICM42688P this: 3176cf40
INFO  [muorb] SLPI: Register interrupt b21d31a4 e61fedbc 3176cf40
INFO  [uORB] Advertising remote topic sensor_gyro_fifo
INFO  [uORB] Advertising remote topic sensor_accel_fifo
INFO  [uORB] Advertising remote topic imu_server
INFO  [qshell] Send cmd: 'icp101xx start -I -b 5'
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: icp101xx start -I -b 5
INFO  [muorb] SLPI:   arg0 = 'icp101xx'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-I'

INFO  [muorb] SLPI:   arg3 = '-b'

INFO  [muorb] SLPI:   arg4 = '5'

INFO  [muorb] SLPI: *** I2C Device ID 0xb76329 12018473
INFO  [muorb] SLPI: icp101xx #0 on I2C bus 5
INFO  [muorb] SLPI:  address 0x63
INFO  [muorb] SLPI: 

INFO  [muorb] SLPI: Ok executing command: icp101xx start -I -b 5
INFO  [qshell] qshell return value timestamp: 630997270, local time: 630998910
Looking for qmc5883l magnetometer
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [qshell] Send cmd: 'qmc5883l start -R 10 -X -b 1'
INFO  [muorb] SLPI: qshell gotten: qmc5883l start -R 10 -X -b 1
INFO  [muorb] SLPI:   arg0 = 'qmc5883l'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-R'

INFO  [muorb] SLPI:   arg3 = '10'

INFO  [muorb] SLPI:   arg4 = '-X'

INFO  [muorb] SLPI:   arg5 = '-b'

INFO  [muorb] SLPI:   arg6 = '1'

INFO  [muorb] SLPI: *** I2C Device ID 0x80d09 527625
ERROR [muorb] SLPI: i2c probe failed
INFO  [muorb] SLPI: PX4_qshell: no instance started (no device on bus?)
ERROR [muorb] SLPI: Failed to execute command: qmc5883l start -R 10 -X -b 1
INFO  [qshell] cmd returned with: -1
INFO  [qshell] qshell return value timestamp: 631032869, local time: 631036064
ERROR [qshell] Command failed
Looking for ist8310 magnetometer
INFO  [muorb] SLPI: >>> ICM42688P this: 3176cf40
INFO  [qshell] Send cmd: 'ist8310 start -R 10 -X -b 1'
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: ist8310 start -R 10 -X -b 1
INFO  [muorb] SLPI:   arg0 = 'ist8310'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-R'

INFO  [muorb] SLPI:   arg3 = '10'

INFO  [muorb] SLPI:   arg4 = '-X'

INFO  [muorb] SLPI:   arg5 = '-b'

INFO  [muorb] SLPI:   arg6 = '1'

INFO  [muorb] SLPI: *** I2C Device ID 0x60e09 396809
INFO  [muorb] SLPI: ist8310 #0 on I2C bus 1
INFO  [muorb] SLPI:  (external)
INFO  [muorb] SLPI:  address 0xE
INFO  [muorb] SLPI:  rotation 10
INFO  [muorb] SLPI: 

INFO  [muorb] SLPI: Ok executing command: ist8310 start -R 10 -X -b 1
INFO  [qshell] qshell return value timestamp: 631080626, local time: 631084258
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: gps start
INFO  [muorb] SLPI:   arg0 = 'gps'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI: Creating pthread gps

INFO  [muorb] SLPI: Successfully created px4 task PX4_gps with tid 2097647
INFO  [muorb] SLPI: Ok executing command: gps start
INFO  [qshell] Send cmd: 'gps start'
INFO  [qshell] qshell return value timestamp: 631107876, local time: 631109005
Looking for ncp5623c RGB LED
INFO  [muorb] SLPI: GPS UART baudrate set to 115200
INFO  [qshell] Send cmd: 'rgbled_ncp5623c start -X -b 1 -f 400 -a 56'
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: rgbled_ncp5623c start -X -b 1 -f 400 -a 56
INFO  [muorb] SLPI:   arg0 = 'rgbled_ncp5623c'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-X'

INFO  [muorb] SLPI:   arg3 = '-b'

INFO  [muorb] SLPI:   arg4 = '1'

INFO  [muorb] SLPI:   arg5 = '-f'

INFO  [muorb] SLPI:   arg6 = '400'

INFO  [muorb] SLPI:   arg7 = '-a'

INFO  [muorb] SLPI:   arg8 = '56'

INFO  [muorb] SLPI: *** I2C Device ID 0x7b3809 8075273
INFO  [muorb] SLPI: rgbled_ncp5623c #0 on I2C bus 1
INFO  [muorb] SLPI:  (external)
INFO  [muorb] SLPI:  address 0x38
INFO  [muorb] SLPI: 

INFO  [muorb] SLPI: Ok executing command: rgbled_ncp5623c start -X -b 1 -f 400 -a 56
INFO  [qshell] qshell return value timestamp: 631152080, local time: 631155799
INFO  [uORB] Advertising remote topic sensor_mag
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: pca9685_pwm_out start -b 4 -a 0x40
INFO  [muorb] SLPI:   arg0 = 'pca9685_pwm_out'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [muorb] SLPI:   arg2 = '-b'

INFO  [muorb] SLPI:   arg3 = '4'

INFO  [muorb] SLPI:   arg4 = '-a'

INFO  [muorb] SLPI:   arg5 = '0x40'

INFO  [muorb] SLPI: Invalid bus
ERROR [muorb] SLPI: Task start failed (-1)
ERROR [muorb] SLPI: Failed to execute command: pca9685_pwm_out start -b 4 -a 0x40
INFO  [qshell] Send cmd: 'pca9685_pwm_out start -b 4 -a 0x40'
INFO  [qshell] cmd returned with: -1
INFO  [qshell] qshell return value timestamp: 631186542, local time: 631187811
ERROR [qshell] Command failed
INFO  [uORB] Advertising remote topic sensor_baro
Starting VOXL ESC driver
INFO  [qshell] Send cmd: 'voxl_esc start'
INFO  [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO  [muorb] SLPI: qshell gotten: voxl_esc start
INFO  [muorb] SLPI:   arg0 = 'voxl_esc'

INFO  [muorb] SLPI:   arg1 = 'start'

INFO  [uORB] Advertising remote topic actuator_outputs

```

I think PX4 is unable to identify the bus and it is saying invalid bus for command "pca9685_pwm_out start -b 4 -a 0x40". Please help.

## Reply by Aaky · 2024-02-22 12:12:58 UTC

@modaltb Got this sorted. Was some power supply problem. Now next hurdle is getting actuator output over QGC. I am unable to see PCA9685_PWM_OUT over QGC and only VOXL_ESC menu is shown. How can I enable actuator output for PCA9685 over QGC as shown on [this PR](https://github.com/PX4/PX4-Autopilot/pull/21528)? I have integrated new driver for PCA9685 from [this PR](https://github.com/PX4/PX4-Autopilot/pull/21528) into my voxl-dev fork.

## Reply by Aaky · 2024-03-18 07:41:14 UTC (in reply to Aaky)

@modaltb @Alex-Kushleyev @Eric-Katzfey 
I am working on this integration of PCA9685 driver over I2C bus on J19 as described above.

I had to modify the driver code to actually make it work over slpi processor with I2C bus 4 and it gets connected well and also PCA chip seems to be communicating with VOXL. Now next I also had to include this driver on application processor post which I got to see PCA9685 control options in actuator tab on Qground control. Now I am able to select output function over any channel of PCA9685 say "Gripper" and I can actually move the slider to send PWM signals to PCA9685. I had put some debug messages in PCA9685 driver and have also checked actuator_outputs topic with px4-listener. I can see PWM data been streamed by Qground control to PCA9685 driver and also over actuator_outputs topic but still my servo dosent move at all. 

I have changed my PCA chip multiple times just to eliminate if it's hardware problem but no luck. Can someone help me quickly to debug this problem? 
I will also send over the modifications which I have done in build pipeline of Voxl2-px4 if necessary to see what is the problem.

## Reply by Aaky · 2024-03-18 10:02:27 UTC (in reply to Aaky)

Update :

Here is the pull request which I have ported into voxl-dev branch : https://github.com/PX4/PX4-Autopilot/pull/21528

On main stream PX4, 'main' branch has this driver already integrated and I flashed this on Cube orange for verifying the operation. So this pca9685 driver works out of the box over there where I connected servo to pca9685 and used QGC's actuator output window to drive the servo which worked well. But with voxl2 dev branch I am unable to make it work.

I might be missing something in setting up I2C on slpi or setting up driver on application processor. Please help me ahead in this regards.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-18 12:51:48 UTC (in reply to Aaky)

@Aaky , I have not used PCA9685, but I understand what it does. Quick question, are you working integrating that due to a limitation of pwm outputs in the VOXL2_IO driver?

I am just asking because it is easier for us to provide support for our own hardware. I am not sure how much we can help with 3rd party hardware and drivers.

Alex

## Reply by Aaky · 2024-03-19 02:09:31 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Yes Alex, I need one or if possible two PWM outputs for controlling one servo (Only PWM without any duty cycle requirements) and one LED from VOXL. Also Yes, I had to take up PCA9685 due to PWM output limitations in VOXL2_IO driver. Is it possible to provide more PWM channels over VOXL2_IO driver? This can solve all my problems.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-19 02:37:15 UTC (in reply to Aaky)

@Aaky , We are currently testing (before releasing) updated firmware for m0065 and updated voxl2_io driver that enables up to 8 actuators (configurable via standard actuator options). You could set it up as 4 motors and up to 4 additional servo / standard pwm signals. This update also fixes the actuator range from 0..800 to standard 1000-2000 range (microseconds) and i believe we have addressed potential issues in ESC calibration procedure.

You can preview the current px4 branch with these changes here : https://github.com/modalai/px4-firmware/tree/voxl2-io-cleanup/src/drivers/voxl2_io but it also requires updated m0065 board firmware. If you are interested to get early access to this release, we can share it after some additional testing.

## Reply by Aaky · 2024-03-19 02:49:50 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thank you Alex for the update. I do have updated M0065 board and firmware, if any new compatible firmware is essential I can flash the same, just point me to right address. 

@Alex-Kushleyev said in [Connecting i2c device on voxl2](/post/15475):
> We are currently testing (before releasing) updated firmware for m0065 and updated voxl2_io driver that enables up to 8 actuators (configurable via standard actuator options). You could set it up as 4 motors and up to 4 additional servo / standard pwm signals. This update also fixes the actuator range from 0..800 to standard 1000-2000 range (microseconds) and i believe we have addressed potential issues in ESC calibration procedure.

Perfect. This will solve my problem. Actually I have very important demonstration coming up and I would need this update as soon as within next 1-2 days, Is it possible for you to share the early access of m0065 firmware and voxl2_io driver now? It would be really helpful if it dosent break anything on aircraft control side (first four PWM channels) and I can experiment with other PWM channels for controlling servo. Please let me know since this is urgent priority for me.

## Reply by Aaky · 2024-03-19 04:33:37 UTC (in reply to Aaky)

@Alex-Kushleyev Even if this is under development but wouldn't break anything, Please share the compatible M0065 firmware with me. I will test out the voxl2_io driver from the above branch and latest m0065 firmware to operate servo maybe by today itself.
Also if you are sharing the firmware now, let me know if I only cherry pick the voxl2_driver and put it into latest voxl_dev branch, would that work? Is voxl_dev in sync with voxl2_io_cleanup branch?

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-19 04:46:05 UTC (in reply to Aaky)

@Aaky , We can share the pre-release m0065 firmware (and the px4 code is already in the branch i mentioned). I would recommend to begin testing without propellers on and confirm the configuration of motors and servos is working fine. We should be able to do more testing in the next 1-2 days. Also, you can revert m0065 firmware and use the px4 from voxl-dev branch.

I just uploaded the test firmware here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl2-io/-/tree/pwm-improvements/voxl2-io-tools/firmware .  You can update the firmware using our `voxl-esc` tools:

```
#stop px4
systemctl stop voxl-px4

#replace $FIRMWARE_FILE below with path to the new firmware
cd /usr/share/modalai/voxl-esc-tools;
./voxl-esc-upload-firmware.py \
                  --id 0 \
                  --firmware-file $FIRMWARE_FILE \
                  --device /dev/slpi-uart-2
```

Blue LED will blink slowly during firmware update.

(you can also use the same procedure to restore original firmware)

Then you should reboot your VOXL2 board before you use PX4 again because sometimes the firmware update causes some issues and PX4 cannot start.

You can build px4 using the following branch of `px4-firmware` : https://github.com/modalai/px4-firmware/tree/voxl2-io-cleanup/src/drivers/voxl2_io . i suggest building the deb package and installing it using the deb, rather than copying files to target directly.

When you run the new branch of PX4 for the first, time, you should run it in foreground and check if VOXL2_IO has been detected. You should get output like this :

```
voxl-px4 -d | grep VOXL2_IO
ESC: VOXL2_IO_PWM_ESC
INFO  [muorb] SLPI: VOXL2_IO: Driver starting
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_BAUD  : 921600
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC1 : 101
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC2 : 102
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC3 : 103
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC4 : 104
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC5 : 0
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC6 : 0
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC7 : 0
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_FUNC8 : 0
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_DIS   : 1000
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_MIN   : 1100
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_MAX   : 2000
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_CMIN  : 1050
INFO  [muorb] SLPI: VOXL2_IO: Params: VOXL2_IO_CMAX  : 2000
INFO  [muorb] SLPI: VOXL2_IO: 
INFO  [muorb] SLPI: VOXL2_IO: Opening UART device 2, baud rate 921600
INFO  [muorb] SLPI: VOXL2_IO: Successfully opened UART device
INFO  [muorb] SLPI: VOXL2_IO: Detecting M0065 board...
INFO  [muorb] SLPI: VOXL2_IO: 	VOXL2_IO ID: 0
INFO  [muorb] SLPI: VOXL2_IO: 	Board Type : 35: ModalAi I/O Expander (M0065)
INFO  [muorb] SLPI: VOXL2_IO: 	Unique ID  : 0x4304296039364B560671FF36
INFO  [muorb] SLPI: VOXL2_IO: 	Firmware   : version    2, hash f94baad1
INFO  [muorb] SLPI: VOXL2_IO: 	Bootloader : version    0, hash 17147346*
INFO  [muorb] SLPI: VOXL2_IO: 	Reply time : 2550us
INFO  [muorb] SLPI: VOXL2_IO: Driver initialization succeeded
..

```
Please note the firmware will be version 2 and hash will match the hash in the m0065 binary firmware name (`f94baad1`)

You will see there were new parameters added, you can see their values in the print above:
```
VOXL2_IO_DIS   : 1000 #pulse in microseconds when not armed
VOXL2_IO_MIN   : 1100 #min pulse in microseconds when armed
VOXL2_IO_MAX   : 2000 #max pulse in microseconds when armed
VOXL2_IO_CMIN  : 1050 #min pulse in microseconds during esc calibration procedure
VOXL2_IO_CMAX  : 2000 #max pulse in microseconds during esc calibration procedure
```
You can see we added separate params for pulses to be send during ESC calibration, so that the minimum calibration pulse is lower than the minimum when armed. You should make sure your params match these, if not, then set them to these values. You should then perform the ESC calibration, I have outlined here:

Suggested ESC calibration procedure:
- power on VOXL2 and ESC while the PWM cable is not plugged into VOXL2. Calibration procedure only works before the ESC receives any valid signals
- start px4 and QGC and verify that the calibration parameters are set to suggested values (min 1050 and max 2000) and regular min and max values are set to min=1100 and max=2000.
- verify that the voxl2_io driver has started correctly : either qshell voxl2_io status  or look at the blue led on M0065 should be blinking which means it is receiving the pwm commands from voxl2_io driver (the disabled commands, since not armed)
- start the custom esc calibration procedure : “qshell voxl2_io calibrate_escs” and follow instructions (which are mainly just plug in the motor pwm cable into m0065 within 10 seconds). You can enter this command right in the px4 prompt, if you start px4 using `voxl-px4 -d` in foreground in interactive mode
- after the calibration is complete, test to make sure the PWM ranges have been correctly set:
    - using QGC actuator test, set the actuator from disabled to 1100 and the motors should spinup and stay on (no jerking)
    - it is encouraged to double check the motor starting point but temporarily lowering the VOXL2_IO_MIN param to 1000 and using actuator test to find the motor starting point, should be around 1060 (the calibration value was 1050). If the motor starting point is very close to 1100, it may not be safe to use this configuration, because if mixer commands 1100 during flight, variations due to temperature of the ESC MCU could cause 1100 command to be interpreted as DISABLED.
    - IMPORTANT: if VOXL2_IO_MIN was temporarily modified to find the motor starting point, revert it back to the desired value of 1100

In order to test actuators other than the 4 motors, you can use QGC to configure the actuator function as for normal actuators.

Finally, I would like to remind you to start testing without propellers attached. We will be doing more testing in the next few days, but if you feel confident after no-prop testing, you can try flying. I have not experienced any issues with the new m0065 firmware or the voxl2_io px4 driver so far that would be a concern. However, there is still a higher than usual risk, so please test at your own risk (for now). Also please note that only v2 firmware should be used with this test branch (it actually checks for firmware version) and only v1 firmware must be used with the current px4 in voxl-dev.

I hope this works for you, let me know if you run into any issues.

Alex

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-19 04:53:33 UTC (in reply to Alex Kushleyev)

regarding `voxl-dev` branch and the test branch, they are not in sync, i think I branched from `voxl-dev` a few weeks ago, but it should be very recent. the only changes were made were in the `voxl2_io` folder and there were no other changes in my branch related to `voxl2_io` functionality, so you could cherry pick all the commits from that branch, or just merge from dev into the test branch (locally on your machine), whichever works for you.

## Reply by Aaky · 2024-03-19 05:11:33 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Superb. Thanks alot Alex for such quick and prompt response. I will start testing this functionality and get back to you soon.
Also just a normal query, Can I assign PWM channel to servo as normal PWM and not in duty cycle mode unlike those on aircraft bldc motors from QGC actuator tab? My servo is actually a gripper which will be just having two values for closing and opening.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-19 05:20:36 UTC (in reply to Aaky)

@Aaky , PWM by definition is Pulse Width Modulation, so the pulses will be generated with  appropriate pulse width as sent by the actuator mixer. This is the same as setting the duty cycle of the pulse (duty cycle simply means proportion of the ON=width cycle vs total cycle length).

 Whatever is controlling the servo to open / close should send the desired command and the mixer will convert it to the pulse 1-2ms and m0065 board will receive that command and execute it. You could set up a toggle (2-state) switch on your RC to send out the correct values for open / close the gripper. You can select the actuator source to be a switch on the RC. Please note that i think the pwm values might update only in armed state, you can check.

## Reply by Aaky · 2024-03-19 05:42:06 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thank alot Alex. I will surely get back to you with my analysis soon over this.

## Reply by Aaky · 2024-03-19 07:22:03 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Hi Alex, I upgraded the M0065 firmware and also cherry picked all commits from voxl2-io-cleanup branch into voxl-dev branch on my local machine. My aircraft motors are working well and also the servo is operational. Thanks alot for this upgrade.

I am facing one problem with servo control, servo keeps on jittering continously maybe with continously received PWM values. When I increase the slider value in actuator tab in QGC it definately does move the servo and also keeps it quite (non jittery) only sometimes but most of the times its jittery when I close the actuator tab (When PWM values go back to 0). I am using Analog servo. Will try with digital servo as well.

Any insights? I am configuring the channel 5 on voxl2_io as "Gripper" in actuator control tab on QGC.

## Reply by Aaky · 2024-03-19 10:48:25 UTC (in reply to Aaky)

@Alex-Kushleyev Also what is PWM output frequency from voxl2 IO? And is this frequency same for actuators/servo channels as well?

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-19 12:27:47 UTC (in reply to Aaky)

@Aaky,

In the current m0065 firmware, the board outputs the pwm pulses in OneShot mode. This means for every command from flight controller (VOXL2), there is one pulse that is generated and this pulse is essentially synchronized / triggered by the flight controller (this minimizes latency). The pulse width  that m0065 produces should not be jittery, however the update rate does vary because the flight controller update rate is not consistent. The update rate of PWM is about 400hz, which is half the rate at which the flight controller update loop is running. 400hz is a limitation of the 1-2ms pulse - it needs to have some off time and 400hs is 2.5ms.

This should not be an issue if the esc / servo is actually measuring the ON width, since the ON width should not be jittery. For example, the motors are spinning smoothly, right?

Sometimes low cost servos instead of capturing the actual width of control signal, use and RC filter to get an average voltage and use ADC to measure that voltage and use it to control the servo angle. If this is true, then varying update rate of m0065 pwm could cause some jitter.

If you want to try, i can send you a test firmware for m0065 that does not do OneShot, but outputs pwm at fixed frequency (lets say exactly 400hz).

Also, perhaps there may be noisy power to the servo - what power source did you use foe the servo? Maybe the control signal is getting some noise if the servo cable is long - that is a possibility. 

You can test the existing set up with a few different servos and see if you get a different result (I know that you may not be able to change the servo that is inside the gripper).

## Reply by Aaky · 2024-03-20 04:30:45 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thanks for the response and brief description of m0065 outputs. Highly appreciated. So even when we select Channel function as some other actuator like Gripper still Onshot is used over output lines? Was the previous M0065 firmware also oneshot based or this firmware has changes?

We are providing seperate 5V power supply to servo from BEC. We are changing the servo from analog to digital in order to confirm the behaviour and will get back to you.

## Reply by Aaky · 2024-03-20 13:32:54 UTC (in reply to Aaky)

@Alex-Kushleyev One more help is essential,
 For my gripper control from joystick or in mission modes, there is one module in PX4 at [this link](https://docs.px4.io/main/en/flying/package_delivery_mission.html) . Payload deliverer I tested in SITL, where if I allocate joystick buttons to Gripper open and gripper close, and if I allocate Channel 5 (say) to gripper, then the PWM are published over those channel in order to operate any actuators. (Verified this by looking at SERVO_OUTPUT mavlink message in QGC mavlink inspector)

Whereas I added payload delivere module in voxl-px4 firmware and I got the gripper related parameters also in QGC which ensured module has been loaded successfully and also I verified in the logs, still when I toggle joystick gripper open close it dosent publish PWM on VOXL2_IO channel 5 allocated to gripper, but actuator tab operates well. Any clue what must be missing? I beleive payload_deliverer is not listening to gripper related commands or voxl2_io is not connected to payload deliverer module. Let me know if you have any clues.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-20 14:01:52 UTC (in reply to Aaky)

@Aaky , yes the latest M0065 firmware is using OneShot style pulses, which is better for all modern ESCs. Please try the digital servo as you are already planning to do.

I am not familiar with the joystick setup in PX4. As long as the actuator test is working, it means the signal from the mixer is getting to voxl2_io driver and the correct command is sent to M0065 board and executed. It seems your joystick driver may not be sending out the correct command to the mixer.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-20 14:14:00 UTC (in reply to Alex Kushleyev)

If you really need to try the periodic (standard, not OneShot PWM), i can add an option to use that.

## Reply by Aaky · 2024-03-20 14:52:12 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thanks Alex. I will let you know if PWM instead of Oneshot is to be tried out. I am yet to test Digital servo.

Also regarding joystick setup, it works only after armed in any flight mode. Thanks for your inputs in this.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-20 16:06:02 UTC (in reply to Aaky)

@Aaky , yes i saw that if not armed, all the actuators are disabled. I think it is a PX4 "feature" and i am not sure if you can bypass it. If you figure out how, please let us know!

## Reply by Aaky · 2024-03-21 09:38:15 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Yes I am trying to see before arming how to get gripper control. Also with digital servo M0065 Oneshot works well without any jitter. So thank you once again for that update.

## Reply by Aaky · 2024-03-23 15:27:21 UTC (in reply to Aaky)

@Alex-Kushleyev We came across extremely weird problem and our aircraft crashed on ground from height of 10 meters due to this. All the actuator outputs saturated and started to vary between 0 to 100% throttle. Please have a look at our log file below. We were comfortably flying UAV for ore then 60 mins in multiples flights, but all of sudden while navigating at high speeds in mission mode, our aircraft crashed.
Note : After this flight now our aircraft isnt able to takeoff at all, motors dosent seem to be providing enough thrust. Somehow we dont know if its ESC's fault or M0065. We are thinking to replace ESC and check again or maybe Capacitor over ESC gone bad. 
Let me know if you have any clue. Please look at the flight towards the very end.
Log : https://review.px4.io/plot_app?log=9032c82a-421a-4f25-8fe5-30bff45cadf0

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-23 16:01:44 UTC (in reply to Aaky)

@Aaky , it looks like your motor 4 (black) was operating at maximum output (1.0) for some time (when the battery voltage got lower and lower) and i suspect that it just could not maintain attitude (roll / pitch) control because the motor 4 was saturated and the drone flipped over. If the actuator saturation occurs, the drone cannot maintain stability. I can take a look at the log more carefully later, but that seems like the issue. Did the drone flip over first then fell? The actuator saturation can be caused by imbalance in center of gravity, since other motors are not saturated. but also it looks like at the low battery voltage there is not much extra margin of thrust for sufficient control.

![e7433a59-6977-413f-8a8c-94790be2dce5-image.png](https://forum.modalai.com/assets/uploads/files/1711209498033-e7433a59-6977-413f-8a8c-94790be2dce5-image.png)

## Reply by Aaky · 2024-03-23 16:41:55 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev thanks for your analysis Alex. Yes drone did flip but it flipped on ground if I remember correctly. Motor 4's saturation might have caused bit of saturation in other motors as well. But very weird problem is now aircraft isn't able to takeoff even at full battery condition. What can be the problem? Is it possible any components involving ESC or ESC itself damaged?

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-23 16:46:04 UTC (in reply to Aaky)

@Aaky , hmm not sure. You should look at the px4 logs of the takeoff attempts after crash and see what the actuator outputs look like. Also try manual mode (thrust, attitude) if you are comfortable flying (instead of position / height control - not sure which one are you testing now)

## Reply by Aaky · 2024-03-23 16:50:32 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Here is the log of flight after this crash where aircraft wasn't able to takeoff.
 We tried in Altitude mode as well as in position mode by increasing throttle upto 80% still aircraft didn't takeoff.
Log : https://review.px4.io/plot_app?log=84d281b9-2756-45c3-b064-ea38848f8580

This shouldn't be M0065 problem right? Just  wanted to eliminate the variables.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-23 19:34:02 UTC (in reply to Aaky)

@Aaky, in your first flight, your actuator controls (thrust) was above 0.5 when vehicle took off:

![165b6380-dcfd-41c9-bbf0-fce561cc6c46-image.png](https://forum.modalai.com/assets/uploads/files/1711221972638-165b6380-dcfd-41c9-bbf0-fce561cc6c46-image.png) 

But in your last test (you were in altitude control mode), the thrust barely reached 0.3 - that is not enough for vehicle to take off. That is why i was suggesting to test in thrust / angle mode (not altitude hold).

![c5945927-c01d-4853-9655-88db5fa3b61c-image.png](https://forum.modalai.com/assets/uploads/files/1711222023829-c5945927-c01d-4853-9655-88db5fa3b61c-image.png) 

Also, your motor outputs are quite noisy, perhaps the flight board became loose after the crash, not sure.

![d5e8b416-14cc-4528-9587-17a88dfd2744-image.png](https://forum.modalai.com/assets/uploads/files/1711222118141-d5e8b416-14cc-4528-9587-17a88dfd2744-image.png)

## Reply by Aaky · 2024-03-25 18:14:56 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thanks Alex. Can you also send me M0065 firmware with normal PWM outputs on 8 channels of actuators? Maybe a switch over existing firmware with capability to switch between Oneshot vs PWM as you told before. 
I tried flying today but aircraft is having serious vibrations which didn't exist on our previous flights. We have used dampeners still vibration and controls look very rough. I might just try with normal PWM also once.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-25 20:36:02 UTC (in reply to Aaky)

@Aaky , Sure we can try it, but i suspect the PWM output may not be an issue if it did not have the vibration right before the crash. 

I do not have the firmware with this change ready to go, but it is an easy switch. I need to test it first and i can provide it to you tomorrow. 

Meanwhile, I suggest to you to do a thorough inspection of the frame. You can also an actuator test (without propellers) to make sure the motor output seems smooth, at least when you are not flying. 

When I looked at the original log with the crash, it seemed to me that the gyro vibrations were a bit high, resulting in motor outputs to be noisy as well. Perhaps after a crash something changed (became more loose) and the vibration worsened, pushing the performance past the point of stability.

Please make sure that any cables that connect to VOXL2 are not tight, which can cause vibration to travel via cables or even pull on the cables if another component is loose on the frame.

I am not sure how much PID tuning you have done, but if the D gain on attitude control is set too high with noisy gyro, this will cause the noisy motor commands to be sent to motors.

## Reply by Aaky · 2024-03-26 17:20:04 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Yes you were right. Problem was not with M0065 controling the motor. We got our vibrations sorted with good dampeners and now our drone flies well. Thank you! :)

## Reply by Alex Kushleyev (ModalAI staff) · 2024-03-26 20:19:26 UTC (in reply to Aaky)

@Aaky Great! 

One advice: save a few logs of good flights for future reference. In future, if something goes bad, you can go back and look at the old logs vs new logs and compare the amount of vibration, actuator outputs, etc.

## Reply by Aaky · 2024-03-31 08:28:17 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Yes Alex Noted. 

We were flying okish since last few days and we had another crash similar to last one. While we are seeing into our propulsion system design (motor propeller and battery), Aircraft this time flipped midair and the reason is absolutely unknown. I just wanted to eliminate if PWM outputs were given correctly to motors from M0065 in below shown flight while it crashed towards the end? I just wanted to check if PWM outputs were all above 1100 and none of the motor was commanded below the same. My VOXL2_IO_MIN and MAX are 1100 and 2000 respectively. Just eliminating any software problem over here once again. Let me know if you can help :)

Log : https://review.px4.io/plot_app?log=d9d7feb3-9e5a-469f-ac95-a4914a243fbe

## Reply by Alex Kushleyev (ModalAI staff) · 2024-04-01 15:59:20 UTC (in reply to Aaky)

@Aaky ,

I took a look at the log, the case seems a bit complicated. It seems the issue starts 6:38:500 when there is a sudden jerk that appears in Roll Rate, see here :
![c504e1c1-234b-4bb3-bc08-f233b0f3fb94-image.png](https://forum.modalai.com/assets/uploads/files/1711986647030-c504e1c1-234b-4bb3-bc08-f233b0f3fb94-image.png) 

As a a result, the vehicle tries to counter act and responds in actuator outputs (negative roll command to counteract the positive roll rate spike)

![4c04d157-6c2e-4c6a-bf54-f4f6da4aa8df-image.png](https://forum.modalai.com/assets/uploads/files/1711986731822-4c04d157-6c2e-4c6a-bf54-f4f6da4aa8df-image.png) 

This causes a sudden change in requested motor commands:
![80012099-329b-4869-a396-7adf19325563-image.png](https://forum.modalai.com/assets/uploads/files/1711986773162-80012099-329b-4869-a396-7adf19325563-image.png) 

After that the vehicle starts oscillating and motor outputs are saturated. To me, it is unclear where the spike in the roll angular rate comes from after very low-noise fligiht. It is almost if something suddenly got loose, snapped, or hit the flight board, causing that angular rate spike. If the flight board became loose, it would have been impossible to stabilize the vehicle after that.

Since you are using 3rd party ESCs, we do not have motor feedback, so we cannot tell if the motors performed well, but it does not look like the motors stopped, as the vehicle appears to start oscillating back and forth in roll initially. Also, if one or more motors simply stopped, we would have a smooth tumble - instead we are seeing a high roll rate impulse that seems to case oscillations and then the crash.

I would suggest to inspect the vehicle and look for potential sources of that initial roll rate jerk that may have caused the oscillations and then crash.

Alex

## Reply by Alex Kushleyev (ModalAI staff) · 2024-04-01 19:16:09 UTC (in reply to Alex Kushleyev)

Even though it is not clear what the initial roll rate spike came from, it seems that it served as an impulse test of the attitude controller and the vehicle started oscillating. If nothing actually came loose during the flight, this may suggest that your attitude controller is not stable and given an large disturbance it can become unstable. There are many unknown variables, but you may need to increase your D gain in your attitude controller to dampen the response. However, still, it is still not clear where the original roll rate impulse came from here..

## Reply by Aaky · 2024-04-02 07:08:51 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thanks for your analysis Alex. This is somewhat a mystery for us as well. Actually in terms of motor saturation, I feel motor saturation started first at timestamp 6:38:560 onwards motors had started to struggle leading to roll failure. We are suspecting if propeller broke in flight, since it was not in our visual sight flying 200 meters away. We flew with another set of propeller at very high speed again and things were all normal this time. There isn't any concrete answer to this just speculations as of now.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-04-03 19:45:41 UTC (in reply to Aaky)

@Aaky Yes, it seems something "mechanical" happened right before the flip. a broken prop may cause impact on the frame and detected by the gyro as that spike. I am glad the vehicle is flying normally again! Regular inspection of the vehicle components is recommended :)

## Reply by Aaky · 2024-04-06 10:37:56 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Definitely Thanks for the support.

On a seperate note, I have one more query. I have a gimbal which expects PX4's Attitude to be fed into it for better attitude control of gimbal (Typically every good gimbal expects Autopilot's attitude to be fed into it). So for this my gimbal has UART port which can capture mavlink packets been broadcasted by autopilot and act accordingly. Can we do this integration using VOXL's ESC UART port to broadcast mavlink packets into my gimbal's UART port in the same way like any Pixhawk Cube based Autopilot running PX4 can output mavlink packets over telem port?

## Reply by Aaky · 2024-04-08 13:24:56 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Alex, Along with above query I wanted to consult one more point with you. With new updated M0065 firmware supporting OneShot and we using [this ESC](https://shop.tmotor.com/products/fpv-drones-v45a-v2-6s-4in1-esc) from Tmotor F45A. Are they both fully compatible? I suppose this ESC even supports Dshot but not sure about OneShot. Actually we are been facing hard time with vibrations on our aircraft. We tried different dampeners, referred sentinel dampeners, tried different propellers like 9 to 11 inch but vibrations aren't going away so just wanted to check if our ESC is fully compatible with Oneshot first. Just FYI we had extremely less vibration when we flew for the first time with our custom drone with older M0065 firmware (voxl2_io_firmware_m0065_v1_35_58c82813.bin) and 11 inch propeller but now when we are trying to replicate the same setup we are facing extreme vibrations. I also read you comment [over here](https://forum.modalai.com/post/15864) about Oneshot increasing the update rate possibly picking up more gyro noise. I checked by going back on older firmware and older px4 branch but no luck over there as well. Anywhich way even with Oneshot aircraft is able to fly solid but only problem is vibrations going high. Let me know your thoughts.

## Reply by Alex Kushleyev (ModalAI staff) · 2024-04-09 13:14:15 UTC (in reply to Aaky)

@Aaky , i will be back to office on Wednesday and will follow up with replies to your questions.

## Reply by Aaky · 2024-04-09 14:57:23 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev No problem Alex.
 In the meantime @Eric-Katzfey if you can  provide me some insights on my following query ? 

@Aaky said in [Connecting i2c device on voxl2](/post/16029):
> I have one more query. I have a gimbal which expects PX4's Attitude to be fed into it for better attitude control of gimbal (Typically every good gimbal expects Autopilot's attitude to be fed into it). So for this my gimbal has UART port which can capture mavlink packets been broadcasted by autopilot and act accordingly. Can we do this integration using VOXL's ESC UART port to broadcast mavlink packets into my gimbal's UART port in the same way like any Pixhawk Cube based Autopilot running PX4 can output mavlink packets over telem port?

## Reply by Eric Katzfey (ModalAI staff) · 2024-04-09 15:03:19 UTC (in reply to Aaky)

@Aaky If you are running PX4 on VOXL2 then you cannot use the DSP UARTs outside of PX4. And within PX4 all data is transferred as topics, not mavlink. To do what you want you need a UART on the apps processor side (available on certain add on boards) and have voxl-mavlink-server route the appropriate mavlink messages to it.

## Reply by Aaky · 2024-04-09 15:13:30 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Okay. So normal Telem ports as they are available on Pixhawk Autopilot running vanilla PX4 arent available on VOXL-PX4? The application processor side integration sounds complex to my architecture since I already have one Add-on board sitting over VOXL providing USB connection for my Doodle labs radio. Any other feasible option?

## Reply by Eric Katzfey (ModalAI staff) · 2024-04-10 16:15:10 UTC (in reply to Aaky)

@Aaky Correct. VOXL2 uses UDP for it's Mavlink telemetry, not UART TELEM ports like on a microcontroller based autopilot. But, voxl-mavlink-server should be able to route Mavlink messages over an apps processor based UART such that it would be similar to a TELEM port. Which add-on board is it? Is it something custom or one of our boards?

## Reply by Aaky · 2024-04-10 17:06:34 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Thanks for the information. The add on board is Microhard modem B2B board without any Microhard radio in it acting just as USB port provider for my doodle labs modem. How can I get UART port if I am using this board?

## Reply by Aaky · 2024-04-11 08:16:52 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Eric, Say I connect UART from [this expansion board](https://docs.modalai.com/voxl2-usb3-uart-add-on-datasheet/), What all changes I need to do in voxl-mavlink-server in order to broadcast PX4 attitude mavlink packets to my gimbal? I understand this UART is meant for external flight controller communication so will it work straight out of the box?

## Reply by Eric Katzfey (ModalAI staff) · 2024-04-11 17:07:23 UTC (in reply to Aaky)

@Aaky That is not a standard configuration that we test with so likely will not work out of the box. But it shouldn't be too hard to adapt voxl-mavlink-server to your use case. And if you make changes that you think would benefit other users we would gladly accept a Pull Request with the updates.

## Reply by Eric Katzfey (ModalAI staff) · 2024-04-11 17:08:13 UTC (in reply to Aaky)

@Aaky Yes, you could use the UART exposed on that M0125 expansion board.

## Reply by Eric Katzfey (ModalAI staff) · 2024-04-11 17:10:25 UTC (in reply to Aaky)

@Aaky The Microhard board does not expose an apps processor UART but you could use a USB to UART adapter to connect to the Gimbal via one of the USB ports.