Forum Replies Created
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?
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….
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.
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.
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.
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.
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.
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.
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.
Shut down GCS, unplug board, then restart. I see that a lot too. I think windows gets “lost”.
Litterbug, just so you know, this is the branch with the Triflight algorithms. A few notes are in order. When auto tuning, make sure the dynamic yaw pids are set to one, it confuses autotune otherwise. Also, I’ve had better results not applying the yaw autotune values and staying with the defaults. Out of three copters, only one behaves well with the autotuned yaw. Curious to see how it behaves for you.
I won’t bore you with the ugly details, but suffice it to say that the F3FC with Dronin is sitting in front of me running fine. The gyro is responding correctly, and I checked each PWM output (all motors and servo) with a logic analyzer. Pulse widths and periods look fine, matching what is selected in the GCS. I don’t have any spare receivers to bench test with, but none of the updates involved the receiver code. Should be good to go. The installer for this version is at:
Delete any other installers you may have downloaded.
As far as I know the two boards are electrically identical, so it should work. I’m looking into a potential problem with the SPI clock setup, might have a solution there, hope to test it later tonight.
I did find a small unrelated issue in the GCS software for the F3FC target, so at any rate I’ll post a new link to the updated installer package either tonight or tomorrow.
Well I can only conclude that there is something wrong with the board I have, as I’ve looked at it from every angle I know and can’t make the Dronin code run without an MPU error. As I said, it used to work and we did get some flights on it.
This doesn’t entirely make sense to me since Triflight runs, and from what I can tell it interfaces to the MPU the same way.
If the opportunity presents itself, I’ll try this on another F3FC board.
It won’t burn out the board.
But I’d wait. I figured out how to build Triflight, and that code works, and it uses the MPU interrupt. There’s something wrong with the F3FC Dronin target, but I haven’t found the issue yet. I’ll update this when I’ve fixed it.
Well I borrowed a board to test with, but I think the MPU6000 interrupt line is dead. The firmware is throwing an error during initialization, and I’ve traced the error back to the MPU6000 interrupt line, the firmware is not seeing any interrupts from the MPU6000.
We previously flew this board with Dronin, so I’m pretty sure it’s a hardware error, not a software problem.
The only interesting thing is that Cleanflight reads the MPU6000 correctly, but I’m pretty sure Cleanflight does not use the MPU6000 interrupt. Can anyone confirm that?
At any rate, I’m unable to do any further testing with the F3FC and Dronin firmware.