Thread Tools
Sep 25, 2014, 04:38 PM
g0t rabb1t?
ABLomas's Avatar
Hello,
having some strange (and probably very easy to fix, i probably forgot something) problem... My setup first:
  • SONY NEX on gimbal, RCTIMER 5010-021-150T for roll/pitch (14 poles), 4108 015-120T for yaw (22 poles). Gimbal was tested previously on EvvGC board, working well (wasn't perfectly tuned and drifting on sudden turns, but balances OK)
  • Witespy board, mounted on gimbal before yaw motor (not moving with roll/pitch, but together with yaw), pins to top (v1.10 F103RC)
  • TinyIMU mounted on bottom of gimbal
  • 2S, 3S batteries
So, replaced EvvGC (used SVentas PLUS firmware earlier) with STorM32, attached motors and tried everything as described in wiki first steps:
  • Flashed v0.43e firmware, configured IMU direction (no.14: -z180° -y -x -z), verified - pitch going up when cam looking down; roll going up when turning cam CW
  • Changed motor settings - 14/14/22 poles, direction AUTO
  • Calibrated Acc (1-point calibration)
So, my problem:
  • When attaching battery, green LED never stops flashing (quote from Wiki: "finally should start with normal operation (the green led goes solid)."). But data window shows "Calibration" and then "LEVEL" in top left corner, so i guess it's OK
  • sometimes board locks up all motors and that's all. All are locked in some position and does not move at all. I can move gimbal in any directions, gimbal stays "fixed" (motors do not spin). After some time all motors are released and starts to spin freely (the same effect as with "disabled motors")
  • Sometimes pitch/roll (never yaw) very slowly spins in big steps. Pitch looks like it's trying to stabilize, but very slowly (one step in ~20 sec) - in right direction, roll is going randomly
  • never saw gimbal working properly, allways one of above variants
I tried to change settings (swap motor direction to normal/reverse instead of auto, change startup motor pos); tried to copy all settings from others who using similar motors (Hexakopter's handheld in wiki), no difference.
Zero I2C errors, real movement is similar to shown at "Data Display" (but do not know what "Control" graph is); board isn't hot, FET's are slightly warm, motors are cold.
What did i miss? ;-)
Sign up now
to remove ads between posts
Sep 25, 2014, 05:12 PM
Registered User
hexakopter's Avatar
Hey ABLomas,

but you turn "on" all motors by using the "normal" setting? I noticed, that all motors aren't set to "normal" when you flash the firmware. And you also set it up without using the second IMU for your first tests, right?

Regards, hexakopter
Sep 25, 2014, 05:20 PM
OlliW
Quote:
green LED never stops flashing ... But data window shows ... "LEVEL" ... i guess it's OK
no, that's not OK, it needs to get beyond LEVEL and reach NORMAL, which corresponds to the green led going solid.
Quote:
sometimes board locks up all motors and that's all.
this happens then the controller detects that it can't complete LEVEL and reach NORMAL within a given reasonable time ... thus, this is just a sideeffect of not getting to NORMAL

so, the diagnosis is that for some reasons your gimbal doesn't manage to level the camrera and get to NORMAL

the past has given a good list of possible reasons:
- motors not enabled
- IMU orientation wrong
- the motors don't manage to move the camera, e.g. because they are to weak (not likely in your case), a wire to the motors or a wire in the motors is broken, becasue of shortcuts of the motors to ground

informative photos of your setup, the settings screen shot, and possibly ea video showing showing the startup alonmg with the Data Display had been very efficient help in the past

Quote:
2S ... batteries
a 2S battery is most likely too small for a nex size gimbal
Quote:
mounted on gimbal before yaw motor (not moving with roll/pitch, but together with yaw)
just for mentioning, for this configuration a 2nd IMU is not supported by the firmware (I'm working on that, but it hasn't big priority)
Sep 25, 2014, 05:42 PM
Registered User
GekoCH's Avatar
hy olli

so finally I received the controller and after one hour it was installed flashed to v043 and working with the first PID settings I tuned.
Now since I come from the AM corner one thing I didn’t found in the config and it is related to the pan for yaw axis.

Currently the setting is now "hold hold pan" and the YAW axis nicely and slowly follows when I yaw etc. And with the YAW Pan value I can speed it up or slow it down HOWEVER where is the Dead band? Does that exist?
So for example I like to have a dead band of +-5° that means that when I YAW 4° either side the YAW axis won’t turn, just holds the position (for example still pointing at the tree even when I slightly YAW left or right). After it reaches 5° or more it starts to YAW back to 5° and less.
I'm probably just too new to the controller but this was the single option I couldn't find and I'm very used to with the AM boards.

Andy
Sep 25, 2014, 10:38 PM
Registered User
@Greg
Well, I can tell you first hand, that Witespy is not shipping the v1.3 board. My order arrived today and it contained the v1.1 board.
I'm not disappointed, but I was hopeful.

@Olli
I would like your opinion on the best budged minded motors to use in a 3 axis, Samsung Galaxy S5 or Iphone 6 plus, gimbal.

Thanks.
Dan(mcg_999)

Quote:
Originally Posted by Greg Covey
The v1.3 board is coming from Witespy. The 2nd IMU is available here but will also become an option when buying the STorM32 board. I even have him planning the HC06 Bluetooth option so people can have it come already soldered.
Sep 26, 2014, 12:55 AM
Registered User
Quote:
Originally Posted by GekoCH
hy olli

Currently the setting is now "hold hold pan" and the YAW axis nicely and slowly follows when I yaw etc. And with the YAW Pan value I can speed it up or slow it down HOWEVER where is the Dead band? Does that exist?

Andy
This was asked earlier in the thread, but there is no deadband for the STorM32. Basically, if you want a dead band, you'll have to toggle between hold/hold/hold and hold/hold/pan :-) Maybe Olli can provide any updates on his thoughts about the deadband feature, particularly now that he's restructured his code to be cleaner. I personally like the deadband feature, especially for flying cameras. The "yaw wiggle" that you see in 2-axis gimbal videos is the main reason I went to a 3-axis gimbal. Once you notice it, you can never un-see it.
Sep 26, 2014, 01:08 AM
Registered User
GekoCH's Avatar
Quote:
Originally Posted by LoneStriker
This was asked earlier in the thread, but there is no deadband for the STorM32. Basically, if you want a dead band, you'll have to toggle between hold/hold/hold and hold/hold/pan :-) Maybe Olli can provide any updates on his thoughts about the deadband feature, particularly now that he's restructured his code to be cleaner. I personally like the deadband feature, especially for flying cameras. The "yaw wiggle" that you see in 2-axis gimbal videos is the main reason I went to a 3-axis gimbal. Once you notice it, you can never un-see it.
Ok thx for the Info and sorry for re-posting since I hadn't enough time to get through the whole thread.
Yeah the dead bad is in my eyes very important I know from my flight with the AM board that I couldn't do the Videos I did without the dead band especially once I flew at 3500 masl where my little copter struggled with the thin air. I got a alot of yaw waggle because of the wind and there the dead band helped a lot to get rid of the yaw wiggle.

Andy
Sep 26, 2014, 01:28 AM
Registered User
Octoberfestsale :-)

