Regarding this I tested latest master on OmnibusNanoV6 and I get not so good log, I can read it with APM Planner 2 (with some error), Mission Planner say there are no FMT messages and with mavfft_isb I get a lot of bad header 0x00 0x00 at 255
and Skipped 44 bad bytes in log at offset 19929, type=(163, 149, 155) (prev=177)
but in the end I get the plot.
Ouch, this is probably a conflict between the FFT and logging threads which I have also seen. I need to dig into this a bit more as it only just started happening.
The log posted above comes from OmnibusNanoV6 with master built without DSP (the default for this board) so I donât think that problems comes from FFT.
Ok, thatâs pretty bad - the work I did on logging was designed to avoid this situation. Are you able to replicate the problem? Are you able to identify a commit that made it worse?
Have a look at the DSF messages (if you can) they will tell you how logging is getting on.
@anbello I have pushed a change to my small copter branch that might help. It seems to get rid of the logger thread died messages and may help with your logging also. It does however make the FFT priority the same as logging so I am worried that on an F4 you might not get enough updates. It seems to work ok on my F7.
Tested latest small-copter-4.1 on my 3 inch quad with OmnibusNanoV6 and I get complete logs that are red without errors by Mission Planner, APM Planner 2 and mavfft_isb, both with FFT_ENABLE=0 and with FFT_ENABLE=1. Good!
The only strange things I see is a bad baro behavior on take-off and landing, but I donât think that this is due to your last logging PR. I attach a plot with baro going to -4m on take-off and landing. Perhaps the foam above the barometer has shifted and is taking air from the propellers.
Hi all,
has anyone used the S.port telemetry Frsky protocol on the Omnibus nano V6.0?
I connected an RX jumper r1 + with S.port output to pad TX1 on the nano v6 (as indicated on the schematic on the wiki so it would seem to support s.port) but it doesnât seem to work.
The RX itself works fine on a kakute F4 (unfortunately 30x30 not good for 3" quad).
Anyone put Ardupilot on a Cinewhoop? I want to fly it with a 4S LiIon and the trouble with Betaflight is it really is hard to fly it with the serene throttle management required to keep current under 20-25A. Alt Hold will really help as I can remember â I use Plane now and have not used Arducopter since APM 2.6! The use-case is to use a it with a Naked GoPro Hero 8 for slower cinematic passes. Anyone have any input here?
Well, weâve all put ArduPilot on microcopters with cameras - I think it will work really well. It requires some tuning and its really important that you use the harmonic notch, but I think you will have a good experience. The tuning wiki page covers smaller copters as well and is a really good starting point.
Oh indeed. I have been watching your work. Amazing stuff. How does it relate to Betaflight? Are they adjusting notch filters? Missed that. I mean I usually flash and fly with minimal tuning. I am no betaflight guru and I am not a racer. Are we ready for some presets for 3,5, and 7 inch quads?
They have notch filters on by default. I think we could get there but it probably requires further work. if the FFT code in 4.1 was smaller we could have that on by default, but ts a chunk of flash and we are short of flash.
To get good performance on a cinewhoop with AP you will need to tune - but just follow the guids and you should be ok.