Pls send me a PM to arrange the HW
Jussi
flomartel wrote: So, do you recommend the STM32F4Discovery with STM32F407VG processor model?
Great question about the M4 vs. the AQ6 w/DIMU. I don't know enough yet about the differences (essentially same source code?) to make a judgment call, so I'm tempted to turn the question back to you. I'm candidly struggling to find information about the hardware and interfaces besides a few pictures and diagrams lying around... So, which one do you think would be most suitable given what you know about my project?
Random question: has there been any discussion about interfacing the ESC32v3 with other autopilots? I know that would require code changes on those autopilots, but I believe some could be convinced by some of its features...
flomartel wrote:On a somewhat separate note, I am also looking at possibly implementing an AGL sensor with the AQ. The obvious functionalities are precision landing and flying at a set altitude above ground. Has any of this work been done for a sonar/lidar?
flomartel wrote:For example, barometer bias is taken into account in the altUkfTimeUpdate but not the accelerometer bias.
flomartel wrote:Another example is that measured downward acceleration integrated over time for the prediction step (“acc”) is divided by two in the alt UKF but not in the nav UKF.
flomartel wrote:More fundamentally, I don’t get why there’s a separate alt UKF coded for when GPS performance is degraded (or in a GPS denied environment) since UKF_VELD is not determined using GPS height anyways. Is it linked to the use of “navData.presAltOffset” which adjusts pressure altitude for waypoint navigation when there’s a good GPS fix?
flomartel wrote:How were the process and measurement noise values for the altitude and vertical velocity for both the alt and nav UKFs determined (there’s a bunch of them)? I’m trying to find what kind of specs/measurements I would need to find out about the sensor I would like to integrate to determine some decent noise values to use.
Actually the bias used in that function *is* ACC bias.
I don't see what you are referring to. Can you quote line numbers?
out[ALT_STATE_VEL*n + i] = in[ALT_STATE_VEL*n + i] + (acc * dt) + (noise[ALT_NOISE_VEL*n + i] * dt);
out[ALT_STATE_POS*n + i] = in[ALT_STATE_POS*n + i] - (in[ALT_STATE_VEL*n + i] * dt) - (acc * dt * dt * 0.5f);
out[UKF_STATE_VELD*n + i] = in[UKF_STATE_VELD*n + i] + acc[2] * dt + noise[UKF_V_NOISE_VELD*n + i];
out[UKF_STATE_PRES_ALT*n + i] = in[UKF_STATE_PRES_ALT*n + i] - in[UKF_STATE_VELD*n + i] * dt;
So, if you want to add a new sensor or state to the UKF, to get optimal performance, this automated tuning would have to be re-run.
flomartel wrote:Maybe I don't quite get how it's done but I'm comparing these two snippets of code
Lines 19-20 of alt_ukf.cand lines 307 and 286 of nav_ukf.c
- Code: Select all
out[ALT_STATE_VEL*n + i] = in[ALT_STATE_VEL*n + i] + (acc * dt) + (noise[ALT_NOISE_VEL*n + i] * dt);
out[ALT_STATE_POS*n + i] = in[ALT_STATE_POS*n + i] - (in[ALT_STATE_VEL*n + i] * dt) - (acc * dt * dt * 0.5f);
- Code: Select all
out[UKF_STATE_VELD*n + i] = in[UKF_STATE_VELD*n + i] + acc[2] * dt + noise[UKF_V_NOISE_VELD*n + i];
out[UKF_STATE_PRES_ALT*n + i] = in[UKF_STATE_PRES_ALT*n + i] - in[UKF_STATE_VELD*n + i] * dt;
I mischaracterized the difference in my previous post, but essentially (acc * dt^2) / 2 shows up in the alt UKF but not in the nav UKF, and I was wondering why the difference...
flomartel wrote:Thanks for your interesting comparison of AGL sensor technologies. It prompted me to look briefly at the code related to the optical flow sensor + sonar sensor (using PX4FLOW?) and the way you handled the sonar data. I think this is a good example and would serve as a nice basis for any other AGL sensor integration work. Interesting to see you used mavlink to interface with the sensor and intrigued as to why you used the averaged ground distance measurements for the altitude state estimates. Why is that?
flomartel wrote:I agree with you that sonar is difficult to work with since the measurements are subject to vibrations, acoustic noise, pressure differences, etc., but you did it! I saw a video on youtube sometime ago of the result in flight which seemed satisfactory but admittedly the ground seemed relatively flat (it was a wooded area with trees if I recall correctly). How would you characterize the flight tests performed with the PX4FLOW?
flomartel wrote:Do you have plans to integrate a lidar or another type of AGL sensor with the AQ? Besides the advantages I already mentioned, do you see others in using an AGL sensor?
Return to AutoQuad 6 Flight Controller
Users browsing this forum: No registered users and 5 guests