Talk:Getting Started: Difference between revisions

From STorM32-BGC Wiki V1
Jump to navigation Jump to search
No edit summary
No edit summary
 
(27 intermediate revisions by 3 users not shown)
Line 1: Line 1:
In my opinion the original text for the IMU orientation was correct, the example image was not.
Oh fu**. Then change the UI back to what it was.
Take the first example, the dot is at the left bottom, hence the y-axis points to the left. Correct. But the x-axis is drawn to point upwards, originating in the white dot instead of ending there.


----
Just kiddin'. I'll update the screenshots and text once it is out.
On every MPU6050 chip (STorm32BGC or breakout module) you can find a little dot (white point) in one corner.
This dot shows the direction of the y axis (the corner shows to the end of the y line, its not the origin).
The x axis is always face to face to the y axis, diagonal (the corner shows to the end of the x line, its not the origin).
To better understand this inspect the schematics in the middle of the picture below, where the y axis (white dot) points to the up-right, and the x axis to the down-right. The z axis is always points away from the face of the chip. Now it is easy to get the right GUI settings.


Example: The IMU is on top of the camera and the white dot on the chip is, when looked at the camera from the font, showing to the left and to the roll axis. Then the IMU gui setting is no.1 (z axis points up / x axis points right).
Was about 6 hours of work, not including the break.


Further examples are treated in this picture:


[[File:Mpufinal.jpg|800px]]
O:
----
ja, tut mir leid ... aber ich denke dass das neue Tool gut ankommt ... hoffe ich zumindest
ich frage mich auch ob es nicht vielleicht "besser" wäre ein Video zum Gimbal Tool zu machen ... das 6-punkt video macht ja schon vieles schnell klar was vermutliche vieler Worte und Bilder bedurft hätte


I am not sure about the printed arrow. Why is on my board the arrow pointing upwards but the dot on the chip at the bottom? Same with your screenshot above. I would think there is an inconsistency.
== STorM 32-BGC as a hand held brushless gimbal ==


****************************************************************************
Hi,
Hey Werner
the figure is absolutely correct, as well as your print ons on your board


if you would dismantle your MPU module you would see that below the screw head there is another arrow labeled y, which point EXACTLY into the direction which you dtermine with your edge and direction thing!
I am new to gimbals and online wiki's etc. so I am not sure where to ask questions or for advice. I figured since this page is under the discussion tab that this would be a good place to start.
please note that for your situation the z axis points down and the x axis points to the front, hence you should have no.15, and NOT no. 13. Indeed, from what you wrote initially, namely that with tilting the camera up the Pitch angle should get more positive, I conclude that you got a wrong no. since it in act should be that with tilting the camera DOWN you should get more POSITIVE Pitch angles.
Here goes nothing, I have been building a hand held brushless gimbal as an action research project for my Btech degree. I based the frame design on the Letus Helix jr. because I thought it is
In fact, if you just compare the two figures with Gui and your camera, then you immediately can see that in the GUI figure the x axis (the green line) points to the BACK while in your camera foto the x axis (=x arrow) points to the front of the camera.
the most compact and practical design. After facing many problems and overcoming them through trial and error I eventually ended up with a functional hand held gimbal. The only thing that
I am not able to do is hold the gimbal as if it is a suitcase (as seen in this video made by No Film School https://youtu.be/A1Uwr_sLVBs). The closest I have come to making the gimbal work
in this position is by switching off the onboard (second) IMU, which I have mounted to the handle. Therefore I believe that the gimbal does not work when you hold the gimbal in this position
because you are basically swopping the roles of the yaw and pitch motors (the yaw becomes the pitch motor and vice versa) and so the gimbal freaks out because it is not able to comprehend
what is happening.


the confusion expressed in your first statement comes from the fact that in the photo above one is looking at the camere FROM ABOVE while in your photo you're looking atthe camera FROM BELOW!


maybe you could PM me photo of your camera showing it from above, and one showing it from below, I would then improve the above figure with a real picture instead of this sketch of a camera, which might help further :)
I would like to know if this is true? Has the board not been programmed to enable it to switch the two motors (since a quadcopter hardly ever banks at 90 degrees)? Or do I have to update the
****************************************************************************
firmware (I have firmware version 80)? Or have I just made a rookie mistake by overlooking a setting of some sort that would allow the gimbal to function in this position?
 
 
P.S
 
