New FIMI Manta VTOL Fixed Wing

All,

A quick clarification question, if I go to Motor Test tab, and test all motor in sequence, should the front right motor spin first, then the front left motor spin, then the last motor in the back spin? What does sequence mean? Should the front right motor spin first, then the back motor, and then the front left motor?

Thanks,

You should upload .bin log file instead of .log file. I checked both files, can see params but log analysis tool does not show detail with log file, cannot see how it behaved.

Looks like you are not sure on motor order? Since Manta is small, you can hold it by hand, arm in QStablized mode, gently apply power and observe how it behaves. Once Manta is self stablized agaist pitch and roll, you can check RC control is working fine as well.

Motor order is motor1 front right, motor2 right and motor4 rear. I can see you have set them in the log, but cannot know which motor they are connected.

I flew Manta a few times till crash this weekend. :grinning:

I agree with @Rolf Manta is far from complete and not safe as PNP. It is a ok built kit with starting point parameters to tune. At least it is good kits have same build, motor and servo so that stability parameters can be common. Mine has SpeedyBee F405 Wing, 20A ESCs, matek m8q-5883 GPS. Fuselage space is tight and I have not fixed everything well yet, lots of tape. AirSpeed is installed but not enabled yet.

This is the third flight after checked stability in QStablize mode well and tried a few transitions. Switching between QStabilize and FBWA, QLoiter in the latter part, a bit windy 2m/s or more. Stabilization is a bit too much, I can see vibrations in both Q and FBWA.

Log of this flight

After a few flighs, Manta got into a state messaging failing to transition to FBWA, repeated to try transition. Tried to transtion back to QStabilize, flipped and crash. I do not fully understand what happened in this log
Fortunately damage was minimal. One motor arm is bent but was able to straighten using vise and pliers.

Hi Satoru,

Good that you were able to repair the damage.
I suspect that the chain of causes for the crash begins with the fact that no compass is installed.
Therefore, the calculated airspeed is always set to zero when the aircraft is objectively moving backwards (in Q mode), but the missing compass causes the heading to point incorrectly backwards, which logically sets the airspeed to zero.
It’s best to check it out for yourself at UAV Log Viewer.


CTUN.As
CTUN.As goes to 0 several times in the Q-modes, always when the heading was calculated backwards incorrectly due to the missing compass.

During the transition to FBWA the error of the 180° twisted heading is noticed and CTUN.AS shows realistic values again.

Why this was not recognized during the last switch and the synthetic airspeed remained at 0 I cannot say. This goes beyond my Arduplane knowledge. However, I am sure: With compass this would not have happened. I think the compass is even more important than an airspeed sensor.

I have a few flights behind me now. The aerodynamics are great, at least a compass belongs in it to be able to start safely in windy conditions or to fly in a Q-mode and from the manufacturer the parameters are partly a disaster.

I realistically expect a safe VTOL flight time of 30 minutes with 3s 21600 LiIons.
Rolf

Hi,

Here are the Bin files to my motor issues: 2023-10-01 15-34-32.bin - Google Drive

log file

I think the motor setup must be M2, M1, and M5 in that order. Any other order does not work. Probably my setup, the motor is backwards.

For example, here is my connection
Channel 5 - ESC4
Channel 6 - ESC 3 - Left wing motor
Channel 7 - ESC2 - back motor
Channel 8 - ESC1 - Right motor

Channel 6 is M2, Channel 7 is M4, and Channel 8 is M1.

When I press motor test Motor A, front right spins. Motor B, front left spins, and Motor D, back motor spins.

I think the setup must be M2 M1 and M4. Any other combination, it doesn’t work. Can you please confirm?

Thanks,

Hi @Rolf thank you so much for looking into the log. I have a compass (matek m8q-5883) aligned, but it may have taken a few try to arm on that flight. I will check.
I learned a lot on log analysis with tailsitter VTOL last year but tilt is new to me.

Thank you for bin log. I can see Manta rolls over as soon as you apply throttle, while plane does not want to do so (ATT.DesRoll stays 0) So right and left motor may be opposite.
It does not matter how motor is wired at 4in1 ESC, no need to change connection. you can change motor assignment at Mission Planner Servo Output screen.

A few general questions about bench testing.
I noticed someone has a issue when USB connected to use Adrupilot and battery was plugged in. I assume that was a unique issue.