http://www.gimbal24.de/storm32-bgc-v...board-mpu.html

59.95 Euros, worldwide free shipping.....
Sep 26, 2014, 01:44 AM
Registered User
GekoCH's Avatar
by the way Olli there is a Bug in the GUI I can't connected to my controller when the com port is at 177 it always tries to open Com17 instead....
There is a problem as soon as the comport is greater then 100.

Andy
Sep 26, 2014, 03:07 AM
g0t rabb1t?
ABLomas's Avatar
Quote:
Originally Posted by OlliW
so, the diagnosis is that for some reasons your gimbal doesn't manage to level the camrera and get to NORMAL
Hmmm, OK, that's a hint.
I removed yaw motor at all and mounted gimbal directly to wooden plate (used for tests). Kept it for few minutes hanging - and hey, it's working (buzzing, heating, but that's due to random settings on board - at least it's trying to stabilize roll/pitch properly, i will tune parameters later)!
Probably some yaw movements prevented proper calibration at startup or something...
I was thinking that "green led" is mistake on wiki and "LEVEL" is final stage, after what i moved gimbal already...
So - yes, all wires are OK, IMU mounting is OK (at least pitch/roll stab is working in correct directions), etc

Just because i did photos already when testing:


Ignore twisted yaw motor wire - yaw is constrained to +/-18° movement on copter - just to compensate sudden movements - such wire is more than enough, it's not 360° system.

So, such board mounting (on moving part) is unsupported with second IMU, right?
Sep 26, 2014, 03:28 AM
OlliW
@mcg_999:
Quote:
Well, I can tell you first hand, that Witespy is not shipping the v1.3 board. My order arrived today and it contained the v1.1 board. I'm not disappointed, but I was hopeful.
what a hope... this was an ANOUNCEMENT!, that there might be one day a v1.3 in the shop ... I'm sure you've ordered a v1.1 and paid for a v1.1 so you ge a v1.1 ... that's how it works

I can't answer your motor question for lack of own knowledge

@GekoCH:
I'll come back to you later in a longer post

@ABLomas:
yes, the gimbal needs to be at rest until the green led goes solid (= NORMAL reached) ... it shoud that even if you hold in hands, but very silently so, of course ... usually you just put it at rest on ground

yes, this board mounting is unsupported for two reasons:

(a) the tilted position (I doubt you find any controller which would handle that) ... but if there would be a strong vote by many STorM32 users I would add this possibility ... which would of course come at the expense of additional paramter values

(b) 2nd IMU below yaw motor ... this is currently unsupported as in this configuration you can't get the full 2nd IMU support but just a strapped down, very limited set of functions ... e.g. the yaw axis can't be stabilized in pan mode etc. pp. ... I just haven't found time yet to focus on that ... but I will ... if it's in the next release or not depends on how quick other things get settled

since with the 2nd IMU below the yaw motor you can't get the best features I would - if I would be you - seriously evaluate if mounting a 2nd IMU above the yaw motor couldn't be an option
Last edited by OlliW; Sep 26, 2014 at 04:03 AM.
Sep 26, 2014, 04:45 AM
OlliW
@GekoCH:
Quote:
there is a Bug in the GUI I can't connected to my controller when the com port is at 177 it always tries to open Com17 instead
haha ... this is well possible, I'm kind of sure that I didn't paid attention to such large numbers I will correct that in the next release ... thx for spotting and mentioning
Quote:
where is the Dead band?
there is no deadband.
I'm willing to rediscuss that, I also admit that in the meantime I much better see its use (francischie's wind video changed a bit my mind). You might guess that it's not missing just because of ignorance. I have two issues with it, first, it's inherently unstable, and second I'm not really seeing what exactly it is supposed to do. Few months back I in fact spend substantial time for that, but the results I didn't liked, so I left it as it is.

First point:
The underlying issue is that the yaw drifts, and that - in contrast to roll and pitch where you can account for that using the accelerometer - there is no real means to correct for that for yaw. Now, I think a yaw drift is serious, especially for aerial applications where you essentially have no means to notice it. I mean, it's just useful to know in which direction your cam is pointing in relation to the copter, but you're losing this over time as the yaw drifts. You can't really compensate for that manually using e.g. a Rc signal, unless you see a piece of the copter in the video as reference. I don't know how AM handles that, from what I read it doesn't handle this at all, i.e., over time the gimbal just forgets where "forward" is.
I don't like that, not at all. I would not want only to be able to readjust the gimbal manually, I would want "forward" just to mean "forward". Now, when yaw is in hold mode there is absolutely nothing one can do, the yaw will drift and so the camera will slowly turn. However, with yaw in pan mode I in fact found a method to correct for the yaw drift, or more precisely, for it's effects (and I'm a bit proud of it). What this means is that then you are in yaw pan mode that the gimbal will NOT forget where "forward" is, it will know forward for ever. It's stable. It will even readjust the yaw to correct values when you had been in hold mode and the yaw driftet away. So, this sounds like a very cool feature. However, in order for it to work, you need to be in pan mode! (obviously, I would say).
In practice this means that you should be in pan mode for as often as possible, and in hold mode only when it's needed. A deadband feature obviously breaks this into pieces: With a deadband you would enter pan mode only when you're outside of the deadband, and then you are in a fast turning situation which doesn't help the pan yaw correction mechanism a lot. In short, with a deadband you just don't give the pan yaw correction mechanism any chance to do it's job, and the result will be what you'll have yaw drift as any other bloody controller.
For that reasons I followed so far the policy to have pan mode as often as possible (but as indicated in the above I also see the downsides).
A bit lengthy, a bit technical, but may be this gave a better insight into my "dead band ignorance".

Second point:
This is much more basic (and you guys might help me out here), I just don't see how the deadband is to work in practice. I perfectly understand you're explanation in the above, it's obvious, but it is by far not sufficient to base a programming on it. As mentioned, I tried to fill the gaps and experimented few days, but then stopped that. The issue I had that I couldn't get a consistent turning speed. But to get into a discussion, let me maybe ask two questions as regards the desired behavior:

1) lock out of dead band:
have cam locked in the deadband, now turn the gimbal such as to bring the cam out of the dead band and pan/follow sets ins. Question: Which orientation should the follow mode follow?
This is a serious question with several implications. One possibility is to let it follow the center of the deadband, another possibility to let it follow the edge of the deadband.
This affects the yaw pan speeds and lock-out behavior drastically. Usually, as that's what feels most natural, the actual follow speed (not what you set in the GUI) depends on the difference angle between cam and gimbal, i.e. a big difference makes the cam to follow faster, a smaller difference to follow its slower, technically that's a 1order behavior like in a low pass filter, the cam smoothly moves towards the target orientation.
With the first option the cam will however follow immediately quite fast when it locks-out of deadband, because the difference is already relatively large (the deadband) ... I did't liked that too much.
With the second option the cam will behave better as regards the lock-out behavior as the difference is measured with respect to the deadband ... but see next point ...

