Recent Posts

Pages: 1 ... 8 9 [10]
General Discussion / Re: Problem with USB - Revolution
« Last post by TheOtherCliff on January 14, 2020, 05:31:52 pm »
Excellent advice!

Sorry, looks like this question slipped through the cracks till now.
General Discussion / Re: Problem with USB - Revolution
« Last post by Kasey00 on January 14, 2020, 02:36:20 pm »
Hello everyone,
I have a problem with my 2019 MacBook Pro - Catalina 10.15.1, when I connect the flight controller -Revolution-, the LibrePilot program does not recognize the device.

these devices are displayed:

Has anyone experienced this pcloud​
LibrePilot: 16.09 problem?

MacBook Pro 2019
Mac OSX: Catalina 10.15.1
USB: USB-C chat avenue


If you bought an RTF quad that has OP on it, then it is probably a good idea to download the matching version of OP, and install and run it.  That gets you in the air and flying so you can at least test it to make sure it works before diving into learning how to set it up from scratch like you would if you started over with LP.
If I recall correctly, the @JDL method allows you to fly in the air something that is effectively Manual mode, and in air switch to Attitude mode without it going crazy; where if you use real Manual mode and switch to Attitude, the windup is a problem.

What I am talking about is like an Attitude mode quad taking off tilted from the side of a hill.  The longer you wait, the more it winds up.  When it finally gets in the air the downhill side has much more thrust and it tends to flip "up the hill" like rolling a ball up the hill.
Vehicles - Fixed Wing / Re: MS4525DO (pixhawk) Digital airspeed sensor connection I2C
« Last post by karla on January 14, 2020, 02:09:01 am »
I thought that windup problem could be solved with the "jdl-method"?

We talking about the same thing right?
(PIDs windup on takeoff in Attitude, after arming, switching from manual to attitude and applying throttle).
Applications - Autonomous Flight / Re: GCS control failsafe settings
« Last post by TheOtherCliff on January 13, 2020, 11:20:10 pm »
Glad to help.  :)

It's not really important at a low frequency such as 50Hz, but I would increment a counter rather than make a function call.  Other devs might do differently.  I would have to research whether the fn call was just a memory read / return or whether other stuff (e.g. executive call / task or context switch) was a CPU suck.