Is there any reason you can’t plug in the USB and battery at same time to do bench testing?
Is it okay to use a 3s or 4s lipo for basic testing while I wait for a 3s1p.

Thanks for the log review and comment.

Hi @dasjlm, no problem to connect USB while Battery plugged in, and it is needed for some calibrations. Depends on FC design, USB will power only FC itself and external sensors/GPS, TX, not servo or ESC.

Thanks Satoru_Sasaki. I just wanted to make sure there was no issues. I assume the guy that had the problem had some kind of short.

Anyone get SBUS to work with the Manta’s fight controller. I’m using a FLYI6X transmitter with output set to PPM/SBUS. I soldered the wires to the SBUS pads on bottom of flight controller and changed the settings per the special instructions. I used a new plane definition on the transmitter and did a bind.

When I connect the flight controller to adrupilot on my laptop the flight controller blue light flashes an red light on receiver is solid on which I believe is correct at this point. When I do a connect via ardupilot I can read the parms okay so I know AdruPilot is communicating with the flight controller. But when I try to calibrate the radio none of the controls I move change the screen so I assume the receiver is not detected by the flight controller.

So just wondering if anyone else had any luck with SBUS and FLYSKY as I think I have everything set up correctly and I double checked the SBUS connections.

Any suggestions on how to troubleshoot?

Did you get SBUS to work after you soldered it to the SBUS pads?

Make sure your receiver is correctly outputting SBUS and not PPM
The special instructions for using the SBUS receiver seem to be incorrect.
SERIAL6_BAUD 115 is right!
SERIAL6_PROTOCOL -1 is right!
BRD_ALT_CONFIG 0

SERIAL4_BAUD 115 is wrong!
SERIAL4_PROTOCOL -1 is wrong!
BRD_ALT_CONFIG 0

Yes- at least according to MIssion Planner.

image

This is what I am seeing in MP, and the Mission Planner is showing proper movement on the setup screen? Actually now I am confused…Are you sure about Serial 6 not 4? Protocols make no sence as 42 is DisplayPort, so how is MP showing stick movement? I didn’t try Serial 6, Serial 6 is how it is from factory.

I tried settings up SERIAL6 as suggested but didn’t help. Interesting they had SERIAL6_PROTOCOL set to 23 and it is not listed in AdruPilot. I did sent note to FIMI support. I’m hoping they have some FLYSKY SBUS experience. The FlySky i6X transmitter allow you to set receiver output mode.

It gives you the option to set the receiver output to

PWM and serial to i-Bus or S.BUS
or
PPM and serial to i-Bus or S.BUS

I’m new to ArduPilot so it’s all a bit foreign to me at this point as this is the first time I tried SBUS. The transmitter I have is suppose to support SBUS and the ia10b receiver is suppose to support SBUS. According to FIMI all I had to do was solder the SBUS wires to the SBUS pads on the bottom on the receiver and then change the settings. But always seems to a trick. Hopefully someone has got the Manta FC to work with an ia10b and SBUS and can let me know if there is another step. Anyway that’s for your suggestion. If FIMI comes up with something I’ll post it.

Took a second look at the Serial_6_PROTOCL and it is 23 with is RC IN. I assume set by FIMI. That makes sense as they have solder the SBUS wires to the SBUS pads which according to their diagram is serial 6.

So I think they want the SERIAL4_PROTOCOL set to -1 to indicate it is not used.

Anyway looks they want me to take a video and pics so guess I’ll have to go thru things step by step tomorrow. My only fear is they’ll come back and say it’s a FLYSKY problem.

SERIAL4_PROTOCOL 42 seems strange? Do you have a cable plugged in it.

Did you connect SBUS via cable to SERIAL4 or solder to the SBUS ports? I was told to solder it to SBUS pads on bottom of FC.

Serial_6_PROTOCL 23 It is used by default for crsf protocol devices, such as ELRS. I confirm that it is set according to the method I told you, because I am also using an SBUS receiver, so you have to confirm again whether your receiver is outputting correctly SBUS signal
SERIAL4_PROTOCOL 42 It is the default interface for high-definition image transmission, so this setting is correct
You can view your joystick output under the mission planner

Glad to see you have it working. Not sure if FLYSKY is causing issues. What transmitter/rec are you using?
. I will try again tomorrow as I kind of burt out tonight. Thanks.