[jihlein]

Same stuff, just wrapped in a single package now. No need to change what you have loaded now.

[jihlein]

I’ve deleted all the previously posted links and replaced them with this one:

https://1drv.ms/u/s!Am7KDquQANJl5j_Au3Dy-BtTUPFd

It’s a complete Dronin installer with the latest flight firmware for the F3Fc. It’s based off this repository:

https://github.com/jihlein/dronin/tree/myNext

[jihlein]

FYI – That discussion was about my original beeper implementation (which admittedly was a hack, but I needed something to test with). I’ve re-based to the Dronin buzzer infrastructure so those concerns have been addressed.
Another way to tell if the tail tune completed (after the fact) is to look at the motor torque constant. Its default vaule is 13.8, and in my experience to date, the smaller airframes will compute a a lower number. See if that value has moved from 13.8

[jihlein]

Link to PR:

https://github.com/d-ronin/dRonin/pull/1054

Link to discussion thread:

https://github.com/d-ronin/dRonin/pull/1054

[jihlein]

@LitterBug, I doubt the tones are the same. Here’s a map of what I setup:

Open to suggestions if you find this confusing. Only requirement is standard morse characters.

I found I was on the sticks less doing the inflight portion of the tune in rate mode, but if that turns out to be problematic for users, I can easily change it back to attitude mode.

@unseen, regarding Linux, no easy way at the moment. There is a PR open for the triflight algorithms, which thru the automated server can be built for Linux, but that build won’t include the F3Fc target. The only place the triflight algorithms and the F3Fc target exist together is my development branch. If you setup the Dronin Linux build environment, you could clone my development branch and build a Linux version.

Regarding the PR, please feel free to comment on your experiences there, good, bad, suggestions. I know the main Dronin developers are somewhat lery/doubtful of the benefits of the direct servo feedback, so users posting their experiences/evaluations would be helpful.

Edit: And why don’t my image links display??

[jihlein]

In Dronin, I change all the triflight calculations to floating point. Doesn’t work on F1 targets, it’ aimed for the F3’s and F4’s with the FPU.

[jihlein]

Set DynamicYawMinThrottle to 1, thought I had that defaulting to 1.

Disable the virtual servo.

There’s also a TriflightStatus UAVO further down that will monitor the state of the algorithms and display some of the computed parameters.

[jihlein]

That’s all good.

Yaw does respond when disarmed, that’s normal. WRT the board orientation, even if you could change the pitch orientation, you would still have to change yaw. Do to the way the math normally works, to invert the board you would change roll and yaw, so we’ll leave that as is.

Setting up triflight is a little different. You use the output pane to set the servo limits and neutral. The stationary tailtune only computes the servo speed. Switch tailtune mode on, and pull elevator stick back, and it will calibrate.

Did the setup of the triflight parameters in the uav browser give you any trouble?

[jihlein]

Here’s the vehicle configuration page for the F3FC:

And here’s the output configuration. Note sync pwm for motor channels, 270 Hz for tail servo. The tail servo min/neutral/max numbers are nominal, they haven’t been calibrated for an installation.

Edit – Not sure why images won’t display in the forum text, right click and display in new tabs works….

[jihlein]

Here’s a link to the firmware with the RTC correction, hopefully this settles down the receiver inputs. This is the board firmware only, not another installer.

https://1drv.ms/u/s!Am7KDquQANJl5j4MAtuai3tgp3up

Regarding the channel mapping, yes, Dronin lets you map the outputs. From an RCE board point of view, it appears the silkscreen output numbers don’t match the order in the software, and that’s where I got confused.

A tricopter, in Dronin, allows you to specify the output channel for the NW(left), NE(right), and S(rear) motors, and the servo. I simply defined these as channel 1, 2, 3, and 4 respectively. From the channel mapping info Lauka provided (thanks!!), this order should work on the F3FC racing board, as I know it works on the F3FC tricopter board.

The update rates for the motors and servos are completely independent this way, so you can set the motors to synchronous PWM and the servo to what ever update rate you need, 50 Hz (default) for analog servos, whatever you require for digital.

[jihlein]

1)I inadvertently left one clock configured for a 12 MHz oscillator, this board is using an 8 MHz. That might fix the dropouts. I’ll rebuild for that.
2)Known bug in GCS. I don’t know the GCS code, so need to live with this for now unfortunately. There is a problem report written against this.
3)Only a GCS display bug. I think you meant the yaw servo channel. Same issue as #2.
4)Forgot about this one. So if you set roll and yaw to 180, is pitch responding correctly. Not an ideal solution, but I could add a selector the hardware config page to set the board orientation. What do you think?
5)For digital servo, I typically use 270 Hz, and with that rate the PWM values will be in the 1000/1500/2000 range.
6)I think you’ve wired yourself into a corner here. You have outputs 1 & 2 controlling the tail motor and tail servo. But those outputs share a timer, and the PWM rate will have to be set to 270 Hz. It would be best to have the motors on channels 1, 2, and 3, where the PWM rate can be set to sync. Channel 4 has it’s own timer, and run the servo from there and set it to 270 Hz rate. This all assumes that the channel order on the racing board is the same as the tricopter, which is what this was derived from. I don’t know what the recommended output order on the racing board is.

Edit – just looked at the board on the website. Looks like you’ve got the recommended wiring. Wish we had a board schematic. You may have to hunt around to find out what channel controls what motor/servo, and hopefully that will end up with the servo on an isolated timer bank.

[jihlein]

They are independent. I usually do the static on ground tailtune first, followed by the autotune. Then apply the autotune values, then do the airborne tailtune. Remember to set the dynamic yaw values to 1.0 before running an autotune, and don’t apply the yaw autotune values, at least at first. I’ve had high freq vibrations in yaw with the computed values, default have worked better. I’ve not tried manual tuning yet. Even while working a tuning manually, I’d make sure the dynamic yaw values are at 1.0.

Here’s another run at the code. I added the ability to enable/disable the baro. If it’s enabled by mistake, the board will signal a bad sensor, but continue to run, allowing you to disable the baro and reboot. The baro is disabled by default.

This is certainly easier when I have the target hardware, but I think this version will run. Famous last words….. 🙂

Delete the prior install, it’s a whole new package.

https://1drv.ms/u/s!Am7KDquQANJl5j1HZiBrx1YMKPOp

[jihlein]

It’s the lack of baro. I configured my build to use the alternate i2c address of the MS5611 so it would not respond, and got the same lock ups you are experiencing. Back to normal i2c address and it’s back to business.

The define for tolerate missing sensors is there, I’ll look into why it’s not functioning that way. I’ll also make a build without the baro and post that.

[jihlein]

If the settings are erased, and it still won’t connect, I wonder if a driver did not load properly. I’ll look into what drivers need to be removed to force a reload. That’s the only thing I can think of at the moment. Weird.

[jihlein]

What happens if you go to firmware, hit rescue, then plug in the board? Is it recognized as the F3FC?

If it is, right click on the settings papartition and select erase. Then press boot and see if it connects.

[Author]

Posts