static void MCCUpdatedCb(__attribute__((unused)) UAVObjEvent *ev) {
  counter = 0;

#define FAILSAFE_TIMEOUT 2000 /* milliseconds */

  counter += UPDATE_PERIOD_MS;
  if (counter > FAILSAFE_TIMEOUT) {
    // do failsafe stuff
Applications - Autonomous Flight / Re: GCS control failsafe settings
« Last post by treemark on January 13, 2020, 05:32:27 pm »
That was the missing piece. Registering my own ManualControlCommandConnectCallback that updates a last lastMCCUpdate variable. Is xTaskGetTickCount() the best way to read the system clock?

Code: [Select]
static volatile portTickType lastMCCUpdate;

static void MCCUpdatedCb(__attribute__((unused)) UAVObjEvent *ev) {
lastMCCUpdate = xTaskGetTickCount();

Utilizing the timeDifferenceMs function to compare lastMCCUpdate with lastSysTime within the main receiver.c while loop gives me the failsafe behavior I need to continue testing my application. Thank you so much for your help.
After you have tweaked PIDs beware that you may / will find that PID I term windup before flight is a problem.  If tilted left in your hand, you will get more and more right aileron.  That left tilt will cause it to go hard right at takeoff.  Elevator affected as well.  Higher PIDs makes this worse.

I have seen this when switching from Manual mode to Atti mode in flight.  I presume that you get the same problem from just holding it in your hand, in Atti mode, with the motor running.

Of course you really need Stabilization->ZeroTheIntegral enabled (you probably already have this) so that as long as throttle is zero it will not wind up.  Then it is just between throttle up and launch that it can wind up.  JDL does bungee launch at zero throttle, then adds throttle when in the air.

One other factor about this is that you can reduce the I term windup by reducing the ILimit in StabilizationSettingsBank1(or which ever bank) ->
  RollPI (not needed for default settings where I term is zero)
  PitchPI (not needed for default settings where I term is zero)

(Other readers should note that we don't usually stabilize fixed wing yaw so it isn't mentioned here.)
Vehicles - Fixed Wing / Re: MS4525DO (pixhawk) Digital airspeed sensor connection I2C
« Last post by karla on January 13, 2020, 09:21:04 am »
Testing the MS4525DO unit in air, looking very promising  :)

Mounted it in the pre cut-out compartment in the wing and had to cut down the length of the plastic tubes a lot, to fit it in.

Its mounted in the left wing and I wanted to calibrate it.
Just using the default settings for the air speed sensor as posted before here by f5soh and me.

This maiden flight is 5 min at the beach. The wind is coming from the sea at just below 6 m/s, very stable not gusty. I am flying close figure eights turning in to the wind, then land. I don't trust myself to fly in manual mode so this is in attitude, attitude, manual, manual in Basic AttEstAlgo.

This is the log from the 5 min flight showing airspeed and gps reported groundspeed.
I think the average airspeed and the average groundspeed align just fine at around 15.5 m/s.

Over at ArduPilot its suggested for the zero calibration of wind speed:
( )
The airspeed varies with the square root of the pressure, so for differential pressures near zero it varies quite a bit with very small pressure changes, while at flying speeds it takes much greater pressure changes to produce a similar change in speed. If you see mostly 0, 1, 2, with an occasional bounce to 3 or 4, consider it normal. You will not see that sort of variability at flying speeds.

I think that's exactly what can be seen in the picture after landing with no wind - yellow circle.

Think the windspeed sensor is okay and ready to go.

Applications - Autonomous Flight / Re: GCS control failsafe settings
« Last post by TheOtherCliff on January 13, 2020, 04:40:44 am »
You use (replacing objectName and ObjectName appropriately) this code one time during initialization.  Look at the first few functions in the source file e.g. receiver.c and you will see the objects inited and callbacks setup there:
static void objectNameCb(UAVObjEvent *ev);

With the above code, objectNameCb() gets called every time ObjectName gets modified.

librepilot/1609 $ find . -iname '*.c' -exec grep -Hi ManualControlCommandConnectCallback \{\} \;
./flight/modules/ManualControl/manualcontrol.c:    ManualControlCommandConnectCallback(commandUpdatedCb);
./flight/modules/Stabilization/stabilization.c:    ManualControlCommandConnectCallback(FlightModeSwitchUpdatedCb);

Consider callbacks to be asynchronous interrupt functions and you will be OK.  Your callback should probably set flags rather than for instance actually doing a failsafe timeout from there.  To be pedantic, you should make sure your counter is atomic and marked volatile.


or (hacks that would not be allowed in release code) you find where the ManualControlCommand object gets received and reset the counter there or reset the counter in one of the already-coded ManualControlCommand callbacks.


In receiver.c, SettingsUpdatedCb() gets called if either VtolPathFollowerSettings or SystemSettings get modified because of these lines:
Code: [Select]


Make sure you never code it to poll continuously (without sleeping).  It's best to wake up every time there is data ready in a queue (but woe is you if your multi byte data packet ever gets out of sync).  It's second best to sleep the correct length of time, and poll each time you wake up, but that can have a sliding delay with hiccup if you sleep say 20ms and the data arrives every 21ms (or worse yet 19ms and you loose some data).  Your particular code and timeout is not critical that way though.
Applications - Autonomous Flight / Re: GCS control failsafe settings
« Last post by treemark on January 13, 2020, 03:31:21 am »
I think we're missing something the other is saying. The loop runs with or without receiving data. How would I tell if the ManualControlCommand object was refreshed since the last loop or not? It's the 'every time you get new data' part I'm struggling with because I'm not receiving events, I'm polling the ManualControlCommand object
Pages: 1 ... 8 9 [10]