I want to thank Olliw and everyone else who have developed this control board and wiki into what it is today. It is a job done excellently!
 
 
Hey,
 
first, in principle this discussion page is an appropriate place for discussions, only that essentially no one is using it and is hence very little frequented - as you may see form the number of discussions here ;). From that point of view, the rcgroups thread is a much (much, much) better place. Maybe you want to move with your question (and follow up discussion) over there.
second, the controller can handle a swap of the yaw and pitch motors, in the "standard" yaw-roll-pitch configuration, but the gimbal in the video doesn't have that configuration, and the code isn't made for that.
 
OW
 
Hi Olliw,
 
Thank you for your follow up. I am glad I came to the right place :). I will have a look and see if I can join the rcgroups thread as well though. Ok I understand, when a gimbal with the  standard
configuration (yaw-roll-pitch) is held in that position the yaw and roll motors swop roles but when a gimbal with a pitch-yaw-roll configuration (like the one I have chosen to build) is held in that position
the yaw and pitch motor swop roles. Hmmm that is a pity, maybe writing the code for that could be the next challenge ;).

Latest revision as of 20:46, 30 September 2015

Oh fu**. Then change the UI back to what it was.

Just kiddin'. I'll update the screenshots and text once it is out.

Was about 6 hours of work, not including the break.


O: ja, tut mir leid ... aber ich denke dass das neue Tool gut ankommt ... hoffe ich zumindest ich frage mich auch ob es nicht vielleicht "besser" wäre ein Video zum Gimbal Tool zu machen ... das 6-punkt video macht ja schon vieles schnell klar was vermutliche vieler Worte und Bilder bedurft hätte

STorM 32-BGC as a hand held brushless gimbal

Hi,

I am new to gimbals and online wiki's etc. so I am not sure where to ask questions or for advice. I figured since this page is under the discussion tab that this would be a good place to start. Here goes nothing, I have been building a hand held brushless gimbal as an action research project for my Btech degree. I based the frame design on the Letus Helix jr. because I thought it is the most compact and practical design. After facing many problems and overcoming them through trial and error I eventually ended up with a functional hand held gimbal. The only thing that I am not able to do is hold the gimbal as if it is a suitcase (as seen in this video made by No Film School https://youtu.be/A1Uwr_sLVBs). The closest I have come to making the gimbal work in this position is by switching off the onboard (second) IMU, which I have mounted to the handle. Therefore I believe that the gimbal does not work when you hold the gimbal in this position because you are basically swopping the roles of the yaw and pitch motors (the yaw becomes the pitch motor and vice versa) and so the gimbal freaks out because it is not able to comprehend what is happening.


I would like to know if this is true? Has the board not been programmed to enable it to switch the two motors (since a quadcopter hardly ever banks at 90 degrees)? Or do I have to update the firmware (I have firmware version 80)? Or have I just made a rookie mistake by overlooking a setting of some sort that would allow the gimbal to function in this position?


P.S

I want to thank Olliw and everyone else who have developed this control board and wiki into what it is today. It is a job done excellently!


Hey,

first, in principle this discussion page is an appropriate place for discussions, only that essentially no one is using it and is hence very little frequented - as you may see form the number of discussions here ;). From that point of view, the rcgroups thread is a much (much, much) better place. Maybe you want to move with your question (and follow up discussion) over there. second, the controller can handle a swap of the yaw and pitch motors, in the "standard" yaw-roll-pitch configuration, but the gimbal in the video doesn't have that configuration, and the code isn't made for that.

OW

Hi Olliw,

Thank you for your follow up. I am glad I came to the right place :). I will have a look and see if I can join the rcgroups thread as well though. Ok I understand, when a gimbal with the standard configuration (yaw-roll-pitch) is held in that position the yaw and roll motors swop roles but when a gimbal with a pitch-yaw-roll configuration (like the one I have chosen to build) is held in that position the yaw and pitch motor swop roles. Hmmm that is a pity, maybe writing the code for that could be the next challenge ;).

Retrieved from "http:///storm32bgc-v1-wiki/index.php?title=Talk:Getting_Started&oldid=2762"