Dronin on Rcexplorer F3FC integrated board

[LitterBug]

I’ve used this laptop with GCS on 3 RE1s, a LUX, a DTFc, and a Seppuku with no problems. Just seems to be this one FC. I’ve had several versions of Triflight on this board, and it was flying last week. Tried unplugging the RX. My micro-minimOSD is hardwired, but not powered, so it should not be interfering.

Cheers!
LitterBug

EDIT> The standalone does not have a baro… that’s one difference between the boards…

[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.

[LitterBug]

Once we do get everything talking, is the Autotune and the Tailtune rolled up into the same process, or are they done independently?

Cheers!
LitterBug

[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

[LitterBug]

Downloaded and flashed. Initial results look promising. I’ll go through all the initial config tonight.

Cheers!
LitterBug

[LitterBug]

Baby tri is wired to the F3FC as follows:
Pad number 1 = Tail motor
Pad number 2 = Servo
Pad number 3 = Front Right motor
Pad number 4 = Front Left motor
UART1 = micro minimOSD
UART2 = DSMX RX
Voltage and current monitoring from BabyPDB

Input configured:
Throt DSM 1
Roll DSM 2
Pitch DSM 3
Yaw DSM 4
Mode DSM 5
Arm DSM 6
ACC0 DSM 7
ACC1 DSM 8

Have motors configured 125-250 PWM (oneshot 125)

Problems:
1)RX is briefly dropping out every two seconds. Makes it impossible to use input wizard
2)Frame type keeps resetting back to Quad X unless I save from the hardware tab instead of vehicle tab.
3)tricopter yaw motor channel keeps resetting to none.
4)Artificial horizon is inverted compared to board. (standalone f3fc pitch is 180 degrees different than integrated board) can only set pitch to 90 on attitude tab. (works with roll and yaw set to 180)

questions:
1) what PWM values for the servo min, max, center, and update rate for digital servo?
2) what PWM channels for the 3 motors and Servo based on the wiring above? (1,2,3 & 6?)

Cheers!
LitterBug

[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.

[LitterBug]

1) sounds good
2) The servo does not show up on the output tab too.
4) Setting Roll and Yaw to 180 does make the artificial horizon work correctly. Might be better if the GCS allowed pitch to be set > 90. Is a second place to configure board orientation a good idea?
5) will give it a try
6) Maybe @lauka or @RCExplorer–David would be able to clear this up. I’ll ping @lauka on the Triflight 0.6 RC1 in case he’s not watching this thread. In the Cleanflight based triflight, wiring the F3FC the way it is results in the servo being on Servo 5

# servo
servo 0 1000 2000 1500 45 45 100 -1
servo 1 1000 2000 1500 45 45 100 -1
servo 2 1000 2000 1500 45 45 100 -1
servo 3 1000 2000 1500 45 45 100 -1
servo 4 1000 2000 1500 45 45 100 -1
servo 5 1105 1975 1539 40 40 100 -1  <----
servo 6 1000 2000 1500 45 45 100 -1
servo 7 1000 2000 1500 45 45 100 -1

Cheers!
LitterBug

[lauka]

Do you need to manually map the outputs in Dronin?

Servo 5 is just what Cleanflight uses internally for the tricopter servo, has nothing to do with the pin mappings.

Please check these for the pin mappings:
https://github.com/iNavFlight/inav/blob/master/src/main/target/RCEXPLORERF3/target.h
https://github.com/iNavFlight/inav/blob/master/src/main/target/RCEXPLORERF3/target.c

Particularly this array definition:

const timerHardware_t timerHardware[USABLE_TIMER_CHANNEL_COUNT] = {
    { TIM3,  IO_TAG(PA4),  TIM_Channel_2, TIM3_IRQn,               1, IOCFG_AF_PP, GPIO_AF_2}, // PWM1 - PA4
    { TIM17, IO_TAG(PA7),  TIM_Channel_1, TIM1_TRG_COM_TIM17_IRQn, 1, IOCFG_AF_PP, GPIO_AF_1}, // PWM2 - PA7
    { TIM1,  IO_TAG(PA8),  TIM_Channel_1, TIM1_CC_IRQn,            1, IOCFG_AF_PP, GPIO_AF_6}, // PWM3 - PA8
    { TIM3,  IO_TAG(PB0),  TIM_Channel_3, TIM3_IRQn,               1, IOCFG_AF_PP, GPIO_AF_2}, // PWM4 - PB0
    { TIM3,  IO_TAG(PB1),  TIM_Channel_4, TIM3_IRQn,               1, IOCFG_AF_PP, GPIO_AF_2}, // PWM5 - PB1
    { TIM2,  IO_TAG(PA1),  TIM_Channel_2, TIM2_IRQn,               0, IOCFG_AF_PP, GPIO_AF_1}, // PWM6 - PPM
};

PWM1 (PA4) is Motor 2 (left)
PWM2 (PA7) is servo output
PWM3 (PA8) is Motor 1 (back)
PWM4 (PB0) is Motor 3 (right)

[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]

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….

[LitterBug]

Thanks @lauka and @jihlein,
Flashed the latest fw_f3fc.tlfw and the RX inputs are solid now. Reconfigured PWM channels similar to your pictures above. Props are off and getting ready to apply battery power to calibrate ESCs, and stationary Servo tailtune. Weather actually looking decent compared to the forcast, so I may even get LOS, autotune, and inflight Tailtune… (fingers crossed)

Cheers!
LitterBug

EDIT: Motors and Servo check out fine. Servo responds to yaw even when disarmed.

[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?

[LitterBug]

Set 40degree endpoints and 0degree center for the servo in the output tab. Selected tailtune mode and pulled back elevator, but no speed measurement was done. Where do I configure the servo feedback to enable the speed measurement?

Cheers!
LitterBug

EDIT: found it RSSI –> ADC RSSI
But it is still not doing speed test. Maybe need to set endpoint values for that?

EDIT2: Missed the UAV setup. Looking at that now.

[LitterBug]

Double checking the UAV settings:

Cheers!
LitterBug

EDIT: DOH. Had elevator channel reversed. It did something, but didn’t update the speed. Think it exceeded the endpoint value and dumped out. Gave five beeps.

Attachments:

1. 

   dRoninTriFlightUAV.jpg
   

[Author]

Posts