Hi
I want to do my own flight controller using the mpu-6050 and SPIN, but I new in SPIN and I don´t have any idea how this sensor works
could somebody help me?
is there some library?
First off, Libraries are provided for specific features in C, C++ and so on.
In Spin, you require an OBJECT from OBEX.
In another positng, people have mentioned that an object does exist that will get you started. Basically, you just have to reconfigure it to replace the existing IMU with your preferred one.
Much depends on how much of a beginner you are. You will have to learn to read SPIN and PASM. And there is quite a bit of mathematics to mastering rotational control using Madjwick's work.
Jason Dorie seems to be leading other Propeller users in creating good code for IMUs and recently mentioned some good progress with the MPU-9050.
The MPU-9050 is a 9 DOH device (nine degrees of heading)
The MPU-6050 is a 6 DOH device (six degrees of heading), and easier to code.
This is by no means an easy cut and paste project. One really has to learn several topics in depth to get to a working project. Can you handle that?
When you say you have no idea how the sensors work, that indicates you are starting out with almost no experience or knowledge.
The MPU-6050 is not simple. It has 3 gyros (X, Y, and Z axis) and 3 accellerometers (X,Y, and Z axis). The data from all six sensors is combined to monitor position and rotation. And then there is the communications to and from the Propeller via synchonous serial.
You might start with learning why we have to have both gyros and accellerometers on each axis.
Loopy/Jason,
You two seem to be very active and competent in the IMU field.
Please I ask if you two could help us newcomers with some recommended reading suggestions and/or links to enable us to understand the physics, maths theory and coding behind these devices.
Your suggestion above "You might start with learning why we have to have both gyros and accellerometers on each axis" would be a good starting point!
Many thanks in advance.
I wish I were compitent. Jason Dorie is lightyears ahead of me.
But I might be more helpful as Jason doesn't really chat with complete beginners. But he has generously provided open source code for the Propeller that actually flies quadcopters. This is something I cannot do.
The reason for both gyros and accelerometers is using just one type of sensor will cause drift and other forms of failure. By combining the two and properly filtering each (different filters for gyros and for accelerometers), the drift is eliminated. In other words, each has a strong point and when combined together there is a synergy that makes excellent control.
6 DOH will work nicely, but now we have 9DOH available cheaply. The extra 3 sensors measure magnetic direction (compass) in an X, Y, Z axis. You don't really need the extra 3 sensors to fly with good results. In fact it is easier to learn the 6 DOH code first and then graduate to the 9DOH code. The code example is shorter.
++++++++++++
The problems arise with combining data from all 3 types of devices with 3 axises. A purely mathematical approach of the floating point variety will work, but the results might be very slow updates.
You need about 100 updates per second or better to have time to actually use the data and not crash.
And if you use some math solutions, you can have 'dead spots' that cause something cause 'gimbal lock'. Gimbal Lock means your sensor calculation code locks up in certain situation. That causes a crash.
So the 'holy grail' is to enhance the code to never have Gimbal Lock and to refresh at the fastest possibly rate so that the microcontroller has time for flying the machine, for getting GPS positioning, for handling the camera, and for radio communication with the operator.
In other words, the microcontroller has to juggle a lot of tasks at the same time. Fortunately, the Propeller has 8 microcontrollers that are ideal for juggling tasks.
One of the first ways to optimize is to reduce the number of math operations and to enhance any math operations that eat up a lot of time. The main one that eats time is getting the square root of a number. Generally using floating point eats up a lot of time as well. So either fixed decimal maths, or pure binary integers will run faster. There are some tricks to managing the square root speed ehancement... including using some special maths that avoids calling square roots unless absolutely necessary.
If you can get your heads around all that, I will mention some more advanced stuff and see if I can dig up the websites that explain those topics.
The main thing is that there is Propeller code created by Jason Dorie and improved recently by Dave Hein that is publically available. It might be an easier starting point than a DIY from scratch. Both are savy Propeller masters that are way ahead of myself. I'm just a groupie.
IMO, it's extremely frustrating to have a discussion abandoned to reappear somewhere else. Restarting the discussion on the same topic is a different thread causes duplication of effort as people repeat what had just been explained.
I for one, am much less enthusiastic about contributing to a topic when this sort of thread bouncing occurs.
People just getting started can be overly ambitious and overly enthusiastic. But without the new customer, where would any enterprise be?
I do admit, not understanding I2C indicates a lot of learn before using the MPU-6050 with any microcontroller. I suspect this thread will be a long slow slog for those that really want to learn it all.
I wish I were compitent. Jason Dorie is lightyears ahead of me.
But I might be more helpful as Jason doesn't really chat with complete beginners. But he has generously provided open source code for the Propeller that actually flies quadcopters. This is something I cannot do.
The reason for both gyros and accelerometers is using just one type of sensor will cause drift and other forms of failure. By combining the two and properly filtering each (different filters for gyros and for accelerometers), the drift is eliminated. In other words, each has a strong point and when combined together there is a synergy that makes excellent control. . . . . . . . . . . .
Thanks Loopy, was the best summary I have seen on the IMU control problem. Any additional links and explanations from you and other is greatly appreciated.
That is the HoverFly Gimbal and I own two of these. I do not own the MCP-6050.
Everyone is a bit confused at the begining as there are various IMUs available. And the MCP-6050 and MCP-9150 have some special features that the others do not.
The problem with those special features is that the manufacturerer desires to keep them proprietary and what code is available a lump -- it isn't explained. A lot of Arduino users are using the 'lump of code' approach, without every learning more detail.
The same MCP-6050 or MCP-9150 can by-pass the proprietary solution and just act as generic senors with the Propeller. That is the way Jason Dorie's code can be adapted to the MCP-6050. Jason Dorie has also done some recent work with the MCP-9150 and seemed able to exploit both the proprietary code and some of his work --- but he hasn't share the Propeller code with us.
So the majority of what you will have to work with starts with Jason Dories' work that became public in 2011. And was revived in Parallax Forum discussions last year. This won't try to hack into the MCP-6050 proprietary features, but works quite well without doing so.
It's not so much that I *don't* chat with newbies, it's just that I'm not on here as much as I used to be. :-)
I haven't gotten a 9050MPU working completely yet - At the moment, I'm using data from independent sensors and fusing them together myself to get a good estimate of the orientation of the board. From there it's still quite a good ways to getting stable flight - knowing your orientation is only part of the problem.
The MPU-6050 has the ability to upload code to it to handle the sensor fusion for you. It takes all the readings, does the hard math, and spits out a quaternion that is the orientation estimate. There are a few Arduino implementations out there already that do this, so if there isn't one for the Prop, it likely wouldn't be too hard to port it over.
From there you still have to know enough math to "degrees away from level" for both axis and feed that into your PIDs. It does not handle compass readings for you, so if you want heading lock you'll have to fuse that in yourself.
Loopy is right - It's not a small project. Basic stable flight is pretty easy. Self-leveling flight is quite a lot harder.
He talks about some of the technical details of building a quad, starts with an existing board but reprograms it. It's Arduino based, but the problems are all the same.
Then, going to a fully orientation aware quad, you'll need some reasonably serious math. Most solutions use quaternions, but the DCM stuff is probably a little easier to wrap your head around to start with:
This goes into specifics on using a Direction Cosine Matrix to store orientation, but it also gives a good introduction to the reasons for needing to maintain a rotating frame, some of the math shortcuts, and so on.
All the stuff I had working was based on my QuadX code for the HoverFly Sport/Open, with my DCM code added to it to get orientation estimate. It did all the DCM work on its own, not using the sensor fusion stuff from the 6050. (I was using a separate gyro and acceleromer). I had a propeller break in mid flight, and the flying bits sheared a bunch of electronics off the board and crashed the quad. I haven't built up another one yet since then, but I've been working on improving the DCM code and making it faster, as well as playing with the PIDs and orientation stuff in a balance-bot. The principles are identical, but the code is a little simpler and crashes don't cost nearly as much.
Loopy, Jason,
Thank you for your time and generosity in donating some of your hard-earned knowledge.
I will plow through your links and notes see if I can make a start in this field.
Comments
In Spin, you require an OBJECT from OBEX.
In another positng, people have mentioned that an object does exist that will get you started. Basically, you just have to reconfigure it to replace the existing IMU with your preferred one.
Read here===> http://forums.parallax.com/showthread.php/146167-MPU-6050-Gyro-Accelerometer
Much depends on how much of a beginner you are. You will have to learn to read SPIN and PASM. And there is quite a bit of mathematics to mastering rotational control using Madjwick's work.
Jason Dorie seems to be leading other Propeller users in creating good code for IMUs and recently mentioned some good progress with the MPU-9050.
The MPU-9050 is a 9 DOH device (nine degrees of heading)
The MPU-6050 is a 6 DOH device (six degrees of heading), and easier to code.
This is by no means an easy cut and paste project. One really has to learn several topics in depth to get to a working project. Can you handle that?
When you say you have no idea how the sensors work, that indicates you are starting out with almost no experience or knowledge.
The MPU-6050 is not simple. It has 3 gyros (X, Y, and Z axis) and 3 accellerometers (X,Y, and Z axis). The data from all six sensors is combined to monitor position and rotation. And then there is the communications to and from the Propeller via synchonous serial.
You might start with learning why we have to have both gyros and accellerometers on each axis.
You two seem to be very active and competent in the IMU field.
Please I ask if you two could help us newcomers with some recommended reading suggestions and/or links to enable us to understand the physics, maths theory and coding behind these devices.
Your suggestion above "You might start with learning why we have to have both gyros and accellerometers on each axis" would be a good starting point!
Many thanks in advance.
But I might be more helpful as Jason doesn't really chat with complete beginners. But he has generously provided open source code for the Propeller that actually flies quadcopters. This is something I cannot do.
The reason for both gyros and accelerometers is using just one type of sensor will cause drift and other forms of failure. By combining the two and properly filtering each (different filters for gyros and for accelerometers), the drift is eliminated. In other words, each has a strong point and when combined together there is a synergy that makes excellent control.
6 DOH will work nicely, but now we have 9DOH available cheaply. The extra 3 sensors measure magnetic direction (compass) in an X, Y, Z axis. You don't really need the extra 3 sensors to fly with good results. In fact it is easier to learn the 6 DOH code first and then graduate to the 9DOH code. The code example is shorter.
++++++++++++
The problems arise with combining data from all 3 types of devices with 3 axises. A purely mathematical approach of the floating point variety will work, but the results might be very slow updates.
You need about 100 updates per second or better to have time to actually use the data and not crash.
And if you use some math solutions, you can have 'dead spots' that cause something cause 'gimbal lock'. Gimbal Lock means your sensor calculation code locks up in certain situation. That causes a crash.
So the 'holy grail' is to enhance the code to never have Gimbal Lock and to refresh at the fastest possibly rate so that the microcontroller has time for flying the machine, for getting GPS positioning, for handling the camera, and for radio communication with the operator.
In other words, the microcontroller has to juggle a lot of tasks at the same time. Fortunately, the Propeller has 8 microcontrollers that are ideal for juggling tasks.
One of the first ways to optimize is to reduce the number of math operations and to enhance any math operations that eat up a lot of time. The main one that eats time is getting the square root of a number. Generally using floating point eats up a lot of time as well. So either fixed decimal maths, or pure binary integers will run faster. There are some tricks to managing the square root speed ehancement... including using some special maths that avoids calling square roots unless absolutely necessary.
If you can get your heads around all that, I will mention some more advanced stuff and see if I can dig up the websites that explain those topics.
The main thing is that there is Propeller code created by Jason Dorie and improved recently by Dave Hein that is publically available. It might be an easier starting point than a DIY from scratch. Both are savy Propeller masters that are way ahead of myself. I'm just a groupie.
http://forums.parallax.com/showthread.php/159885-help-I2C-in-SPIN
Below is a link to another thread on this topic (no discussion though).
http://forums.parallax.com/showthread.php/159910-HELP-MPU-6050-AND-PROPELLER-SPIN
IMO, it's extremely frustrating to have a discussion abandoned to reappear somewhere else. Restarting the discussion on the same topic is a different thread causes duplication of effort as people repeat what had just been explained.
I for one, am much less enthusiastic about contributing to a topic when this sort of thread bouncing occurs.
I do admit, not understanding I2C indicates a lot of learn before using the MPU-6050 with any microcontroller. I suspect this thread will be a long slow slog for those that really want to learn it all.
Thanks Loopy, was the best summary I have seen on the IMU control problem. Any additional links and explanations from you and other is greatly appreciated.
http://forums.parallax.com/archive/index.php/t-157270.html
That is the HoverFly Gimbal and I own two of these. I do not own the MCP-6050.
Everyone is a bit confused at the begining as there are various IMUs available. And the MCP-6050 and MCP-9150 have some special features that the others do not.
The problem with those special features is that the manufacturerer desires to keep them proprietary and what code is available a lump -- it isn't explained. A lot of Arduino users are using the 'lump of code' approach, without every learning more detail.
The same MCP-6050 or MCP-9150 can by-pass the proprietary solution and just act as generic senors with the Propeller. That is the way Jason Dorie's code can be adapted to the MCP-6050. Jason Dorie has also done some recent work with the MCP-9150 and seemed able to exploit both the proprietary code and some of his work --- but he hasn't share the Propeller code with us.
So the majority of what you will have to work with starts with Jason Dories' work that became public in 2011. And was revived in Parallax Forum discussions last year. This won't try to hack into the MCP-6050 proprietary features, but works quite well without doing so.
Most of Jason Dorie's public information is at DIY Drones. So you should visit that site as well as the 2014 thread about the HoverFly Gimal. http://diydrones.com/profiles/blog/list?user=2tm559odsmhka
I haven't gotten a 9050MPU working completely yet - At the moment, I'm using data from independent sensors and fusing them together myself to get a good estimate of the orientation of the board. From there it's still quite a good ways to getting stable flight - knowing your orientation is only part of the problem.
The MPU-6050 has the ability to upload code to it to handle the sensor fusion for you. It takes all the readings, does the hard math, and spits out a quaternion that is the orientation estimate. There are a few Arduino implementations out there already that do this, so if there isn't one for the Prop, it likely wouldn't be too hard to port it over.
From there you still have to know enough math to "degrees away from level" for both axis and feed that into your PIDs. It does not handle compass readings for you, so if you want heading lock you'll have to fuse that in yourself.
Loopy is right - It's not a small project. Basic stable flight is pretty easy. Self-leveling flight is quite a lot harder.
For reading, start with this:
https://ghowen.me/build-your-own-quadcopter-autopilot/
He talks about some of the technical details of building a quad, starts with an existing board but reprograms it. It's Arduino based, but the problems are all the same.
Then, going to a fully orientation aware quad, you'll need some reasonably serious math. Most solutions use quaternions, but the DCM stuff is probably a little easier to wrap your head around to start with:
http://gentlenav.googlecode.com/files/DCMDraft2.pdf
This goes into specifics on using a Direction Cosine Matrix to store orientation, but it also gives a good introduction to the reasons for needing to maintain a rotating frame, some of the math shortcuts, and so on.
All the stuff I had working was based on my QuadX code for the HoverFly Sport/Open, with my DCM code added to it to get orientation estimate. It did all the DCM work on its own, not using the sensor fusion stuff from the 6050. (I was using a separate gyro and acceleromer). I had a propeller break in mid flight, and the flying bits sheared a bunch of electronics off the board and crashed the quad. I haven't built up another one yet since then, but I've been working on improving the DCM code and making it faster, as well as playing with the PIDs and orientation stuff in a balance-bot. The principles are identical, but the code is a little simpler and crashes don't cost nearly as much.
Thank you for your time and generosity in donating some of your hard-earned knowledge.
I will plow through your links and notes see if I can make a start in this field.