The PX4flow is expensive, heavy, & fragile.  Its sonar module is insufficient, so you need to replace it with a more powerful module.    Replacing the MB1043 with an MB1240 & translating the serial protocol from cm to mm is required.  Only the UART output of the sonar is used.


The trick is the more powerful module outputs a different protocol, so you need to pass the sonar readouts through the mane microcontroller to be translated & then to the PX4flow.  There's also the glue logic to invert the UART voltage.

The PX4flow is liberated from its inferior sonar module & useless headers.


Replacement sonar signal & mane I/O are connected.


  More powerful sonar module & glue logic.







Sonar, PX4flow, flight computer, & bluetooth are soldered in the navigation test harness.


The Turnigy Microquad has the highest capacity for its size.


It's single sided PC boards, conventionally routed.  No 3D printing, laser cutting, or anything else.


 The landing gear is made out of PC board standoffs.



The motor mounts need a lot more reinforcement.  Some guys glue on carbon fiber or plywood doublers.





It has enough clearance for the PX4flow.  The battery needs to go on top, over the mane board. 



Taking a page from the AR Drone, the battery is used to weigh down the IMU. 






It's the most energetic platform so far, definitely not a toy.  Those Turnigy 1811-2900's get a lot more thrust from the same space as brushed motors.




  The PX4FLOW's 1st flight


Based on the previous video of the TCM8230 over carpet, the PX4FLOW is a huge improvement.  It actually holds position quite well over plush carpet & below 1m.

The sonar still has issues above 1m.  It glitches to 5m when it can't detect a reflection. Sometimes you want it to send 0 when it reads 5m & sometimes you want it to repeat the previous reading when it reads 5m.  It still glitches, despite this algorithm.


It's very heavy, so it handles the wind quite well.  Crashes require a lot of repairs & propellers.  It's every bit as crash prone & fragile as expected.  Every day of flying requires a bag of propellers.  The propeller mounts tend to break off.








It's time to fuse a barometer with the sonar to try to improve the range over carpet.



 The jesus barometer goes on.


& gets earplug foam insulation.  Earplugs are decent sources of breathable foam.


The temperature compensated MS5611 output

 




 is compared with the raw MB1240 output



in a 1m flight over carpet.  Despite the temperature compensation, the MS5611 has a huge amount of drift, leading to 1m of unknown absolute error.  Its short term relative readings are quite good for something that measures air pressure.


For the 1st time, you can see just how many sonar readings are invalid.  It generates 7650 when it knows the reading is invalid, but sometimes it errors low.  It never seems to error high.


The object of the game is to fuse the air pressure & sonar readings to eliminate the errors.  Sonar still has to be the master.



In this flight, the last 10 pressure readings are averaged & normalized to the average of the last 10 sonar readings to compensate for temperature drift.  The most recent pressure reading is subtracted from the average pressure & scaled to mm to get the most recent altitude based on pressure.


The algorithm doesn't produce any glitches, but is very noisy compared to sonar.  You want to use sonar if the sonar change is under 100mm.  If it's over 100mm, use air pressure. 


A flight using fused sensors for guidance was very smooth, but overshot the altitude changes a lot more.  It switched to pressure, which lagged sonar.  The sudden altitude changes due to glitches were gone, but there were audible glitches in motor speed.




The PX4flow has presented a case of far sightedness.  It's most accurate at 1m altitude.  Below 1m altitude, it has a very hard time detecting position.  Above 1m, the sonar falls over.  The focus can be adjusted for lower altitude, but it has to fly in a narrow altitude band.  That's the price of a very high magnification, high brightness lens which can detect surface features from far away.


A 2nd camera would have benefited the low altitudes, but there wasn't enough time to discover the PX4flow limits & design a 2 camera optical flow solution.








 That's probably the most aggressively something has ever flown itself using optical flow.  Optical flow has previously just been used for aiding a human pilot in a hover.


 So the PX4flow has a very low top speed.  The horizontal velocity has to be limited to 0.25m/s.  Vertical velocity has to be limited to 0.1m/s.  The mane problem is what kind of carpet it has.  Its top speed in the plush apartment carpet seemed to be higher than the finely colored office carpet.  The mane problem with altitude is it's clearly switching to the barometer more for high speeds & the barometer has much more lag.



The flight time with the PX4flow weighing it down was slightly better than the Syma X1 at 7 minutes.