2) lock-in into deadband
have the cam outside of the deadband so that it is in follow mode, and either slow down the yaw turning or to stop it, such as to bring the cam into the deadband. Question: Towards which orientation should the cam move to as its target orientation in hold mode?
Again, this affects the behavior drastically. And again two basic options. One would be to let the cam lock into the position where it was then it entered deadband, another possibility to let it target the center of the deadband and to lock-in where.
The first option would give the smoothest lock-in and also lock-out behavior. However, it would be essentially impossible to correctly orient the cam into the desired orientation, i.e. it would stay at the deadband edge. What I mean is this: When you turn your gimbal and now stop it, then the cam will NOT move towards the center or forward position, but will stay 5° degrees to the left or right (if the deadband is 5°). Is that good????
The second option would bring the cam to the center = forward orientation once the deadband region is entered, that's good

so, to me it seems that one wants to have the first option in the lock-out but the second option in the lock-in ... but both are not identical and hence one gets inconsistent yaw speeds, i.e. this produces a change in the yaw speed, which - to me - feels unnatural (like a cam operator who isn't able to smoothly turn the cam). One could define a kind of crossover region next to the deadband, but hey ... things start to look ugly now, too many if and thens...

So, you see I have troubles to properly define what should actually happen in detail with the lock-out and lock-in transitions. I f I would know what to achieve I could code it, but without knowing what to achieve ... If I would have an AM in my hands I probably would know in few seconds what behavior one would want, but like that, just with words and videos, I somehow don't get it ... my imagination is failing me here Any help is appreciated. Not sure if this post is of any help though LOL.

Olli
Sep 26, 2014, 05:22 AM
g0t rabb1t?
ABLomas's Avatar
Quote:
Originally Posted by OlliW
since with the 2nd IMU below the yaw motor you can't get the best features I would - if I would be you - seriously evaluate if mounting a 2nd IMU above the yaw motor couldn't be an option
It is, for sure. I will re-do entire gimbal at some time (will use those 24 poles dualsky motors, also 360° pitch motor (with slip rings)); but maybe (i read somewhere on this thread) i can just attach one more IMU and use it as "secondary", instead of onboard IMU? This way i could have simple setup - one IMU on moving platform (following NEX movement), board on gimbal frame and second IMU on multicopter frame. No serious rework, no wires around yaw (what is main reason why i do not want to move controller on multicopter)... Possible?
Sep 26, 2014, 05:40 AM
Registered User
GekoCH's Avatar
wow thx for the answer!

Ok I totally get what you wrote, really.
Maybe some more words from my side to explain how I work with the dead band:
All my copters are single man used and I fly them over FPV from a board cam. Additionally I have a Video Processor PiP which lets me see the board cam and at the same time the GoPro footage.
Now when I fly fast forward towards a object (house tree car etc) I first centre the GoPro towards the object with the RC inputs. Then I start flying forward and I try to keep both pictures (board and GoPro) pointing at the same direction. Now when suddenly a wind gust is coming from the side the board cam probably gets out of the centre of the object but the GoPro still points there. Now I start to yaw the copter so that board cam is again pointing at the object.
The result s a super smooth footage on the yaw axis even though the copter might fight with the environment
I could use the hold mode for that but would have to switch back to follow mode as soon as I turn around to fly back other wise the GoPro would record into the wrong direction...
Ok - This you already understood just explained it a bit further.

Now what happens when I reach the corner of the dead band.
Currently the yaw axis then tries to follow the corners of the dead band and stays there once I stoped yawing.
So now for example the board cam is pointing again towards the object after yawing around and looking for something new but the GoPro is at the corner of the dead band. Now I yaw even more to get the corner of the dead band into the centre of the object I like to film and then yaw back so that the board cam is again aligned with the GoPro. OR I use the RC commands to yaw the GoPro to its new centre position.

Since I always use this mode and no hold mode I can’t answer your second question.

PS: It all sounds so complicated if you like Olli we could skype and talk about it, können dann auch in Deutsch redden

Andy
Sep 26, 2014, 05:50 AM
Registered User
subscribed


Quick Reply
Message:

Thread Tools