Flybrix

My Account

Delay between remote and drone response

Comments

23 comments

  • Avatar
    Chris Nichols

    Same experience here. I hope there is a way to improve this experience

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    I'm having the same problem. There is too much lag between the transmitter input and response of the drone. makes it impossible to fly.

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Flybrix people? Any comments/suggestions/updates?

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Same here, corrections just lead to more overcorrections. I've flown plenty of drones with no issues. The lag is pretty bad on these.

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    The latest firmware (1.4.0) and configurations in the app has increased the proportional response to deviations from the controller input so it should feel more responsive.

    I made this video just last week of a sturdier build design, and I definitely feel like I could control it to stay within a foot or so for a full battery.

    q_nE_jDCM_4

    I also tested flying with the app too, maybe a bit harder to keep it this tight, but still can hover within a meter or so.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    I updated to 1.4.0 with no positive changes. I am not using the app for control. Is it possible that by using the right stick to arm the motors put the controller into a different flight mode? The controller is used for controlling other Horizon aircraft and pushing the right stick down changes flight modes in other aircraft.

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Amir, did you post the correct video link?

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Thanks Raja, Apparently not the right video link: NgOLD23fp_c

    The right stick is only for arming/disarming in our firmware. I'll keep digging into it until we can get your experience to the same quality of flight as in this video and run through a build and test to see if I can replicate the lag issue

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Thanks for this Amir. If you can get me close to this level of performance I would be satisfied with your product. I think one of my main issues is that I didn't know about the calibration taking place upon arming. I will rebuild your design and make sure I arm on a flat surface. I will see if I can get someone to record my flight. I would also be interested in a video that utilizes the iphone app rather than a controller.

    Also, utilizing the accelerometers in the iphone to allow for tilt controls rather than the touch screen controls would also help with the user experience.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    I am realizing that my configuration upgrade advice is insufficient to change the responsiveness since new configuration settings may not overwrite the existing settings in a firmware upgrade. We will need to add code to migrate configurations from the previous version to the current version when it boots up. This is related to why people see upgrade messages in the app after they've already upgraded but if they haven't yet changed the configuration since the app checks against the configuration version. I'm hoping we can push this change tomorrow.

    The 1.4 app has tilt-to-fly controls. The next app release will let you control the tilt sensitivity and set the bias offset.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Hi Amir, I think it is a great product but I am having the same issue as many here. When I try to launch it lurches in one directions. I have checked my motor and propeller config and they are fine. I have installed the chrome config app, but am not sure what I should be looking at here to improve the flight and some guidance or a video on the config app would be great. Based on comments I also made a very similar mod to yours to put the battery below, but it still lurches straight away when I try to launch. Really hoping to be able to get it to work like your video. Any suggestions are welcome. I am also curious if I should be trying to use the trim, tips on how to use this would also be great. I have already killed two propellers so hoping to get this working soon as I am in Australia. If I am looking to buy new propellers, can you suggest what to get in terms of A and B type propellers. Thanks, Ben

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Amir – I am hoping the change you pushing soon fixes the issues with the remote controller version as well as bluetooth – right now we are looking at returning the entire kit or having to buy our own flight controller, adapt it to mount on lego, and then running that one.

     
    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    The 1.4.0 update did already include code to automatically update the configuration to the latest settings. (in case you're curious here's the code: Flybrix/…/config.cpp#L63)

    I just opened a new unit to test (I'm at my parents house for the holidays so I opened the one I sent them), built the sturdy quad and flew it around my living room with the RC controller. Had some issues with it veering off when I armed it on the carpet, but then armed it on the wood floor and it calibrated great. I was able to fly the thing in one place until the battery power started to drop it. I updated to 1.4.0 and flew it again on the other battery and it was even more responsive. Then I piloted a flight with my iPhone (1.3, it said i needed a firmware update, but you can ignore that if you don't need to change the configurations, since the default configuration works for quad and octo designs) and was able to control it almost as well as with the controller. I don't seem to have latency issues. You can monitor the RC signals with the chrome app see the graph update as you change the controls:

    Rc_signals

    I want everyone to have this same successful flight, and I really appreciate everyone's feedback since we are adding development tickets based on these suggestions.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Thanks for your engagement, Amir. The community and the fun problem solving is definitely added value for me! I had my best flight yet yesterday. I included pictures of the mod that I made to the base of the sturdy quad design. The issue I am still having is over-correcting with the iphone app. I got the quad in the air and it started wandering in one direction at about 0.5 m/s. I over corrected in the other direction and it took off at around 1.5 m/s. I was able to correct one more time but it lost lift as it banked and crashed.

    I am looking forward to the 1.4 iphone app and firmware upgrade.

    IMG_5419 IMG/em5420 IMG/em5421

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Okay. We will try updating again today and see what happens. I can then post some video…

    Good news. We updated to 1.4 and it is much more responsive and flyable. Note, we thought we had already updated to the most recent software because the update button in the app had been used. But that doesn't include 1.4 which is a pre-release, so for those having this problem, one should go to:

    Flybrix/flybrix-firmware/releases

    and manually download 1.4 and install

    then get the 1.4 Chrome app:

    chrome.google.com/…/mcdbgoelaigocgknkpblmandhol

    You can then verify responsiveness via the app. Could still be a bit more responsive, but now at least functional. Keep the updates coming.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Awesome to here you've got it working and I appreciate your help in clarifying the update confusion. We are modifying the startup LED light pattern so that will be unique to the version number for confirming the update and also reporting the version number of the firmware to the app. Also nice to get positive feedback on the forums since it's obviously biased toward issues

    1.4 is pre-release until the iphone app is updated on the app store, which is still taking much longer than usual to get to review.

    The actual change to improve responsivity/flyability has nothing to do with the actual firmware, and is actually just a modification of the default configuration settings that are accessible even in the 1.3.0 firmware using the chrome configuration tool. (Sorry if this starts to get a bit pedantic) What I did was increase the proportional gain of the Master Roll and Pitch controls to increase controller response, and I decreased the proportional and integral gain of the Slave Roll and Pitch controls to prevent wobbling. This is called a cascade PID controller. The “Slave ” control represents the feedback response to changes in rotational velocity, and the “Master” control represents the feedback response to changes in the rotational position. This sort of control works well for a drone because the gyroscope which measures rotational velocity directly, is not effected by linear vibration as much as the accelerometer (which measures the rotational position) so the gyro updates at a much higher rate (>200hz) than the accelerometer which must have a low pass filter to mask vibrational noise at the rotational frequency of the propellers. The actual state estimate of the rotational velocity and position is determined by a Kalman filter that combines the accelerometer/gyroscope/magnetometer data to get an optimal estimate despite the noise. To go deeper into the mathematics see the wiki page on PID feedback and Kalman Filters and the software that does this is all open source on github.com/flybrix:PID controller and Kalman filter

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Hi Amir!

    I opened the flybrix kit a couple of days ago and am having more fun than one would imagine smashing lego into walls and attaching propellors to various builds. However when making the Quadcopter I also ran into this ‘veering off’ issue. To rectify this I acquired the chrome configuration tool and have just now increased all the Master proportional gains and decreased the slave proportional gain and integral gain to zero. After now testing not much happened that was in a positive light – I then increased the Slave PID values and still not much is happening. I was merely wondering If you could be somewhat more specific and a tad more ‘layman’ in you explanation of editing the tuning configuration as I'd really like to get flying and gain a deeper understanding of what the effect of changing around these values really is.

    Thanks

    Sean!

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Hey Sean,

    (this post got super long, and might take like 10 minutes or so to read)

    The veering issue is almost certainly a bias during the arming as it calibrates the horizon setting so changing the feedback system settings will not have an effect on veering. We' plan to add the option to disable calibration during arming so that you can set the horizon once precisely and it will stay roughly the same between uses since the accelerometer doesn't really drift over time.

    We are working on a textbook on drone building with a deep embedded systems / control theory angle that would dive into this with proper figures and so on, but for now I'll jot dot some notes that might help clarify how the feedback system settings work. If you want to reset the settings, you can use the app (unless you're still waiting on iphone 1.4.0 version release in which case you can downgrade and then upgrade the firmware to reset the configuration)

    The PID acronym stands for proportional/integral/derivative. I'll get more into that in a bit, let me first explain how the cascade PID (master/sl ave) system works.

    In the cascade PID controller, Master and Slave settings correspond to the Positional data and Velocity data respectively. The aspects which our feedback system can control is the Roll (Ty), Pitch (Tx), Yaw (Tz), and Lift Fz. Generally speaking a symmetric design should have the same Tx and Ty settings. One could also image Fx and Fy feedback settings if you had propellers blowing sideways (even at a slight angle).

    You can bypass the Master controls to enter “rate mode” where the controller left stick input controls the pitch rate and roll rate — this is the default configuration for the Yaw axis. In rate mode, the system will not auto-level, which is useful for drone racing where you are primarily trying to pitch forward.

    You can also bypass the Slave controls to effectively directly control the inputs for each control vector and fly without feedback. This is the default configuration for the Fz axis (Lift/throttle), but is probably not recommendable for the other axes. We do have a barometric altimeter on board so we can use feedback to control the lift rate using slave PID feedback only or potentially even the absolute height using master mode based on the throttle joystick position. Once we add barometric altitude data to the state estimator, we will also add a button to turn on altitude locking, which would essentially control the bypass on the slave PID feedback on the Fz axis.

    The mix table in the configuration tab specifies how the motor outputs are determined by the values for the control axes (Tx, Ty, Tz and Fz) coming out of the feedback system. For example a “-1” in the Tx row implies the corresponding motor is in the rear of the design such that increasing the motor power would cause a torque in the negative direction around the x axis (pitching forward). A “1” in the Fz row implies that the motor contributes to positive force in the z direction.

    With the Master control enabled the drone will respond to set the angular position and the controller input is interpreted as setting the target angle. In principal you do not need slave feedback enabled to restore the angle setting, but due to the higher frequency of accurate angular rate measurements from the gyroscope (>200hz), there is a much faster response to tell the system what rotational velocity to target especially since we're generally looking for a very low or 0 rotational velocity during stable hovering, the master control is then a slower responding system (10hz instead of 200hz) that says how to change the target rotational velocity in order to get to the target angle of the controller input.

    So now what do the PID terms actually do?

    The P (proportional) term controls the amount of response in direct proportion between the measured input and the target. For slave roll, suppose due to a disturbance, we start turning at a rate of 1, but we want to be turning at a rate of 0, then the proportional output is -1 times Pslave. For the master roll, suppose you are at 0 angular position (level) and you push down the controller to bank to 5 degrees, then the output is 5 times Pmaster. This output is called the Proportional gain.

    The I (integral) terms accumulate over time — each computation cycle the measured deviation from the target is accumulated ( the integral of deviation over time). The windup guard sets the maximum value of this integral over time. This accumulated error times the I terms yields the Integral gain.

    The D (derivative term) is a dampening effect. If the measured deviation is approaching the target, then the derivative gain would be negative, subtracting from the effect of the proportional and integral gains. The gains are all added to compute Tx Ty Tz and Fz.

    You do not need to have anything but proportional gain to get a multirotor flying, however the response may be slow without integral gain. Too much P and I gain and the system will wobble. This can be counteracted by lowering the P and I terms or by adding some D terms. Generally adding the D terms will prevent over-correction and damped oscillations, but will also decrease the responsiveness too.

    As a generally approach to tuning you want to start with all the PID settings 0 and in rate mode (bypass master). Increase the P term until it starts to wobble and then halve-it. Then do the same for the I terms.

    Then enable the master controller (for Tx and Ty, not for the Yaw axis Tz which should just stay in rate mode) and do the same thing for the P and I terms: increase P until it wobbles then halve it, then increase I until it wobbles and then halve it.

    Instead of halving it, you can experiment with low D terms also.

    Anyway, this is already way longer than I thought I'd type up tonight…

    happy new year!

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Amir

    Thanks for all your help on this. However, after trying to get the flybrix kit into any stable flight for almost three weeks, we have given up. It still veers and crashes almost immediately after takeoff.With the 1.4 code it takes off reasonably vertically and it somewhat responsive (which under 1.3 it couldn’t even do). But it won’t hover – it rapidly veers off course and course corrections are too slow. Again, we have experienced drone pilots trying to fly this and they can all fly a $18 echanine or a high-end racing drone with no problem, but they can’t successfully fly any of the builds we have tried (and verified). It simply isn’t a fun kit/toy/activity if all it does is crash. I am sorry about this, but it is sufficiently expensive that we need to go a different direction. Right now I feel like we are still beta testing, but my sons are not getting any enjoyment out of this (crashing was fun for a bit, then became too routine). Again, they can fly many other drones no problem, so there is something still fundamentally wrong here with the controller.

    Best, Michael Tarr

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Michael,

    I agree. This has promise. But right now nothing, and I mean nothing, flies more than 3 or 4 seconds without slamming into a wall. Not fun, which really makes me sad. Both because I spent so much money on this and because I had really hoped to use it for STEM education.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    The drone calibrates the horizon based on how it is armed so make sure you arm it on a flat surface. I don't think I'm a particularly good pilot, but this is me flying a sturdy quad build with 1.4.0 firmware: NgOLD23fp_c

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Thank you for the reply Amir. I had read long ago about using the position at arming as the level reference. I am a very experienced drone pilot. I can assure you that is absolutely not the problem many of us are experiencing. Despite the fact that you obviously have models that fly, too many of your customers are having problems to simply dismiss them as calibration errors. Too many experienced pilots are having identical problems.

    Even assuming the model isn't absolutely level at arming, it is within a degree at most, and it should be easy to compensate for. This looks to me like a F C with really screwed up pids or sensors in a feedback loop.

    What I see is the model will lift off and the moment it starts to drift and I correct for it, the model then accelerates the same direction until it hits something. No amount of input in any plane changes the trajectory (except throttle). That is most definitely not calibration.

    You owe it to your customers to take this seriously and not blow this off as user error.

    0
    Comment actions Permalink
  • Avatar
    Chris Nichols

    Hey Jon, I don't dismiss there is something wrong and that it goes beyond correctly upgrading and arming procedures. You were new to the thread so I wanted to make sure we covered the basics. I provide my flight video just to show what I expect to be a nominal flight experience, since as you can imagine, I am trying to replicate the take-off and race off in one direction issue being reported here. It bothers me to think there might be a software or hardware issue that only shows it's face in a small percentage of cases, but my best guess is that there is something is wrong with the receiver, or the PID settings are not getting correctly updated.

    With the chrome configuration app (flybrix.com/chrome) you can monitor the controller in the R/C signals tab. Does it seem like excessive latency between moving the controller and the graph updating? Are there any channels dropping or glitching?

    Can you check the PID settings in the configuration tab? It's possible these values are getting corrupted when trying to set the configuration from the app. Here are the default PID settings for 1.4.0 on the configuration screen: PIDs

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk