17 April, 2019 at 08:59 #61529
@jihlein I have a Matek M8Q-5883 and it works perfectly, both GPS and mag. The only problem is, I couldn’t get any RTH or anything associated with navigation working on dRonin, it complains about configuration and modules and does not let me arm. If you can give a step-by-step instructions how to set it up I would gladly take my tri off the shelf where it landed in favour of iNav quads…
PS I used this guide with no luck: dRonin User Guide: Preparing for Navigation The errors were (paraphrasing): “no path planner module enabled and a path follower module is” and then “path planner enabled with no path follower” when I took the advice. I had the VtolPathFollower enabled as per the instructions, than tried turning on PathPlanner as well.
PS2 Does running the mag_calibration.py script have any significant benefits? It seems a hassle…17 April, 2019 at 14:23 #61532
@frederoo – remind me which FC you are using again….
From memory, you need to enable the Path Planner and VTOL Path Follower modules, and set the navigation algorithm (on Attitude->Filter Settings pane) to INS. GPS will need at least 7 satellites if I recall correctly before the system will set the home point and allow the attitude filter to run properly and the system to arm.
A good mag calibration is important for good navigation results. I’ve not looked into the details of the mag_calibration.py script, I’ve got some of my own tools/routines I use for that. Probably should look at that script…..
I had position hold mode working fairly well quite some time ago, but got sidetracked with other things. Never graduated to return to home, so that’s were I’m going to start poking around again once I get this mag issue sorted out.
The KakuteF4V2 is the first board I’ve used that seems sensitive to the SDA/SCL pull up resitor values on the external mag. All the gps/mag units I tried with the KakuteF4V2 work with other boards, AQ32, F3Fc, Matek405Std, even my Raspberry Pi and Beaglebone Blue boards. I have another unit coming tomorrow that will accept either 5v or 3.3v power, going to give that one a try and see what I find.17 April, 2019 at 14:57 #61533
I have a Kakute F4 v2 AIO, so I assumed the same you are writing about.17 April, 2019 at 15:32 #61536
Subtle difference – I’m using the non AIO version……wouldn’t think that difference would cause any issues. Encouraging to hear you found a unit that works.17 April, 2019 at 17:52 #61537
@jihlein, thanks for having a glance over my outputs tab, as well as helping me fix my mixer settings. Everything seems to be working now.
Took the V4 out last night and this morning, and completed AutoTune and ServoCal. I noticed that with ServoCal, that when I enable it, I hear it start beeping a few times, but I never hear the “ServoCal completed” tones that we used to hear back on betaflight. Is this normal? It has done at least something as my MotorThrustFactor is now 30.6957. Does this seem like a reasonable value for the V4?
Jesse17 April, 2019 at 18:32 #61538
I’ll have to check my V4, but I believe your thrust factor is in the same range as mine.
The beeps are different from Betaflight, and I’m making a change to simply them. The in air servo cal aims to take 500 data samples. It currently makes a single short beep after every 100 recorded samples. After landing and disarming, I’m going to have it emit 2 long beeps, pause, and repeat until ServoCal mode is exited for passing the calibration, 4 long beeps, pause, and repeat for failing the calibration.18 April, 2019 at 04:53 #61543
@jihlein, sounds good. I think that the extra beeps will make it a more intuitive user experience.
I am out and flying, and that’s good, but I’m noticing some very strong yaw oscillations during high-throttle punch outs. Not even jamming it full-throttle, and then cutting it off, but even just steadily raising the throttle to 100% and then backing off relatively slowly. Its seems like whenever I get in the 80-90% throttle range the tail servo starts wagging rapidly and gets worse the more I raise the throttle.
I was reading David’s tuning tips on the first post of the thread and after reading, I set YawBoost to 0 and DynamicYawMaxThrottle to 0. Previously they were both set to 1. I then went flying again. Strangely, it doesn’t seem like either of these changes made a real significant impact (if any) on the V4’s flight performance. I then went looking again for parameters that seemed strange, and I did notice that the Yaw PIDs from AutoTune do look a little odd. I have zeroed out the D gain on Yaw as was suggested by David’s video, but the I term seems huge. Perhaps this is contributing to the overly-active tail?
Any tips would be greatly appreciated, and please see the attached screen-grabs of my TriFlight and PID settings.
Attachments:18 April, 2019 at 14:23 #61552
I’ve noticed the same, not sure what is going on. I’m working on some changes to record telemetry to see if I can figure something out. The Yaw I does look high, I’d try manually reducing that some.
There is also a UAVO, ActuatorSettings->MotorInputOutputCurveFit, that can be used to help with high power instability. It defaults to 0.9, you might want to try 0.85 or 0.8. I’ve read reports that this helps high powered quads, I’ve not yet tried it on my tricopters. My tri’s are not overpowered, I’m running 3s on all of them FWIW.18 April, 2019 at 15:03 #61553
@wynnsquad From my experience with Tri’s, not only do the D’Terms need to be zero’d but the Yaw P and I terms need to be lower than those of the Roll. Reason being, is that when the Tri Yaws it induced Roll in the opposite direction. Having a lower Yaw term allows the copters Roll to compensate faster than your rate of Yaw. Beyond that when the Yaw does change, it doesn’t do so aggressively and thus should reduce the amount of wag. This of coarse assumes that your Servo is running smooth, using 6 + Volts and that your Tail Mechanism isn’t misbehaving. (Loose zip-ties or Sloppy response)
Side note: The Tail not only controls Yaw but to some degree, Pitch as well.20 April, 2019 at 04:13 #61568
Okay, I have the new build complete and have started flight testing. Tonight, I was able to setup from scratch and test fly my Baby Tri with the F3Fc, and V4 Tri with MatekStd. The testing covered basic setup, on ground ServoCal, AutoTune, apply AutoTune gains, in air ServoCal. Test flew Arco, Leveling, Horizon, LQG Rate, LQG Attitude, and LQG Horizon (new mode in this build). This was in the confines of my back yard, so nothing radical. Both vehicles performed very well, all tunes completed on the first attempt.
There’s a lot of changes from the previous release.
1)All three boards (F3Fc, KakuteF4V3, Matek405) are now navigation capable, supporting external HMC5883 and HMC5983 magnetometers
2)On ground ServoCal limit checks relaxed slightly, should complete now in those few cases that were previously failing
3)In air ServoCal calculation bounds increase slightly, V4 doesn’t need much trim and was right on the edge of failing
4)ServoCal beep tones. At the end of the calibrations, 2 long beeps repeating indicates pass, 3 long beeps repeating indicates fail. The in air calibration should beep 5 short beeps, one after every 100 samples are collected. These 5 short beeps may or may not be periodic, depending on vehicle motion and stick inputs.
5)External mag senor handling is improved, firmware will still run but throw an error if the sensor is selected but not detected (not installed, not powered, etc.) In the case of the F3Fc integrated and racing, the racing board will need the Tolerate Missing Sensors UAVO set true. The sensor status block will be yellow, but the controller will still arm and fly normally. The same is true for the Matek405Mini. This is due to some variants having an on board baro chip, some not.
5)IMU setup has been simplified, alternate DLPF settings and ranges removed and these settings now default to those that have shown the best performance overtime.
6)The KakuteF4V2 now can make use of the on board SPI Flash for logging. To use this feature you will not only have update to the new firmware, but also perform a one time update of the bootloader.
7)The triflight routines now support both CW and CCW rotation of the tail motor. I flew the Baby with CCW, the V4 with CW.
While my V4 is setup for navigation, I won’t get to check that out for a while yet. I also need to try the KakuteF4V2 load on my BiCopter, and Mini Tri if I get that completed.
So there’s a bit more testing to be done before I create new install files, but I’m getting close. I will likely create the installers before I try testing the RTH functionality.20 April, 2019 at 09:43 #61569
Man you’ve been a busy bee. Thatnk you for everything mate. We’d still be using Betaflight if not for your efforts!
And oh yeah, happy Easter!
Side Note: Will pull my Baby-Tri out and give it the full monty using the latest Firmware.
Kevin25 April, 2019 at 19:53 #61611
I apologize in advance if this has already been asked, or if there’s an obvious reason why this is a dumb question: is there a reason we can’t use the UART 5 as the second feedback pad on the Kakute v2 board instead of UART 4? That would open a full UART for GPS or camera control since UART 5 is RX only anyway? And for those who want to use ESC telemetry, you would have the option of putting it on UART 4. Just a thought. Again sorry if the answer is obvious, I don’t know enough about the inner workings of the boards…25 April, 2019 at 20:12 #61612
Uart5 has no TX pad, at least none that I’ve found, so that’s why it’s semi dedicated to the ESC telemetry.
I’m planning on returning Uart4 to full functionality shortly. With ESC telemetry now available, current can be received via that interface, freeing up the current pad for use as a 2nd fdbk if required, thereby freeing up Uart4 RX for it’s normal use..
I’m probably the only one using the 2 fdbks on the BiCopter, and it’s just for telemetry purposes at this time.25 April, 2019 at 21:31 #61613
Yeah, a bunch of boards did that, exposing just an RX pin for ESC telemetry but not the TX pin to save space on the board or whatever.
I would respectfully request that you not take away the current sensor pin since that’s how I like to track current using the PDB, but I guess that’s an option, too. Switching to UART 5 would allow maintenance of all features as they are now, other than requiring swapping the second feedback and ESC telemetry (if used), while also turning UART 4 back into a full UART for whatever purposes are desired. Just my two cents. Again, I have no idea of the technical challenges of one solution vs. the other, so I understand if that’s not a practical change.26 April, 2019 at 04:19 #61615
The current sense pin will remain as an analog input, user can decide how to use it, current sense, servo fdbk, etc.
You must be logged in to reply to this topic.