yeah, i thought about that… i am trying to keep chameleon to look like one, it is a pretty good looking frame, but, will need to think of something.
most likely i will use this:
https://store.mrobotics.io/product-p/mro-acsp7v10-mr.htm
and will need to solder in ESC feeds directly from it, like octopuses arms, will think about it…
I notice in the 1st photo you have the GPS pitched up at some angle but your COMPASS_ORIENT parameter is at 4 (Yaw 180). Is this what I’m seeing?
on other question from pictures i posted above - what orientation setting would compass in this gps unit need? arrow on the unit it facing forward. plate is about of 40-45% tilted. I would think yaw45, right? it refuses to work this way.
when it was mounted flat on the arm with arrow also pointing forward - it accepted yaw180 to be in line with internal compasses, also not clear why as actual chip on the gps board is aligned same way with compass chip on pixracer and dot - 1st pin is oriented same exact damn way. but, it was absolutely refusing to work with orientation set to 0 and i would see mag readings not to align in real time view on tilting it. it got workiing with yaw180 orientation, somewhat, but assigned very large offsets. The position where it is now is the best spot on this frame to get good gps signal almost immediately, so i do not want to move it anymore.
But, with 45% tilt of the plate under and presuming original yaw180 setting - what orientation would this thing supposedly accept? so far all attempts to use that compass generate red EKF with compass inconsistent cries, go figure what is inconsistent with what if it gets chosen as the only one to be used in the configuration.
it was sitting flat on the rear arm before very close to the frame - i just posted about that. with this pitch now - what orientation would it take?
No, Yaw 45 is what would be required if the unit was mounted flat and rotated in the yaw axis 45°. What you have is either Pitch 45 or Pitch 315 (assuming 45° from horizontal) not sure which. I would mount it flat.
no, there is no good spot on this frame to get it flat and make gps work well. i will see what gives, it is weird. will try to alter its orientation setting again and recalibrate, i am not sure anymore if internal compasses x-y-z axles and this m8q thing axles are aligned at all. it did not make any sense to have yaw180 set if forward arrow is aligned properly and chips seem to be sitting in same way 1st pin wise.
If it’s flat and the arrow is pointing forward you want Orientation 0 (default). I suppose you could use the current location and put a 3D printed angled block under it.
i know! but, when it was set like that, at least 2 axles in real view were changing in opposite ways - internal compasses axles would be decreasing with pitch/roll up and external compass would increase. i literally had to sit and jerk this thing around to understand what happens - did not make any damn sense.
just did some test flight - mount of rubber posts is inferior to previous one. at high speed it did not do alt jump yesterday, but does it today. will look at logs now to compare vibs to see where it is coming from now. it should not have had any.
I use these mounts and and on the 210 replaced the black balls with super compliant orange ones meant for camera mounting. Vibes are extremely low,
i deduced the issue! it was not the vibrations alone. it was the prop pressure into the baro at max braking.
so in addition to foam under the baro i now added strips of foam across all sides of a pixracer plate between copper and the FC. it solved this thing! and it flew great, well, compared to what it was. there is still a bit of a climb after the brake after the max acceleration in pos hold mode but it is normal.
overall it was very stable, this last test. here are logs.
https://drive.google.com/file/d/1cTsrOFtmS8pA-KqQXAOW3RtYoeWgy_g-/view?usp=sharing
It’s still chock full of EKF errors and some GPS glitches. You are asking for trouble. Just my opinion but I would disable both internal Compass’s and fix the orientation of the external one. The vibration levels are still high showing clipping on 2 axis.
you should have looked at the CURR reading at time of those EKF errors. it was stab mode torture going from max current in with subsequent drop from the sky and catching it mid-air with self-stabilizing.
like i said - it flew ok compared to what it was. should get better, eventually.
new wiring approach is needed. may be ESCs will go under arms.
As of now compass stability was fine based on what i see in circle test mode and rest of flying. i will see if i can make external one work - i do not disagree with you on that. for gps glitch an additional gps is needed but it also due to wiring rework, to find a good spot for second unit. any spot on arms right now is not working well at all for gps due to interference from escs and other components.
other issue i see in logs is a deviation from alt readings from baro to lidar, i need to figure that out, will try next time to do a video capture during test to see what it actually was at what time. green baro line below is way too delayed i think, not sure why, did i choke it with foam too much? drone was jerked up and down in stab mode there below. lidar cuts off at 10m - RFND.Dist1. Baro shows bogus…
Mike,
it is really difficult for me to understand this. I look at this chart - and in the sample here it took this model to go almost over whole football field to pick up enough speed to get this effect - at the mark 29 on this graph it picks up max speed, and then i give it full brake. GPS.Spd shows how it stops, at same time VIBE.VibeZ goes all way up. But before all that at mark 26 it shows normal loiter - on new props and new mounts all vibes are under mark 7 - as good as i can get it. What i do not get at all - vibeZ goes up at braking, understood, but, model starts climbing altitude even before VibeZ maxes out and clips out at value 30 - what drives this behavior? it begins at value 25 about time mark 29 1/3. It looks to be something specific for position hold logic, as i tortured this model in acro and stab mode to push it way harder and it was able to fly fine maxing out current on ESCs, with no such weird issues. Of course vibs do get higher as model pick up speed, there is nothing to do with that, but why it results in such a response as to give extra throttle and climb up?
I tried to play with filter values on gyro and accel, and ended up back with gyro to be at 80 and accel at 40 - it seems to show least amount of weirdness, but, it is still looking odd to me.
i admit i never had a chance to tune such racer small fast models, it seems to be very different from 800kv or 315kv heavier slow drones. i am trying to understand if there are any parameters that may affect this scenario and what factors contribute to this issue. it was a challenge even to get it into the air, thanks to Leonard who actually gave some advice here:
otherwise it would not even fly at all.
I do not expect arducopter to be a betaflight - but i can see how in stab and acro modes it is working acceptably fine, as i pushed this model to max current there and it responded decently enough, so this altitude jerk in pos hold has to be something caused by some code logic related to some parameters or filters, perhaps? vibes will raise with speed, it is a given. is there anything that can be done here or only solution would be to lower max speed for pos hold to tame it down and avoid those issues by reducing max speed?
logs here
https://drive.google.com/file/d/18NyTXkU9CshD1rxxq4dYhgBmhCLse22d/view?usp=sharing
also, in this log i posted, i really cannot understand - there is this message in log
MSG, 73204363, GPS Glitch
and then there is
MSG, 85072488, GPS Glitch cleared
i look in between those messages and i see perfectly fine working GPS unit providing messages.
what is the exact logic behing this "gps glitch’ message as i am lost what is in there to fix.
there is only 1 gps unit on this drone. what is this chart supposed to tell me?
And looking at this chart it also would be awesome to gain any understanding of why it decided to switch EKF while simply sitting on the same spot loitering on idle with no vibs and no inputs given.
if something is wrong there - what is it?
Have you autotune this frame setup?
Yes, no issues with autotune. It completes fine, sample was in posted logs.
Have our issues been solved? If solved what was the problem as I am facing it with my drone also. @Paul_Atkin1
OK, the uncontrolled full power climb is the result of excessive vibrations on the platform, if that is the issue you have.
you need to do better job on the vibration isolation, first, then, especially in case of a small platform or hard mounted controller - search and find how to setup an arducopter notch filter. i cannot recall now all the links as i stepped away a bit from this hobby - but if you search you will find all the required details. notch filter will most likely solve all the issues with this behavior unless your vibrations are totally over the roof.
