Okay, can I just as well set the servo trim, or does that affect something else I should be aware of?
. . .
Also, where might I find the feed-forward data due to the Col2Yaw input?
couple of things at first sight:
- correct RPM scaling, youâre running around 1333 rpm HS, while the RPM reports half of that.
- I see you are using GPS for yaw, but there is something not right (270degs offset) :
when you connect to MP, does the heli icon nose point in the same direction of the real heli?
Yes, the heli icon points in the same direction as the real heli.
. . .
I calibrate the compass before performing the 3D accel recalibration. I did not do another compass calibration. Could that have something to do with it?
. . .
I have uploaded my parameter configurations here. One just before the parameter reset, which contains 3D calibration setting with flight controller on the bench (E1 900, Pre-tracking test.param). Second, is the parameter configuration after 3D recalibration in the heli (E1 900, ReCal and First Hover).
Maybe there is some evidence here if something went wrong during recalibration.
. . .
Similar issue here?
. . .
Looks like I should go recalibrate my magnetometer, and see if that resolves the ATT YAW problem.
. . .
Yeah, check out my GNSS mag (at least I think this is the GNSS mag in orange). The GNSS does sit right next to my main current line. I should just disable the internal magnetometer so it doesnât mess with the system.
Not sure why the ATT.Yaw was off from the beginning though.
Yes, it is the CUAV C-RTK 2HP. ANT1 is set as the main antenna (right side of heli), and ANT2 as the slave (left side of heli).
ESC_CALIBRATION
Any reason I should not adjust this parameter manually? My system has been in ESC_CALIBRATION = 3 for a while. I have already performed calibration outside of ArduPilot. The parameter says not to change it manually. What is the reason?
I have uploaded a more recent flight log. After disabling the GNSS internal compass, and recalibrating the Nora+ flight controller compass. Still seeing the same offset between ATT.Yaw and GPYW.RHD
Flight log is â2024-06-13 16-36-53-anon.logâ
No, donât do that as you are using compass fallback. Best thing to do is to relocate the unit in a more suitable position away from main power lines.
I had a look through the code, the âreported headingâ is not used as is for yaw, it is corrected by the rotation offset. So the data in your logs are correct:
Thank you for looking into the code!
Why is there an offset? The GNSS unit and the flight controller are both oriented facing forward. Is the offset caused by the disrupted yaw magnetometer in the GNSS? (Disrupted by my close power line).
Because the value logged is before the offset rotation calcs are applied. It is a bit misleading in my opinion.
In MP you can enable âgpsyawâ to read the corrected heading value in real time.
Starting to dial in the manual tuning parameters. even with the low head-speed of the E1 900, as compared to the Trex 450, the D parameter is still very small. Seems to be proportional to the head-speed. For the Trex, I had set the Pitch/Roll D parameter as 0.00037. Head-speed was about 2600 RPM. For this E1 900, the head-speed is about 1400 RPM, and I dialed in about 0.0008 for the Roll/Pitch D parameter. Might want it a little lower still, like 0.0007 or 0.0006.
Log is uploaded as 2024-06-14 10-59-24-anon
In setting the Yaw feed forward, it is not clear what units the ATC_RAT_YAW_FF are in. The tutorial explains to divide the average RATE.Yout by RATE.Y in radians. Does this mean I need to convert RATE.Y to radians first? Or just simply divide RATE.Yout by RATE.Y to get the FF value?
To simply divide, I get 0.08/162.85 ~= 0.0005
Derek
RATE.Y is given in deg/s so yes you need to convert the 162.85 deg/s to rad/s. This comes out to 2.84 rad/s. So doing the calculation for Yaw FF you would get 0.028 which is pretty close to the default value. Typically yaw FF is small if not 0. you rely mainly on the yaw rate P gain.
Completed manual tuning (2024-06-14 22-16-56-anon). I may have entered a higher-than normal P-gain for pitch and roll. Seems pretty rigid. Thatâs good from a control system standpoint. I would like to have a smoother, more gradual control. I suppose that is where the ATC_ACCEL_x_MAX parameters come in. I will reduce these to a recommended acceleration for a 900 size heli. I am starting with reducing from 110 000 down to 50 000 for pitch and roll.
There is also the ATC_INPUT_TC. I am changing this from 0.15 to 0.2.
Iâll add a little expo to the controls as well.
Also wondered if it would be right to reduce the ATC_ANG_x_P. These are currently at the default 4.5 value. It appears that the helicopter has some slow pitch and roll oscillations due to FF and I gains when holding position in a hover. Maybe this is normal, but it looks like the oscillations could be reduced. It does not appear to be oscillating visually, but the data shows oscillation.
Derek,
Personally I would not mess with the ATC_ACCEL_X_MAX. Leave those at the 110000. Those limit accelerations regardless of the input size. The feel really comes from ATC_INPUT_TC in the stabilize and althold modes. This will limit accelerations based on the input size. I have found that ATC_INPUT_TC value of 0.2 to 0.25 to be very nice for flying. I just tuned up a Trex 700 and have 0.22 on it. As for angle P, I donât generally recommend lowering that. I would use autotune to see where you are at with the rate loops. I found with my 700 that it had a lightly damped pitch axis which required some special filtering to reduce the overshoots. If you are not looking for a super fast heli and just want it to fly nice in stabilize, I have a recommendation for the filtering that would help. I also would not recommend change expo until you have adjusted the INPUT_TC.
1 Like
@bnsgeyer Bill, that would be nice to go over the filtering. I do have some very fast servos, which should reduce damping in the roll and pitch axes, I would think. I am using Promodeler DS490BLHV servos with 2S LiPo. Specs show a speed of 0.078 sec/60deg at 8.4V. Torque is 490oz-in at 8.4V. They are very quick when using RC passthrough to move them.
I did have a question about the RPM sensor input. There is spiking in the RPM reading occurring soon after reaching 1400RMP. Perhaps I am surpassing the sample rate capability of the flight controller? Seems like that would cause a 1/2 cut in RPM reading rather than a spike, unless the flight controller is attempting some kind of compensation. I am using the HobbyWing 260A RPM feedback. This is a buffered feedback with a 3.3V high state square wave. The motor is 10-pole and the drive gear to pinion ratio is 104/9. This gave me an RPM1_SCALING factor of 0.008653846, however, RPM was being reported at half its actually speed, so I changed this to 0.017307692.
Not sure what rate ArduPilot can accept RPM signal input, but that is my first thought as a potential reason for this spiking.
See log 2024-06-15 21-02-14-anon.log in shared drive.
Iâm trying out the auto missions. Just did a RTL test, which was supper cool! It came right back and landed itself so beautifully!
When planning an auto mission, if my mouse hovers over the home location, it shows Alt: 230. I guess this is my takeoff altitude, even though I donât have a takeoff command set? I would like to reduce the takeoff altitude, but am not finding the option to change it anywhere. where can I adjust the takeoff altitude? Or maybe I need to be explicitly providing a Takeoff command?
You need to provide a takeoff command and altitude in the mission. The 230 might be your altitude in reference to Mean Sea Level?
Takeoff will be your first command in the mission planning, you can specify the altitude it will climb at before moving to the next waypoint.
I would suggest to play and experiment this stuff with SITL, itâs super useful and you can explore pretty much everything related to mission planning!
Thatâs the altitude provided by the GPS, so itâs AMSL.
1 Like