The power distribution on the microquad interferes with the magnetometer.  It needs to be on a mast.






Views: 7138


Moderator
Comment by Gary Mortimer on October 10, 2013 at 12:21am

As ever love your work Jack


3D Robotics
Comment by Chris Anderson on October 10, 2013 at 4:11am

Fascinating. Should I ask the team to change the stock PX4 Flow sonar sensor to a MB1240? (We've done that on the RTF ArduCopters)

Comment by Euan Ramsay on October 10, 2013 at 4:37am

Yes please Chris ;-)

Comment by Rob_Lefebvre on October 10, 2013 at 4:53am

Jack, what kind of filter are you using on the sonar?

I was fiddling with it lately and I think I'm having some better success.  The standard filter in Arducopter is a simple 3 element mode filter.  This means it can only reject single "high" error before it affects the reading.  I changed it to a 7 element mode filter, but returns the second element, so it can reject 2 low errors and 4 high errors.  Then I run that through an LPF with 1Hz cuttoff.

Comment by Dave C on October 10, 2013 at 6:10am

If it's possible to swap out the sonar, could I just desolder the existing one and fit a 1240 in it's place?

Thanks


Developer
Comment by Lorenz Meier on October 10, 2013 at 6:19am

Hi Jack,

Its cool to see the flow module being used. The primary reason for the current sensor is the accuracy and mounting size, but given the length of the lens assembly its probably not a problem to offer that alternatively.

I assume you have seen the firmware is open sourced here?

https://github.com/px4/flow

The most recent version offers a 25% speedup. It would be trivial to parse the different messages from the MB1240 in software, too. We have a board version with the inverter onboard, that would be easy to bring back (we started with it).

While you're at it, I'd like to encourage you to experiment with different focal lengths. The M12 lens used has 18 mm focal length. You will get higher top-speeds with e.g. 15 or 12 mm, but less resolution. I can't rule out that a different lens will be a better fit for particular applications (e.g. the drop in resolution might not be visible in the position output). The 18 mm lens is a tradeoff-choice for indoors and outdoors.

New firmware and a different lens might easily get you a 50 - 100% speedup without deteriorating performance if you're willing to optimize for close-ground operation.

Note that the top speed linearly scales with altitude, so at several meters altitude you get some meters per second top speed. The current PX4 native flight stack is currently in testing with parallel flow and GPS support and automatic switchover.

Comment by Bill Nesbitt on October 10, 2013 at 10:27am

Lorenz: Mr Crossfire was the original author of the improved SAD assembly code :)

Jack: Fuse the reported optical position changes (not the reported velocity) and height measurements with the baro, ACC & GYO sensors' and you should then be able to solve most of your altitude hold problems by double integrating Z acceleration.  A byproduct will be well biased rate & acceleration estimates:

px4Flow Demo

Comment by Gary McCray on October 10, 2013 at 6:19pm

Absolutely superb work as usual Jack,

Both the experience with and evaluation of the PX4-FLOW and the use of the Turnigy Micro Copter are very interesting to me.

And you just beat them into submission.

Thank You!

Comment by Crashpilot1000 on October 12, 2013 at 2:02am

Very nice work! There must be countless hours in your project!

I wonder if such optical devices wouldn't need some kind of autofocus to be outdoor usable in different hights. Pairing it with a sonar suggests a main operation hight in the range of about 4m? (i know MB can do more in the datasheet...). I see great potential for indoor usage, paired with some further sonarsensors for autonom. mapping of a building etc!

Comment by Tommy on October 24, 2013 at 4:26pm

I love what your doing sensors are awesome! I posted this before but i thought i would share again sry if you already knew this almost all sensor data is dirty at the raw state you must average you numbers by a certain amount which gives you clean data. this is usually done in the code with an array. the deeper the array the better the number i usually start off with ten then twenty and go from the there!
Example Reading into array
take ten readings and store them into an array sudo code
sensordata = new array(10)
sensordata [0] = 12
sensordata [1] = 10
sensordata [2] = 12
sensordata [3] = 13
sensordata [4] = 15
sensordata [5] = 16
sensordata [6] = 17
sensordata [7] = 15
sensordata [8] = 40
sensordata [9] = 14
total = 164

total devided by array lenght gives clean device reading
214 devided by 10 is 16.4

Of course this is a simple form of signal processing and is based on the speed of the microcontroller
Tricks of the trade Choc
Ps sry if you knew this already

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service