Thread Tools
Aug 16, 2019, 02:26 PM
Registered User
Dear Olli,

Quote:
Originally Posted by OlliW
yes, you argue correctly, the rx line should be high in idle phases, since the modules keep their tx in hiZ unless they transmit and the pullup should pull the level to high.
You comment is very helpful and now we can investigate the case properly. It happens with just one main board, so looks like poor soldering is the reason.

Thank you for prompt response!
Sign up now
to remove ads between posts
Aug 16, 2019, 02:32 PM
OlliW
Thread OP
T-STorM32 cannot be used currently for 2 axis, only for 3 axis gimbals. There is no workaround. This might change in future, I have that in my list, but I don't have or give any ETA.

I agree it's somewhat unfortunate that the GUI shows Encoders: --- instead of Encoders: ok ok -. I will see if I can change that.
Aug 17, 2019, 12:51 AM
Registered User
Quote:
Originally Posted by OlliW
T-STorM32 cannot be used currently for 2 axis, only for 3 axis gimbals. There is no workaround
Well... can you please comment on the following:

1. Are there any commands on NT bus to set target motor to particular angle? Like “go to angle X degrees”? Or “rotate to angle Y with speed Z”? Or “rotate CW with speed Z”? Then we can use roll/pitch angles from our flight controller (it knows frame attitude in relation to ground in any moment) and send commands to roll/pitch motor units on NT bus to maintain horizontal level. In our particular case we even do not need smooth motions and exact targeting of camera unit, instead, we need horizontal level within +/- 1 degree only while drone’s frame floats within 10 degrees max during landing. I feel direct control of motor units can solve our problem while you will have 2D solution somewhere in future. This way also does not require any disclosure of your know how. Any useful advice here is highly appreciated...

2. Assuming that gimbal has three motors, are there any modes then YAW angle is locked? It could be a worst case for us as we need to add another heavy motor unit with extra arm but it could be quick and dirty temporary solution for us. We need camera heading matches drone’s heading always.

