I've noticed that one major problem for ArduPlane flying on GPS-denied environments is wind estimate, which if not very accurate can really make things very bad.
So what If I've an external source of wind estimate? A separate device that can feed EKF with wind vector. Should then I just set stateStruct.wind_vel.x and stateStruct.wind_vel.y for every thing to be fine or there is something else?
I've done a small experiment where I got very accurate wind estimate and injected it by setting the mentioned two variables. The wind was blowing from East, plane was flying into wind in AUTO mode - yaw was ~90 -, I've verified it got wind estimate correctly over telemetry/MP, then turned-off GPS using AUX switch, the plane kept going South East changing its yaw randomly between 100 and 190 but at ~110 most of time.
arspd_use was activated and EKF3 was used.
The same experiment had been run without wind_estimate injection - default arduplane - and things was too much worse, yaw turned to ~170 when GPS was off.
What do you think?
I'm a masters student in control engineering and am doing my masters using a pixhawk with arduplane, but could use help navigating the code structure of arduplane firmware.
I have developed a feedback linearized controller for a two engine flying fixed wing to support VTOL, without vectoring, that I would like to implement on a pixhawk/arduplane combo. The controller, in simulations, sucessfully can go any direction with any speed. No need for switching controller or gains. It automatically adjusts attitude to achieve the desired velocity vector.
So far I've cloned the repo, built the firmware, uploaded it, modified the firmware to show simple console output in the ground staion, and reuploaded sucessfully.
My idea was to hijack the FBWB mode and just insert my control algorithms there.
I need access to the quaternion estimate, velocity, angular rates and position estimates.
If motor speed and elevon/servo states are available those would be nice too.
I need to be able to control both engines and both servos, or at least indirectly set their states.
The simulator/control algorithm I've implemented also includes a waypoint navigator where it essentially tries to fly along the line between the two waypoints. Is this how arduplane already works? Should I just go ahead and implement my own tracker in FBWB or is there a way to use the already implemented features?
Is this possible like I imagine?
Would you recommend another way?
@Akshath-Singhal At first I just want a quick n dirty hack to see if my controller ever would work in real life or just in simulations. If I do get that working i may be offered a position at a company that uses these drones to implement it properly. So at first I was thinking to just disable those somehow.
@kd0aij Will do, thanks! At a first glance it seems he has the solution to my parameter estimation problem for the aircraft, so my controller could be ammended with his system to eliminate uncertanties! That would be great!
It also seems he did implement this on a pixhawk, need to read more to see how. Are you guys using this now in the arduplane firmware for the autotune?