Talk:Getting Started: Difference between revisions

From STorM32-BGC Wiki V1
Jump to navigation Jump to search
No edit summary
No edit summary
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Okay, getting closer. But your IMU example does not match mine. I as well have the dot left bottom, I as well look at the camera from the bottom (so that "right" is on the wrong side, but my index no is 15, in your example it is the zero. So either we change the index numbers or we assume the IMU was mounted on top of the camera and the right arrow is pointing to the right.
Oh fu**. Then change the UI back to what it was.


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


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


I'm not sure I get exactly what you say, but the "old" picture describes a different situation than seen in your setup photo.... in your photo one is looking at the camera FROM BELOW while in the "old" picture one is looking at the camera FROM ABOVE (I guess I said this before ;))... the "right" is correct and no index number needs to be changed, it's just this different perspectives... maybe have a look at Greg's addition to this figure in the rcg thread... I'll provide you with some additional figures


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


Understood but I find it confusing. I would still not be able to relate this picture to my concrete example. What should we do?
== STorM 32-BGC as a hand held brushless gimbal ==


->
Hi,


Not sure what to do. I'll send a new picture with an explicit photo of a camera instead of the blueish scheme, I would hope that this avoids at least missreading it. I have my doubts though that this by itself would simplify relating things or remove any confusion. Ideally you would figure out what it exactly is what makes you confused and makes you not to be able to relate the pictures.
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 think the basic problem is that it's not everyone's cup of tea to relate coordinate axes seen from different perspectives. I.e. one photo shows a camera from below, the next from above, the next from the front etc. etc.


I could imagine if one would stay within one perspective things might get simpler. In fact, I tried to aid the user into this with the grey axes labeled front, right, up shown in the GUI window. Following up on this I could suggest the following general recipe. Look at your camera from the front, i.e. directly into its lens. Then the meaning of the grey axes and their relation to the camera should be obvious. Now, still looking at your camera from the front, identify in which direction the IMU's z axis points to. It can only be one of six cases: it can point towards you, away from you, to the left, to the right, to the top, or to the bottom. Sounds fairly easy to me. Next, still looking at your camera from the front, do the very same for the x axis. What do you say?
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?  


PS: maybe the figure with teh many configurations should be totally removed


->
P.S


Frankly I find the current method to most easy one.  
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!
The z-axis does grow out of the IMU chip, so where does it point to? It points down in my example.
The x-axis can be seen on the board but is the one pointing in reading direction (from the white dot left to right in the direction of the printed text on the chip), it points forward.
Done.


Your image I find confusing. How about that change?


The last thing I find confusing is where the camera right side is. I would have thought that if I hold the camera in my hand for shooting, the right hand side would be to the right. But be it as it is, at least it is not confusing anymore with all the examples, especially the coordinates (front/right) you have added to my picture.
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.


just have seen your new IMUorientation figure... yes, that's what I had in mind too... I only would also remove the camera figure, so that this figure is generally valid
OW


your comments however gave me another idea. One equally well could turn my above suggestion around, namely instead of looking at the camera from a given perspective and determine the orientation of the IMU one also could also look at the IMU module with a given perspective and determine the orientation of the camera!!
Hi Olliw,
so, a recipe could go as follows:
Look straight at the top of your IMU module, such that the x axis arrow points to the right. The dot on the IMU chip should be in the left top corner.  Now, still looking at your IMU from atop, identify which face of your camera you see. It can only be one of six cases: you can see the front, the back, the right side, the left side, the top or the bottom. How the story goes on for the next setting I have to think briefly about... but you may see what the point is


left and right depend on the perspective, if you look at your camera the right is the opposite to when you hold your camera in shooting position
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
maybe all this would be easier if one just would refer with the axes to the situation where on holds the camera in shooting position?
the yaw and pitch motor swop roles. Hmmm that is a pity, maybe writing the code for that could be the next challenge ;).
 
->
 
I believe we are getting closer. I like the idea of holding the IMU in one position and then describe the camera.
If you would change left/right in the doc because of the more natural "shooting position" point of view, we would need to change the GUI as well. Something I'd shy away. In that case I would align the documentation to the current reality only.
 
Do you want to make the changes in the docs?
 
->
 
Both the IMU perspective and the right/left thing will need changes in the GUI, and accordingly in the docs... before we jump to the docs let me first change the GUI and let us see in what this results... then everything else will unfold by itself
 
I like the new ideas. Thanks for your contributions!
 
PS: to do the IMU perspective thing, I consider using photos of an actual camera and to blend it into the axis thing in the IMU configure tab...
 
->
 
hey Werner,
things are not that easy, hence a question before I go into lengthy but fruitless programming
I played with this scheme:
- look at the camera such that the top of the MPU module points at you
- first set which face of the camera is seen: front, back, top, bottom, left, right
- finally set the orientation of the MPU module: x axis points right, x axis points down, x axis points left, x axis points up
I planed to put pictures of the respective situation in the GUI, for the MPU module I did this, and it are basically the sequence of four pictures which are seen in the Apendix.
Sounds good. BUT: I'm not sure I like that, I find this quite clumpsy.
E.g. the first step sounds easy, but it isn't since it can (and will) happen that the MPU module is then behind the camera! You see, the "issue" here is that it can happen that MPU module is mounted such that the top is face to face with the camera, it doesn't always have to be like in your setup (e.g. in my setup it's not like that).
Also, the second step may require you to think around the corner...
What do you say? Suggestions?

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"