Connecting i2c device on voxl2
-
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).
-
@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.
-
@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.
-
@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.
-
If you really need to try the periodic (standard, not OneShot PWM), i can add an option to use that.
-
@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.
-
@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!
-
@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.
-
@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 -
@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.
-
@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?
-
@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)
-
@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-ea38848f8580This shouldn't be M0065 problem right? Just wanted to eliminate the variables.
-
@Aaky, in your first flight, your actuator controls (thrust) was above 0.5 when vehicle took off:
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).
Also, your motor outputs are quite noisy, perhaps the flight board became loose after the crash, not sure.
-
@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. -
@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.
-
@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!
-
@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.
-
-
@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
-
@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 :
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)
This causes a sudden change in requested motor commands:
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