Shop Learn P1 Docs P2 Docs
P2 Drone Quadcopter project — Parallax Forums

P2 Drone Quadcopter project

mwrobertsmwroberts Posts: 36
edited 2022-07-26 19:38 in Propeller 2

This is the quadcopter I have been working on for the past year or so...
I've never owned or flown one, so my piloting skills are not very good.
I'm using one of @ManAtWork KISS boards.
It has 4 ESC's for motor speed control
10 channel R/C serial input
Yaw,Pitch,Roll IMU serial input (WT901Cttl from amazon or BNO080 sparkfun unit)
GPS serial input
LPS22 barometer I2C input
Parallax ping sensor pulse width input

I tried to do most of the PID tuning while hand holding it in the basement.

For the first flight the pitch and roll inputs were limited to +/- 3 degrees or so, and I had full control of the throttle. Flying, the pitch/roll stability was a bit shakey, the yaw looked good... my throttle skills are poor.

For the second flight, the pitch/roll stability was better, I lowered the P and D gains.
The battery voltage would drop over time, so I would have to increase the throttle to maintain altitude...

The third flight shows it over the road with a ping sensor holding altitude. The ping feedback gets sketchy as it moves over the curbs...
I had tried it earlier over the grass, but the ping signal was too dirty, maybe some filtering would help.

I'm currently working on trying to get it to hold position with a GPS module.


  • Nice!

  • JRoarkJRoark Posts: 1,079

    That is darned-Skippy impressive! Well done!

  • Very cool! And just at the right time. I'm about to do simething very similar (look here) I've planned to use the LPS25 (from the Elev-8 flight controler) as barometric altimeter and the BNO55 as IMU.

    @mwroberts said:
    The battery voltage would drop over time, so I would have to increase the throttle to maintain altitude...

    I think it would be good to add altimeter feedback to make an "auto throttle" to maintain altitude and use the throttle input as climb/descend command.

    The third flight shows it over the road with a ping sensor holding altitude. The ping feedback gets sketchy as it moves over the curbs...

    I'd use the ping sensor only as "warning device" for landing to slow down the sink rate when close to the ground. Above say 2m height I'd use the altimeter or GPS.

    I'm currently working on trying to get it to hold position with a GPS module.

    What module are you using? I've ordered an LG69T from Quectel but it's only available as bare SMT module or on a really big eval board. Yours comes on a nice breakout board with a connector for an active antenna.

  • I don't know what your requirements are for holding the position with GPS, but due to the reduced resolution that's not the way precise position control is achieved in drones (unless something like differential GPS is available). The way the commercial drones achieve this via optical flow. They basically point down a camera, and use that do stabilize. The same principle is used in ready-made form in optical mice sensors. I do not know if tweaking the optics of these systems would allow for them to be used in the same application.

  • @ManAtWork , I ublox neo-m8u with RTK from Sparkfun. Set it for 10Hz update rate and ublox format in Ublox-center software, brought it out to the front lawn carrying my laptop with X-Y position display, expecting to see a high res trace of my steps as I walked around the yard... but no... I can't get the RTK to work. I think the RTK works for moving things, like cars, so that the GPS can figure a heading and figure out how it's internal x-y accelerometers correlate to the north-south/east-west GPS inputs it receives. The m8u has no internal compass, so if it sees, say, an acceleration in it's internal X direction, it wouldn't know if it should add it's predicted integrated motion to the next longitude or latitude extrapolated RTK output... I bought a HGLRC 80 and a HGLRC 80pro to try. They have an update rate of 10Hz, were cheap and had an antenna built in. They seem to work better than the ublox RTK, but the @deets position output isn't as good as I had imagined. With this resolution maybe my drone could hold position in a 10ft radius?....

  • I know... cheap or highly miniaturized GPS receivers like that in a cell phone give really jerky coordinates. I'm a geocacher. I don't know how many times I stood in the forest looking for a cache and I cursed because the position was 30+ft off, or even 100ft when the sky wasn't clear.

    The ads for the LG69T claim is has "centimeter accuracy", whatever that is... The don't say how many centimeters, 10, 100? :D I'll try it out. But I have only little hope that it's good enough to stabilize the position of a camera drone. But that's not my application. I just want to use it to correct the weather dependency of the barometric altimeter, corect the drift of the IMU, provide ground speed readings and to navigate back to the landing pad if necessary.

  • here is a video of my LPS22 testing...

    The ping sensor had much better vertical resolution than the barometer, and let me hold a tighter altitude window...

  • That looks fairly good. The resolution seems to be in the centimeter range although there is a lot of noise (literally, air pressure changes = sound). I'd use low-pass filtering to supress the noise. That results in delay which is bad for control loop stability. But you can mix it with input from the accelerometer for faster response to changes.

  • PublisonPublison Posts: 12,344
    edited 2022-07-27 23:08

    Great Project!
    Yor first video is just like my first flight with a quad 10 years ago.:) You are getting better each flight. Hang in there!

    I would try a Line of Sight LIDAR like this one:

    Works good over a variey of surfaces. +/-1% accuracy over 5 m to 12 m distances, and +/-5 cm accuracy down to 10 cm.

    I bought and expensive one:

    to put on my ELEV-8 . Have not had the time to integrate it yet.

  • Using LIDAR instead of ultrasonic ping is a great idea. Those little gadgets are cheap and quite accurate these days. (I remember there was a presentation about a 8x8 pixel distance sensor for <$10 on the live forum but I don't find it anymore) I think they give more reliable readings when pointed on a "soft" object like a tree or long grass. But do they also work in fog or dust? I know, this is a more theoretical question. In practise you'll never need that because with model aircrafts or smaller planes you are restricted to visual flight rules anyway. So if you don't see the runway you don't land.

    But it would be nice to have something that would, at least theoretically, still work in such a case.

  • pik33pik33 Posts: 1,735

    But do they also work in fog or dust? >

    Or sunlight.

    I have Intel L515 LIDAR - depth camera but when in sunlight its laser is too weak and it simply stops working and/or sends garbage

  • PublisonPublison Posts: 12,344

    The Lightware family of products work very well in sunlight.

  • @Publison , I'll give the tfmini plus lidar unit a try, it looks much better than the ping, and will interface with UART like the R/C, AHRS, and GPS. Thanks!

  • ManAtWorkManAtWork Posts: 1,512
    edited 2022-08-01 16:31

    I just got my LPS25H sensor working. Wow, that little bug has really amazing resolution. At 25Hz update rate I have ~16 bits stable which translates to around 1.5Pa or 13cm or 5in altitude. With low pass filtering I think 1cm can be achieved, of course with reduced bandwidth.*

    I think one of the reasons for the noise is the dynamical pressure caused by wind and turbulences. 1cm altitude change means only 1.2Pa pressure difference. 1,4m/s wind leads to the same (dynamical) pressure. If there are turbulences or vibrations which can't be avoided near propellers this generates noise.

    So for an "auto throttle" or altitude stabilization control loop it's probably best to use a so-called velocity observer. To calculate the vertical velocity we can combine a low pass filtered derivation of the altitude reading from the barometer and a high pass filtered integration of the vertical acceleration from the IMU. The offset error of the accelerometer causes a theoretical infinite drift over time for the integration (=velocity) but that error is removed by the high-pass filter which has a DC gain of zero.

    • Edit: Nope. :/ There is too much drift and low frequency noise. Even when decimating the output down to 1Hz the altitude values vary by ~1m over a minute.
Sign In or Register to comment.