Coding error?

Coding error, can anyone confirm?

I tried to understand Arduplane's code. In calc_nav_roll (Attitude.pde) there's a command:

nav_roll = g.pidNavRoll.get_pid(bearing_error, dTnav, nav_gain_scaler);I understand that dTnav is the time interval between calls of PID controller. This command is executed each time calc_nav_roll is called so the time interval between calc_nav_roll's calls also dTnav. dTnav is updated in medium_loop at the frequency of about 10 Hz, so dTnav is about 100 ms. Looking at the main loop, the fast_loop is called at the frequency of about 50 Hz, the time interval between calls is delta_ms_fast_loop which is about 20 ms. The fast_loop calls update_current_flight_mode() that means the time interval between calls also 20 ms. In most cases of update_current_flight_mode() it calls cal_nav_roll, so the time interval between calls is only 20 ms. There is a big difference between 20 ms and 100 ms. In my understanding in get_pid() calls instead of dTnav it should be delta_ms_fast_loop. Is this a coding error? Can anyone confirm or clarify this?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Another thing I don't understand is that when looking at calc_nav_pitch(). There is a command

    nav_pitch = -g.pidNavPitchAirspeed.get_pid(airspeed_error, dTnav); (2 parameters call)

    However, get_pid definition is

    PID::get_pid(int32_t error, uint16_t dt, float scaler) (3 parameters definition)

    How can it be like this? Can anyone explain me?

  • Developer

    yep, you're right. Jon Challinger noticed this recently as well. I've been thinking about how to fix it.

    It's easy to just fix the deltat of course, but that will change the meaning of the I and D terms in everyones existing configurations (ie. the HDG2RLL_I and HDG2RLL_D values), scaling them by a factor of 5x. That could change how well a plane flies by quite a lot. I'm always reluctant to break existing tuning, but in this case we may have to, with a warning in the release notes.

    I'm also thinking about how to ensure this sort of bug doesn't happen again. I think the best way would be to make the PID object compute the deltat itself, rather than passing it in.

    Cheers, Tridge

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @gclue_akira: 柏の葉で走行させてるjetracerの中身 #instantNeRF #jetracer https://t.co/giVvuE4hP7
Jul 4
DIY Robocars via Twitter
Cool web-based self-driving simulator. Click save when the AI does the right thing https://github.com/pncsoares/self-driving-car
Jul 4
DIY Robocars via Twitter
RT @donkey_car: Human-scale Donkey Car! Hope this makes it to a @diyrobocars race https://www.youtube.com/watch?v=ZMaf031U8jg
Jun 25
DIY Robocars via Twitter
Jun 25
DIY Robocars via Twitter
Jun 16
DIY Robocars via Twitter
RT @GrantEMoe: I won my first @diyrobocars @donkey_car virtual race! Many thanks to @chr1sa @EllerbachMaxime @tawnkramer and everyone who m…
Jun 13
DIY Robocars via Twitter
RT @gclue_akira: JetRacerで自動走行したコースを、InstantNeRFで再構築。データセットは別々に収集 #jetracer #instantNeRT https://t.co/T8zjg3MFyO
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: SPC 3.0 Now the motor also works. This car is doable. I just need to design a deck to mount my compute and sensors. http…
Jun 13
DIY Robocars via Twitter
RT @SmallpixelCar: My new car SPC 3.0. https://t.co/CKtkZOxeNQ
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: High speed at @diyrobocars thanks @EdwardM26321707 for sharing the video https://t.co/o4317Y2U1S
Jun 7
DIY Robocars via Twitter
RT @SmallpixelCar: Today at @RAMS_RC_Club for @diyrobocars. Used @emlid RTK GPS and @adafruit @BoschGlobal IMU. Lap time 28s https://t.co/R…
May 28
DIY Robocars via Twitter
May 15
DIY Robocars via Twitter
May 14
DIY Robocars via Twitter
May 13
DIY Robocars via Twitter
RT @f1tenth: Say hi to our newest #F1TENTH creation for @ieee_ras_icra next week in Philly. It’s going to be huge! 😎 🔥 @AutowareFdn @PennEn…
May 13
DIY Robocars via Twitter
May 11
More…