OpenPilot

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
assistedcontrol: prevent assist mode impactig new flight mode position

assistedcontrol: stay in manual thrust when throttle is below vtol min

This was already working for the wrong reason...when thrustatbrakestart was 0, in the brake state it would change to manual, because of noise in the ppm/pwm throttle value

OP-1648 System panel : Detect CC/CC3D (don't display CpuTemp), "Basic (No Nav)" or "Gps Nav (INS13)" display for attitude estimation

Merge remote-tracking branch 'origin/next' into thread/OP-1628_Reboot_Board_In_Wizard

OP-1628 Uncrustify

OP-1628 The autoupdater should wait for board to boot and connect before returning.

assistedcontrol: avoid timeouts being the main brake exit scenario

Yes good suggesting I was thinking along these lines I'll include in existing documentation.

Yes good suggesting I was thinking along these lines I'll include in existing documentation.

this needs extensive flight testing Alex Beck could you define a test scheme / sequence / checklist or something similar that would 1. test all the new functionality 2. test all existing functional...

this needs extensive flight testing Alex Beck could you define a test scheme / sequence / checklist or something similar that would
1. test all the new functionality
2. test all existing functionality that is potentially affected by the code changes
3. desired test outcomes for each test case

with that we could let it loose on the flight test team (or maybe in a first step a selected few daredevil alpha testers like failsafe )

like "defineable unions in uavobjects" ? http://reviews.openpilot.org/static/ne9j9f/2static/images/wiki/icons/emoticons/smile.gif

like "defineable unions in uavobjects" ?

sooner or later we need to find a solution to better handle stuffs like this

sooner or later we need to find a solution to better handle stuffs like this

note: this is basically 2 functions in one and does different things based on this if/else switch - when this code gets cleaned up later, it should liekly be refactored as two different functions f...

note: this is basically 2 functions in one and does different things based on this if/else switch - when this code gets cleaned up later, it should liekly be refactored as two different functions for better readability and reuseability. similar applies to a few other places

assistedcontrol: fixed deadband and flightmode reuse with GPSAssist

    • -22
    • +74
    /flight/modules/Receiver/receiver.c
I have addressed all code review comments to date

I have addressed all code review comments to date

assistedcontrol: code review comments

1. prevent Adjustments when low throttle less than vtol min. No user impact.

2. removed brake vertical thrust pid controller. Just use one as tuning is done on the hold. Note thrust management used to be great...so need to test and compare...Jim please test...

3. move pathDesired parameters to ModeParameters - no impact to user setup.

4. make uncrustify_flight from code review

5. plans.c move magic values to defines - no user impact

6. move brakerate from flightmodesettings to vtolsettings - just a move of where to set brakerate.

Well, not really "noisy" - the accelerations we measure and call "noise" are actually real most of the time, like vibrations on a quad or from a bumpy ride on a ground vehicle. Instead of (or in ad...

Well, not really "noisy" - the accelerations we measure and call "noise" are actually real most of the time, like vibrations on a quad or from a bumpy ride on a ground vehicle. Instead of (or in addition to) a low-pass filter it might be better to check for "close to zero" condition and run a timer. Then do roughly somethink like "if zero g persist longer then 100ms it's airtime, otherwise we can consider it "noise" fom a bumpy ride or other vibrations". Of course that's a matter of testing and looking on how real-world data actually look. Apart from that, when doing low-pass filtering for this special purpose, my guess is that doing the magnitude calculation first and then filtering the magnitude might show better results then filtering the raw data and computing the magnitude from teh filtered data. But that also is something would have to be proven by tests. Like recording raw data, running both approaches on the same data set and comparing the result.

true, good idea - needs low pass filtering though, accels are very noisy http://reviews.openpilot.org/static/ne9j9f/2static/images/wiki/icons/emoticons/smile.gif

true, good idea - needs low pass filtering though, accels are very noisy

yes, exactly - simply as an inbuild "flip over" protection, this would trigger whenever a maximum angle of lets say 75°-80° nose up is exceeded

yes, exactly - simply as an inbuild "flip over" protection, this would trigger whenever a maximum angle of lets say 75°-80° nose up is exceeded

nah, not now. this pid_zero() function is very cheap in execution, so the overhead caused by calling this is negligible. later, however pathfollower needs a partial redesign to make it more modula...

nah, not now. this pid_zero() function is very cheap in execution, so the overhead caused by calling this is negligible.

later, however pathfollower needs a partial redesign to make it more modular (split into multiple files per frametype, maybe similar to how its handled in manualcontrol with the "handlers", extract reused code in separate functions, ...) when we do that we could also handle initialization of each mode when modes are switched / pathfollower turned on/off (including pid zeroing, fetching of settings, separate control structures for each submodule allocated and maintained by the module (similar to how its done by the sub-modules of StateEstimation) ...)

but with all that I would wait until after both this and your stuff is tested and merged, because it makes significant changes. its simply saves work, addressing these things all at once with no functional/behaviour changes at the same time.

The best way to detect flight is to check for zero g condition (magnitude of the accel vector is close to zero)

The best way to detect flight is to check for zero g condition (magnitude of the accel vector is close to zero)

assistedcontrol: uncrustify

climbing uphill would be an issue though...so only if near vertical would this work I would think

climbing uphill would be an issue though...so only if near vertical would this work I would think

assistedcontrol: fix revoproto compile

Revert "assistedcontrol: auto adjustment of neutral thrust setting"

This reverts commit 888188768e7f23860ef51246a70c3a489fcace96.

Conflicts:

flight/modules/PathFollower/pathfollower.c

    • -0
    • +32
    /flight/targets/boards/revoproto/board-info.mk
    • -863
    • +791
    /flight/targets/boards/revoproto/board_hw_defs.c
  1. … 11 more files in changeset.
assistedcontrol: merge fixes

Merge branch 'next' of ssh://git.openpilot.org/OpenPilot into abeck/positionhold

Conflicts:

flight/libraries/sanitycheck.c

flight/modules/ManualControl/manualcontrol.c

flight/modules/Notify/inc/sequences.h

shared/uavobjectdefinition/flightmodesettings.xml

shared/uavobjectdefinition/flightstatus.xml

that, or you could just simplay always limit pitch to a safe margin (prevent flipping). you could have "pitch" controlled by throttle all the time (mixed together in same channel) and have the pitc...

that, or you could just simplay always limit pitch to a safe margin (prevent flipping). you could have "pitch" controlled by throttle all the time (mixed together in same channel) and have the pitch controller always maintain the current pitch, while the throttle controller fights it and tries to control speed

but if the maximum/minimum pitch is exceeded, pitch controller would try to restore max/min pitch instead of just maintain which suddenly gets it much more say compared to throttle controller


that doesn't let you control pitch deliberately yet, but prevents flips - regardless wether you're actually airborne or the vehicle is doing a "wheely"