Thank you for any useful feedback
Aug 17, 2019, 02:03 AM
OlliW
Thread OP
1. yes, there are of course such commands
for a somewhat outdated description (doesn't has TSTorM32 stuff) see http://www.olliw.eu/storm32bgc-wiki/NT_Bus_Protocol, gives you an idea at least

in conventional NT mode this would directly set the motor angle (however, in that mode you can use it also as gimbal)

however, in T-STorM32 mode, the NT command sets the speed of the motor !!!! So you can't just use the roll/pitch angles from the controller, but would have to set up some sort of control feedback loop yourself. E.g., you could readout the motor angle with another NT command, and that way build a servo loop.

I would not think however that you will be able to do that fast, and it might be that by the time you've done that I did the 2 axis mode ...

2. no, there is no such mode currently ... note that what you suggest is nothing else than again a 2 axis gimbal, so its kind of redundant question and answer
The point in 3-axis vs 2-axis is NOT the one axis, but that the math is totally different, with yaw fixed the math would be equal to that for a 2 axis, right
Aug 17, 2019, 04:21 AM
Registered User
Quote:
Originally Posted by OlliW
2. no, there is no such mode currently ... note that what you suggest is nothing else than again a 2 axis gimbal, so its kind of redundant question and answer
The point in 3-axis vs 2-axis is NOT the one axis, but that the math is totally different, with yaw fixed the math would be equal to that for a 2 axis, right
Actually, it is not the same... I clearly understand how projection from one coordinate system to another works. If we are not restricted in position of base frame, two degrees of freedom is just not enough to keep gimbal both horizontal level and a particular heading in it, it's just a math fact with three degrees of freedom (with three motors) all is fine. So, 3D gimbal with three active motors are good to maintain horizontal level and a heading in it (as way as any other plane and direction in it). Even some cheap gimbal sticks do that right from the box - trying to smoothly point camera in direction of motion.
With 2D - it is just not possible. But if we are trying to compensate relatively small inclinations from horizontal plane ( that is usual case for heavy lifters without any acrobatic abilities) 2D is just enough.

Regarding NT bus:
Yes, I have read wiki before posting, but that page does not give a clear understanding of two aspects:

- how to read encoder value from motor board? Can you post template or struct of commands that request encoding and description of response

- what is actual command to set rotation speeds for latest T-STotM32 motor boards with encoder

- any remarks on units of values will be helpful as well

You are right, it will take time! But we have to do that one way or another. I can send you some photos of our unit if you like to see. Probably, they can slightly push you in direction of 2D option

I appreciate any help, if it needs support or donation of any kind, please leave me PM

Thanks
Aug 17, 2019, 05:21 AM
OlliW
Thread OP
when the yaw axis is made to stay fixed with the vehicle the math either way is 2 D since only two motors are stabilized ...

while thinking about it one could use ultra stiff pan on yaw as a sort of workaround ... might work sufficiently ok ... but as you said the extra motor is a drawback

yes, as indicated, the NT bus communication wiki is somewhat behind .. have to update it some day, ... it's at time thing though, have too many other things on my list of interests ... I might be faster adding 2 axis than updating the wiki ...

let's see

it's always interesting to know what people use STorM32 for ... so you are highly welcome to post some pics here
Aug 18, 2019, 03:57 AM
Registered User
Olli, you are the God of gimbal community full of kind devotees - real hostages of your personal list of interests It's a real drawback of "open hardware - closed software" paradigm. But we were informed! Do hope, you will have 2D option available still this year!
Anyway, thank you for prompt comments
Aug 18, 2019, 02:55 PM
OlliW
Thread OP
just to let you know, I've looked at the issue and the controllers seem fine, I "just" need to make the encoders available for non-3-axis situations ... this however sounds easier than it is since it needs getting all the possible situations and conditions right ... anyway, the bottom line is I've put this up on my list, wanted to do it anyhow at some point ... I expect the next alpha version to have it
EDIT: nt bus info is updated

as regards "It's a real drawback of "open hardware - closed software" paradigm", there are plenty of open source 2-axis and 3-axis gimbal codes available ... it just needs a bit of easy googling to find them ... if that serves you better don't hesitate to choose these .
No one, and really no one, is a hostage of me. There are plenty of options and anyone is free to chose. For me it was a good decision, it has worked very well for me
Last edited by OlliW; Aug 19, 2019 at 02:16 AM.
Aug 19, 2019, 04:51 PM
Registered User
Olli, thank you for updating protocol spec! I definitely need to study it carefully.
Today we have prepared own software for motor boards with Angle encoder readout, space vector modulation for center aligned PWMs and PID controller with some LPF built in. Each board can maintain requested angle and even reduce current if angular error is small to minimize heating. Our tests show that D component can be ignored and PI controller is well enough. We use 2804 kv100 motors @ 12Vdc. Is your experience the same with well balanced hardware? Tests with camera unit were planned for tomorrow but if your protocol is clear and reasonable, we will stop inventing bicycle and will use product you are creating last N years! I am sure you spent a lot of time on proper processing of different edge conditions and exceptions.
Once again, thank you for update!
Last edited by Robotopia.eu; Aug 19, 2019 at 05:14 PM.
Aug 19, 2019, 05:10 PM
Registered User
Olli,
We are still fighting with RX line of NT bus as I have mentioned above. Looks like Ensys IMU module RIP... (if replaced by spare one than system works fine, if connected to good spare main board, that main board fails) really sad experience with a product that fails in virgin lab conditions even... poor or absent static discharge protection could be a reason. We cannot use it in our product because of that... can you recommend more reliable IMU for your NT bus if any?
Aug 19, 2019, 05:10 PM
OlliW
Thread OP
since you have already some working code you probably will rather want to go with it, I guess it's at least what I would do if I were you
I found D to be helpful, it however gives issues with the low resolution when simple differencing is used, so it can be better to not use it. If PI works for you, go with it. You said you don't need high stability.
in view of your "real drawback of "open hardware - closed software" paradigm" you surely will open source the code, right LOL
my code isn't perfect, I still see several points I could (want to) improve


EDIT: imu: I just know the sources mentioned in the wiki, and I generally do not make recommendations as regards other's offers. Since you did build your own motor modules I would think you wouldn't find it hard to also build your imu modules. If you are sure that it's the imu, you also could contact Ensys, from what I know they always had been helpful. The v1.3 boards btw have become a source of unreliability lately, obviously Asian cost-"optimization"
Last edited by OlliW; Aug 19, 2019 at 05:17 PM.
Aug 20, 2019, 02:34 AM
OlliW
Thread OP
you can try this: http://www.olliw.eu/downloads/storm3...-v20190820.zip
set yaw usage to disable, and it should work (does for me on the bench)
might still have few glitches, but you'll find them
Aug 20, 2019, 12:21 PM
Registered User
You are right main board v1.3 is not reliable, generates headaches and a lot of heat We adapted latest main board design and it looks like working. We have added DC/DC converter (as our main power is 12S), some protection circuitry and alternative communication channel via CAN.
Preparing own reliable software is not an easy task, you definitely know it! We did proof of concept but it is far from production quality with plenty of open issues (calibration and programming tools, internal docs, QA and so on). There are two key benefits - we own it and we do not need main gimbal board at all because our flight controller can communicate with motor board via either CAN or UART. But gimbal was not on our list of activities and we would prefer using existing stuff rather than wasting expensive resources on creating own one.
Tomorrow I will definitely check your software!
Thank you very much!
Aug 20, 2019, 12:49 PM
Registered User
I have played a bit with own software today and looks like obvious strategy is to convert encoder's angle into electrical angle of BLDC motor (seven periods per one rotation) and then controlling phase offset in required direction. This should create force that moves camera unit into required position. It is aka "FOC" but without current feedback. Preliminary tests show that motor acts like a spring... I like it more than what we have got with controlling speed. So, I wonder why your latest NT bus protocol delivers angular speed rather than absolute angular position (if I got it right from your comments above)... Are there any real advantages of using speed rather than absolute angle?

Second question is about bus itself. I clearly understand why i2c is a bad option, but why have you switched to logic level UART? CAN, RS485 or LVDS drivers are quite cheap and offer much higher reliability, . Also, 5V wire looks spare. Looks like you recommend use it on last node for delivering power to IMU unit. But why not uniform solution with four wires only?
Aug 20, 2019, 03:52 PM
OlliW
Thread OP
you'll find a long exploit on TSTorM32's encoder motor drive in the first posts

I can't see a single significant advantage of CAN etc over UART, but lots of disadvantages. I can't see a reason why a imu or motor would be 10m away from the controller.

you really can do the powering as you want, just design your electronics accordingly


Quick Reply
Message:

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Cool T-STorM32: The best STorM32 ever !? OlliW Multirotor Drone Talk 2 Feb 21, 2017 05:02 PM