Connecting i2c device on voxl2
-
@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.
-
A Alex Kushleyev referenced this topic on
-
@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
-
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..
-
@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.
-
@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
-
-
@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?
-
@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 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 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.
-
@Aaky , i will be back to office on Wednesday and will follow up with replies to your questions.
-
@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:
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?
-
@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.
-
@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?
-
D Denver Bennett referenced this topic on
-
@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?
