Connecting i2c device on voxl2

Aaky

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

On a seperate note, Can I connect I2C device to this port 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?

modaltb

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

Aaky

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

Aaky

This post is deleted!

Aaky

@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? I have integrated new driver for PCA9685 from this PR into my voxl-dev fork.

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.

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.

Alex Kushleyev

@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

Aaky

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

Alex Kushleyev

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

Aaky

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

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.

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?

Alex Kushleyev

@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

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.

Aaky

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

Alex Kushleyev

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

Aaky

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

Aaky

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

Aaky

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

Alex Kushleyev

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