A place users can post their projects. If you have a small project and would like your own dedicated place to post and have others chat about it then this is your spot.

User avatar
By Squonk
#20375
cnlohr wrote:None of that. Sadly, none of those algorithms interest me.

This is the most interesting part, though :ugeek:
If you change your mind or in case someone else is interested, here is a useful link:
https://github.com/kriswiner/MPU-6050/wiki/Affordable-9-DoF-Sensor-Fusion
Some more links from Geek Mom:
http://www.geekmomprojects.com/gyroscopes-and-accelerometers-on-a-chip/
http://www.geekmomprojects.com/mpu-6050-redux-dmp-data-fusion-vs-complementary-filter/#more-876
And a definitely more theoretic one:
http://www.olliw.eu/2013/imu-data-fusing/

cnlohr wrote:I was able to get some brief, shakey flight a couple feet up tonight using nothing other than integrating the gyro.

That's about how far you will get without fusing data from all the sensors...

cnlohr wrote:On the current rev of the board I have in my copter right now, though I am getting a lot of bogus data on some of the readings from the LSM9DS1 :(.

Fusion would also smooth that out too... Have you tested the MPU-9250 or the latest BNO055? This last one is particularly interesting as it features a built-in 9-axis fusion algorithm @100Hz implemented into a Cortex M0+. I also recommend changing the outdated BMP085 for a more accurate BMP280 pressure sensor.

cnlohr wrote:*EDIT* I have had to modify my board here and there, like I found out I /really do/ need pull up resistors on my I2C and can't rely on the pullups on the AVR + ESP to save me in a high noise environment.

You DO! Internal pull-ups are OK for normal conditions, but with all these motors in near vicinity, you need stronger ones. You may need separate power/digital power supply with chokes, too.
cnlohr wrote:Additionally, I had to short the reset line on the AVR to 5V. Somehow it was getting triggered. I've driven motors before, but sheeeeeesh this is insanely noisy!

Never a good idea to leave a reset line floating when you may have noise. Don't forget that you are switching at least 4A on a small area board!

cnlohr wrote:I think I am going to separate myself from any kind of sensor fusion and close loop stuff if I can so I can work on things that are actually cool like making a webgl interface using websockets!

I have a sketch running on an Arduino 2009 reading Fusion data out of an MPU-6050, converting them to yaw/pitch/roll on the fly @60Hz and spitting these on a 9600 bps UART, with another sketch in processing language (~Java) on my Linux host to display a nice 3D GeeBee aircraft using OpenGL:
GeeBee Fusion.png
Turning this into WebGL should not be too difficult, the problem is more to read an UART from the browser :roll: I know, I could use a proxy, but this is not elegant! Another better solution would be to implement this on the ESP8266 and spit angles on a socket...

cnlohr wrote:Or, getting even more confusing and running JSLinux inside the browser with the ports mapped back to the ESP :twisted: .

Except for the fun, I don't see how interesting this can be.

cnlohr wrote:Sadly, I won't be able to put hardly any time at all toward this over the next two weeks.

I understand that you may have some other things to do (like exams, maybe), but given the already good work you already did, I strongly urge you to continue on this!
You do not have the required permissions to view the files attached to this post.
User avatar
By cnlohr
#20380 I've looked at the MPU-6050, but The LSM9DS1 just seemed more interesting to me, though I didn't see how cheaply you could get the MPU-6050's until I googled again, they are comparably priced. At this point I am still gonna keep going with the LSM9DS1 unless you can see some technical reason to use the MPU-6050, other than the LSM9DS1 has that awful .43mm BSC!

But yeah, I don't care about the sensor fusion or anything else on that end. If I get this working more reliably, and figure out what's causing my errors (if they're internal to the IMU, or on the bus) I would hope this is something I could get others to participate in. I do care a lot about many of the other aspects and have some expertise in them.

I am switching away from the BMP085 to the MPL3115A2 for the barometer. It has slightly better specs and, most importantly, is available from Digikey! Those boards should arrive in about two weeks from Osh Park. The design also adds a LOT of noise immunity on the power rails, so hopefully that'll help, though I am not convinced that is where my noise is coming from.

Regarding the whole webgl thing and piping data... that's where my major interests and expertise comes in. I already have HTTP interfaces to get data to/from the device. I have written a few websockets systems before. When I operate on a LAN, I can get 500Hz from it, with minimal overhead!

For me, it's co-coordinating MAGStock, then Creation festival aaand getting a bunch of NeonFM Arcade machines out the door!
User avatar
By Squonk
#20381
cnlohr wrote:I've looked at the MPU-6050, but The LSM9DS1 just seemed more interesting to me, though I didn't see how cheaply you could get the MPU-6050's until I googled again, they are comparably priced. At this point I am still gonna keep going with the LSM9DS1 unless you can see some technical reason to use the MPU-6050, other than the LSM9DS1 has that awful .43mm BSC!

Built-in 6-axis fusion algorithm and 0.50 mm pitch, 4 x 4 mm QFN24 :mrgreen:
You can get a GY-521 MPU-6050 breakout board on Amazon for $2.65, and a single chip from DK for $10.83 :shock:

cnlohr wrote:But yeah, I don't care about the sensor fusion or anything else on that end. If I get this working more reliably, and figure out what's causing my errors (if they're internal to the IMU, or on the bus) I would hope this is something I could get others to participate in. I do care a lot about many of the other aspects and have some expertise in them.

All you get are 3 independent sensors, each having their pros and cons in terms of speed, accuracy, noise, drift, etc, not a real IMU. You won't get anything more reliable without fusing their data to get a true IMU.

cnlohr wrote:I am switching away from the BMP085 to the MPL3115A2 for the barometer. It has slightly better specs and, most importantly, is available from Digikey!

The BMP280 is available from Mouser at about the same price. In ultra-high resolution mode, you get a 1.6 cm RMS noise @ 26.3 Hz.

cnlohr wrote:Those boards should arrive in about two weeks from Osh Park. The design also adds a LOT of noise immunity on the power rails, so hopefully that'll help, though I am not convinced that is where my noise is coming from.

With 4A switched current, you should probably get 4-layer boards to get a good GND plane for digital, and star-like GND for power distribution, but I guess you already know all that ;)

cnlohr wrote:Regarding the whole webgl thing and piping data... that's where my major interests and expertise comes in. I already have HTTP interfaces to get data to/from the device. I have written a few websockets systems before. When I operate on a LAN, I can get 500Hz from it, with minimal overhead!

You won't get much more than 100 Hz for yaw/pitch/roll data out of the IMU, thus I don't think even a bad WS system will cause any problem. You may have a look at the MAVLink protocol:
http://qgroundcontrol.org/mavlink/start

cnlohr wrote:For me, it's co-coordinating MAGStock, then Creation festival aaand getting a bunch of NeonFM Arcade machines out the door!

All very sane occupations indeed :D
User avatar
By cnlohr
#20556


Re: Squonk

MPU-6050: Not interested any more. More expensive, doesn't have magnetometer, significantly lower sensitivity than the LSM9DS1... All it offers is stuff that I (maybe) or some other sufficiently versed engineer can do in software with fixed point math.

BMP-280 ... it looks like it ... might ... be better than the MPL3115A2 I am looking at. I'm gonna try that part first and see how it goes.

Re: 4-layer. Yes. I know. I feel like I should be able to engineer this better, though. I want to do it in 2 layers to keep the stack thinner and so they can be manufactured on the super cheap. I care big time about cheap!

I looked at MAVLink a while ago, and that's okay and all... It's not really where my interests lie, but I could totally see someone adding some code to this project to accept UDP on a MAVLink port and handle it at a protocol level.

*EDIT* Regarding implementation of other new and random bizarre things on new hardware... that's what I think is awesome. (I think I'm broken)