OpenPilot

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OP-1543 Fix font used for sat numbers

Apart for the deadband pourposes you need to use a small enough value instead of 0 as we are dealing with floats. i.e. take this into account: float v1 = 1.0f/3.0f; float v2 = 1.0f - v1 * 3.0f; v...

Apart for the deadband pourposes you need to use a small enough value instead of 0 as we are dealing with floats.
i.e. take this into account:

float v1 = 1.0f/3.0f;
float v2 = 1.0f - v1 * 3.0f;

v2 will not be 0.0f but some very small value.

For the same reason you can't assume you'll get exactly 0.0f for roll or pitch here.

altituderoam: Add state transition to altitudeholdstatus for debugging

positionroam: BrakeRate parameter drives rate of deceleration

1. plan_setup_braking calculates distance and time to halt from decel rate and a few assumptions

2. Sanity check for multirotoar initially

3. Pathplanner accurate dT calculation and variable timer as calculated in plan_setup_braking

4. Added brakeRate parameter to flightmodesettings

5. Moved braketimeout period to flightstatus as a calculate value.

    • -8
    • +11
    /flight/modules/PathPlanner/pathplanner.c
Autodetection is now handled using code in OPReview-885 so forcing it by settings is no more required.

Autodetection is now handled using code in OPReview-885 so forcing it by settings is no more required.

positionroam: refinements

1. smoother transition to positionhold on timeout

2. removed lower velocity limit on transition to position roam

3. adjustable timeout value from new UAVO calculated from task update rate

    • -3
    • +4
    /flight/modules/PathPlanner/pathplanner.c
positionroam: Sanity checks and options

1. Add sanity check that integrated stabi mode is either rattitude or attitude.

2. Added adjustable timeout for reversion to position hold.

    • -1
    • +3
    /flight/modules/PathPlanner/pathplanner.c
The general idea looks good but I'm not sure it will work well as it's currently implemented. *about the hybrid mode, what exactly is the 50% limit at which you switch between both modes? Is it 5...

The general idea looks good but I'm not sure it will work well as it's currently implemented.

  • about the hybrid mode, what exactly is the 50% limit at which you switch between both modes? Is it 50% stick range? And wouldn't the transition between both (direct <-> altitude) be pretty extrem?


@Eric: I agree about the fixed fixed time being a problem. It's not so much the weight of the vehicle. If we assume it has enough power to keep altitude even at max. pitch/roll angle, weight doesn't make a difference at all and acceleration/decelaration only depends on pitch/roll angle, not on weight. But what makes a big difference is velocity. No matter what we set as braking distance or time, it will not work well for all speeds if we set the distance directly based on velocity. From a physical point of view, the best approach would be to have "maximum acceleration" (or deceleration in our case) as our configurable parameter. Then, the time we need to brake can be calculated by t = v/a and the braking distance by s= 0.5 * (v^2)/a. This will probably still not work though as "flyendpoint" will brake very smoothly and not go into "full deceleration" immediately. We would need a correction factor for this but I think this would probably be a fixed factor (haven't done the math yet). The problem is that the real deceleration depends on actual pitch/roll which depends on velocity error and velocity PID settings. Velocity error depends on current velocity and desired velocity while desired velocity depends on distance from target. So it's a bit more complicated

The 0.5 velocity limit @Eric mentions would be a real problem I guess. But I think you addressed this already with the "braking timer". So it will enter PH mode after 5 seconds no matter what the velocity is? Should be fine then. Btw, what is the purpose of the >30m/s limit? Would be interesting though to see a quad going from 30m/s directly into PH )

what would happen if the velocity estimate is for whatever reason wrong (badly calibrated sensors, messy GPS signal) and above 0.5m/s ? (edit: to be more specific, "if the vehicle has a velocity es...

what would happen if the velocity estimate is for whatever reason wrong (badly calibrated sensors, messy GPS signal) and above 0.5m/s ?
(edit: to be more specific, "if the vehicle has a velocity estimate of above 0.5m/s while flying in fact stationary")

im a bit confused by all these changes in pios_board.c is this crucible acting up or actual changes?

im a bit confused by all these changes in pios_board.c is this crucible acting up or actual changes?

looks pretty good, although I had no time to test fly it. suggestions: (low priority) make the breaking time configurable, very heavy or very fast crafts might need more than 3 seconds for slowdow...

looks pretty good, although I had no time to test fly it.

suggestions:
(low priority) make the breaking time configurable, very heavy or very fast crafts might need more than 3 seconds for slowdown, - very agile crafts might be able to do in less. the 3.0 hardcoded is a bit questionable, although good enough for testing

(low prio - for debate) the code in manualcontrol.c line 198 and following looks a bit "hacky" at first glance because it "overrides" the mode (newMode) - its debatable if it would be cleaner to handle this completely in pathfollowerhandler.c - although at the price of then having to possibly call the "stabilizedhandler" from within pathfollowerhandler - but I'm myself undecided about that. overriding the mode temporarily might actually be indeed cleaner, as it introduces less code duplication. I dunno

shouldn't this have a (possibly larger) deadzone like the positionvario modes have?

shouldn't this have a (possibly larger) deadzone like the positionvario modes have?

mixer table looks good. I can't test right now, I assume it has been double checked to produce a setup compatible with setups manually created in the config widget when configuring vtail ? (the fir...

mixer table looks good. I can't test right now, I assume it has been double checked to produce a setup compatible with setups manually created in the config widget when configuring vtail ? (the first attempts at fixed wing wizzard had problems there, as they used a different output channel assignment)

positionroam: fix config sanitycheck

Simpy add flightmodeposition positionroam treatment same as positionhold. Future enhancement would be to sanity check the roam stabi selection.

Uncrustify

Merge branch 'master' into next

Merge branch 'rel-14.10'

update WHATSNEW for release

positionroam untested for review. The functionality is: 1. New hybrid altitude roam thrust mode. Altitude control below 50%, direct control above 50% 2. Position Roam consists of four sub-states. ...

positionroam untested for review. The functionality is:
1. New hybrid altitude roam thrust mode. Altitude control below 50%, direct control above 50%
2. Position Roam consists of four sub-states.

State 1: Stabilisation 1 - 6 active because of roll or pitch input.
State 2: Braking mode activated. This triggers a slow down to a endpoint that is 3 seconds times the velocity vector in front.
State 3: Braking timer running. Starts when path followertask resumes and counts down for 5 seconds.
State 4: PositionHold on timer expiry

Note intent is to go immediately to PositionHold if velocity vector is small or too large to be accurate.

positionroam
positionroam
positionroam: Adding braking timeout

1. manualcontrol: don't clobber the braking state if already in braking mode.

2.pathplanner: We reuse this pathplanner task for pathfollower monitoring of the braking timer. Count down from 50 to 0 at 100ms per tick, means we can brake for up to 5 seconds before transitioning to true positionhold.

    • -1
    • +24
    /flight/modules/PathPlanner/pathplanner.c
positonroam: Braking via a fly to vector mode

Activate braking via the fly to vector pathfollower mode with diminishing velocity at the target endpoint.

Add new CCs from Failsafe

compile error/positionroam

position roam compile error and pathfollower setup

1. Fix non-revo compile error with ifdefs

2. Add switch statements in pathfollower to setup and call a run handler for braking until zero-ish velocity attained to then change modes to true position hold.