-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guidance Vector Field #1919
Guidance Vector Field #1919
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indent in C files seems wrong at some places, you can use the fix_code_style.sh
script
#include "std.h" | ||
|
||
// Control | ||
extern float gvf_error; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This variables could be in a gvf structure
*/ | ||
|
||
#ifndef GVF_ELLIPSE_H | ||
#define GVF_ELLIPSE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be GVF_ELLIPSE_H
|
||
#include "../gvf.h" | ||
|
||
extern float gvf_ellipse_a; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe make a gvf_ellipse structure
*/ | ||
|
||
#ifndef GVF_LINE_H | ||
#define GVF_LINE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be GVF_LINE_H
*/ | ||
|
||
#ifndef GVF_SIN_H | ||
#define GVF_SIN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GVF_SIN_H
// 1 - Ellipse | ||
// 2 - Sin | ||
|
||
extern uint8_t gvf_traj_type; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to make an enum for the list of possible types
#include <math.h> | ||
#include "std.h" | ||
|
||
#include "gvf.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually, we have "global" path (from airborne code folder), so would be modules/guidance/gvf/gvf.h
, and the others accordingly.
|
||
<header> | ||
<file name="gvf.h"/> | ||
<file name="trajectories/gvf_line.h"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix indent (no tabs)
@@ -0,0 +1,18 @@ | |||
<!DOCTYPE settings SYSTEM "../settings.dtd"> | |||
|
|||
<settings> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
settings should be included in the module
yep, I will apply these changes. The structs that you suggest make sense. I will also split the settings. The essential ones in the module (the gains and direction) and optional ones (parameters of the trajectories) in the current file at /conf/settings |
Actually, you can have several |
btw shall I add a gvf_demo.xml flight plan? so people can play with the settings from the GCS, etc. |
< !DOCTYPE module SYSTEM "module.dtd" > | ||
|
||
<module name = "gvf" dir = "guidance/gvf"> | ||
<doc> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something went wrong with formatting here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha, I see that the script for fixing the style messed the .xml up :P .
float alpha = gvf_trajectory.p[4]; | ||
|
||
// Phi(x,y) | ||
float xel = (px - wx) * cosf(alpha) - (py - wy) * sinf(alpha); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to make two local variables so that cos(alpha) and sin(alpha) are computed only once. Same for the sin guidance function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, I can do it.
However (not 100% sure about it) I would say that the compiler takes care of such optimizations with the flag -O2 right? It checks how many times the same operation is done in the same scope and then make the corresponding optimization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, maybe we discussed that already. It still hurts a bit to see so many trig functions ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha yep. No worries, it does not take any effort to make this change. I will do it within tomorrow :P.
Shouldn't we prefix the module name and the "nav" functions that are supposed to be called from the flightplan with |
The defines that the user is supposed to (optionally) add to the airframe file should be documented in the module xml file. A bit more detailed description in the module xml (maybe with link to the the wiki page) would also be nice. |
True, I have forgotten to add the #defines in the .xml. I will add also an extra description there tomorrow. I also have to add the condition/check 'only for fixedwing' (for the moment). I am not sure about the prefix nav_ . Maybe this is another discussion and for sure you know better than me how to proceed. Instead of having nav_circle, nav_gvf_ellipse, nav_foo_circle.... is there any plan for how to organize/call different algorithms for the same purpose? e.g. to follow a circle? what do you think? |
Regarding the |
A guidance module based on vector fields: https://wiki.paparazziuav.org/wiki/Module/guidance_vector_field (wiki entry still to be improved)
After polishing (and hopefully merging) this commit I will work on the integration of the module in the GCS , right now it can only draw circles using the CIRCLE msg.
So far it only works with fixedwings. The extension to rotorcrafts should be easy to implement, but I have not looked at pprz's rotorcrafts code yet...