Hi @rmackay9,
as discussed with you last time on discord. I am uploading the logs
@Leonardthall your help is much appreciated
problem -
When we are flying the drone in guided mode and giving velocity + yaw + yawrate (ignoring other fields with the respective typemask) through the set_position_target_local_ned through mavros, The drone is flying fine, and the trajectory tracking is good, there’s discrepancy while there’s yawing but the tracking Is descent, as seen in the following video and the log corresponding the video can be found here
the image below shows the tracking performance
The red Arrow demonstrates the position and orientation of the drone and the blue line is the overall path executed by the drone, it is laggy because of communication latency, and the red path is the trajectory generated by the planner.
when, we are flying the drone in guided mode with position + velocity + yaw + yawrate, (ignoring other fields with the respective typemask) the trajectory tracking is really bad. it is illustrated in the video here and the corresponding log can be found here
the image below illustrates the discrepency
intuitively speaking, if we provide position + velocity, it should ideally perform better than giving only velocity setpoints. but in my case it’s the other way around.
please let me know if additional data is needed or if links are inaccessible.
thanks
ArduCopter 4.3.3 has a better trajectory tracking when using position + velocity typemask.
Update first and re-test.
@amilcarlucas because of certain constraints, I cannot do a direct update. can you please point me to the related PRs which I can go through to understand what has aided in the improvement?
thanks
You can use:
gitk libraries/AC_AttitudeControl
To see the changes.
1 Like
This doesn’t look like the trajectory tracking is bad. It looks like the trajectory you are generating is bad.
For example. You have asked for a trajectory with a moving position when your velocities are zero. How do you expect this to be followed?
Hi @Leonardthall,
thanks for looking into the issue. I get your point, the thing is, we have validated the trajectory generator in simulation, and here is the standalone simulation video with the same trajectory generator, and here’s the corresponding log.
also for a side-by-side comparison, I sent the same Pos + vel commands used above, (which was causing tracking error in real world) to the drone in simulation and it is performing better. in the following video, the drone with the blue trail is the simulation drone and the other one is the real-world drone, Odom. (sorry for the glitchy output)
here’s the comparison video and corresponding simulation log
thanks once again
also, the max_velocity the trajectory generator can give is 1m/s so initially, the inputs are low, which can be seen in the logs where I am passing only velocity.
Then you have made a mistake in your trajectory generation as it is absolutely and clearly not generating a realisable kinematic path. Moving position with zero velocity is as clear as it gets.
Both appear to be following a very similar path but with an offset. It is pretty clear that both of these aircraft are demonstrating the path you are sending is broken. I don’t see any justification for what you are saying is “better”. Until you generate a realisable path I don’t believe you can make the statement that one is “better” than the other because it follows a broken path with less error.
I have highlighted a very clear error in your system. I would suggest the best way forward is for you to fix the obvious problem before asking for more help and analysis. By removing the obvious problem it makes it easier to see and diagnose any additional problems.
Good luck.
Okay, thanks for the input, I’ll look into it
Thanks and regards
Also, this is just for someone who looks into this later, these are not “0” velocities, the scale is zommed out, there are really low velocities, since the max velocity that can be generated are 1 m/s
And as shown in the resources above, the same system works flawlessly in simulation, work ardupilot 4.1.5
I hope the resources are clearly demonstrated
Thanks and regards
Hi @Leonardthall, sorry sir to bug you the last time, here is the same log you mentioned in the image above
with a correct scale and I am unable to find instances with 0 velocities with moving positions
thanks
sorry for spamming this thread but I tried UAV log viewer but I am unable to find a single instance where there’s a moving position and 0 velocity
thanks
I apologise, I was mistaken that you were commanding zero velocity here:
The “zero” velocity are actually no updates. However your next set of updates don’t start where the last set ended. So the aircraft is moving to your new starting point while at the same time trying to follow your velocity command.
You can see from the picture above. Your starting target position is not where the aircraft is. So the aircraft is moving towards your desired path. Then once it is on it, you can see if follows well.
To fix your problem before starting any path, send the aircraft to the starting location and don’t start the path until it is stationary at the starting point.
no worries sir,
I see, that makes a lot of sense now. I’ll incorporate the mentioned changes and update you
thanks
Hi, @Leonardthall I went through the problem and I found out while planning the trajectory my planner takes odom at t0 and it would take 1-10ms to generate a plan if meanwhile the odom changes a bit because of some noise, the first waypoint isn’t aligned with what the current drone pose is, as we saw as per your observations from the logs, and I believe the position control tries to correct the small difference and might overshoot a bit and there on its a chaos
The same setup works in SITL seamlessly because the odom there is picture perfect
1 Like
I am glad you worked out what was going on. This stuff can be tricky with so much going on!
2 Likes
Thanks for the response, I’m still lacking ideas to solve this, since I believe the noise would be inevitable in the odometery. And if there’s no proper alignment for first waypoint, position controller would have issues as discussed above, so I’m really not sure from which end I could try solving this.
Thanks
Sorry, I don’t quite understand the problem. The error is only there at the beginning and quickly reduces to zero. I don’t understand why this would cause “chaos”.
You should have only one sample of noise that is removed by the position controller.
Maybe share a log of the real aircraft.
such tracking error in the beginning in a cluttered environment is the real issue. I am sorry, I wasn’t able to understand the noise point which you mentioned. it would be great if you could elaborate more on that. and I would try to get a log as soon as I can.
thanks
Can you tell me why noise is a problem?
