Connecting i2c device on voxl2

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

Aaky

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

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

Alex Kushleyev

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

Alex Kushleyev

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

Aaky

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

Alex Kushleyev

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

Aaky

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

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

Alex Kushleyev

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

Aaky

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

Alex Kushleyev

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

Aaky

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