Thread Tools
Jul 02, 2017, 03:14 PM
Registered User
buckker's Avatar
Hi Olli

Yes, I have a hand gimbal rig. But it's not the same quick release system... So it's not compatible. Only my bigger gimbals work with the hand gimbal rig.

This evening I mounted my Sony A6300 in the encoder gimbal and did the balancing. After that, I did the basig setup. It's really crazy how much power the motors have. After some PID tuning I wouldn't say that the encoder gimbal is more precise than the normal gimbal (on the bench). But the disturbance behavior is much better. But I have to mention that I only do 1 point IMU calibration. I will run the 6 point calibration tomorrow.



Cheers Michael
Sign up now
to remove ads between posts
Jul 02, 2017, 09:07 PM
OlliW
Quote:
Originally Posted by buckker
I wouldn't say that the encoder gimbal is more precise than the normal gimbal
are you comparing to the normal gimbal with or without 2nd Imu activated? For my gimbals I've seen that with encoders it is better than for normal without 2nd Imu, but not as good than normal with 2nd Imu - for bench tests. I think this indicates a much better vibrations handling with encoders, or less vibs in aerial applications. So, the flight tests will be quite interesting.

edit: hopefully you'll use the nt logger
Last edited by OlliW; Jul 03, 2017 at 01:02 AM.
Jul 03, 2017, 12:38 PM
Registered User
buckker's Avatar
Hi Olli

I have some good news and some bad news

Good news: I did this morning the first test flight with the gimbal. It's surprisingly good That means, no micro vibrations and the overall stabilization is very good. I used the stabilized lens but with the lens hood. The lens hood produces a lot of turbulence in the forward flight. But with the encoder gimbal it seems not a problem anymore.

Bad news: The roll axis become a drift after a yaw turn (follow mode)... No clue where the problem comes from. I have to say, that I didn't perform the 6axis calibration of the IMU. The logger is still in the old gimbal . So I have a few things to do

If you like, I can upload the video. But not sure if youtube can handle a 120fps video

Cheers Michael
Jul 03, 2017, 12:53 PM
OlliW
micro vibs: T H I S is indeed good news ... I would go that far and say, that's excellent news

I'm glad - relieved - that all the efforts you're putting into this may pay out for you

roll drift upon yaw: that's totally normal for (i) poorly calibrated imu and/or (ii) not squarely mounted imu ... this you should be able to also see on-ground, when you do e.g. quick 90 turn ... the rule is, one degree of imperfection leads to up to 2 degrees in roll (and possibly pitch) tilt

EDIT: as regards videos: the first who provides video proof will get the "World's first T-STorM32 User" badge (zyawoo just said he had one)
Jul 03, 2017, 02:13 PM
Registered User
buckker's Avatar
I hope I find some time tomorrow to calibrate the imu on all 6 axis and get rid of this problem.

Of course I want the World's first T-STorM32 User" badge The video uploads right now

Cheers Michael
Jul 03, 2017, 02:33 PM
OlliW
a single-point calibration usually fully suffices
Jul 03, 2017, 10:43 PM
Registered User
buckker's Avatar
Here it is:

First Test Flight T-STorm32 (3 min 22 sec)


Cheers Michael
Jul 04, 2017, 12:19 AM
OlliW
well deserved:
Jul 04, 2017, 12:32 AM
OlliW
stability/vibration wise it looks really good
and it's with this hood, which gave you these troubles, right?
I still see some few roll shakes in down-approaches, e.g. starting at 1:25

the roll tilts are - IMHO - very typical for improper imu calibration (or non-square mounting)
it can be easily identified by that it happens during a turn while the gimbal/copter stands (nearly) still at one place, the long turn at ca 1:40 is very characteristic, as said , you should see that also on ground when you turn the copter by 180
what surprises me though a bit is how large the tilt is, this are much more than 10, so the calibration must be really aweful
always at minimum do a single-point

sad there is no NT Logger
it would also be interesting to see how it compares to normal mode

may I ask: what FOV is that camera?

anyway, good job, sir
Jul 04, 2017, 03:24 AM
Registered User
buckker's Avatar
Hi Olli

Hehe, the World's first T-STorM32 User badge is f... awesome I should mill the design in a carbon plate or something similar

at 1:25 the copter is descending. It's nearly impossible to get no shakes.. If we want no shakes, the gimbal should work faster and more precise.

The lens was on 12mm focal lengh. If I'm right this gives us a FOV arount 100 . Maybe a little bit less.

I did a second one point calibration yesterday before the flight. I can't be so bad. I take care to hold the IMU steady (on the table plate) an the mounted it after well aligned in the gimbal.

Cheers Michael
Jul 04, 2017, 04:37 AM
OlliW
Quote:
Originally Posted by buckker
I did a second one point calibration yesterday before the flight. I can't be so bad.
this is then strange ... very strange ... from scratch I'm not sure what to say ... I agree, it's not possible to get it wrong by that much

it's a stupid question, but just let me rule that out: the camera Imu is mounted perfectly aligned with the gimbal?

if so, which I assume, I only can conclude that something with the calibration went wrong

since it's off by more than 10, it should be easily noted in e.g. the data display, i.e., the pitch&roll angles shown there should not be close to zero when you have the camera imu sitting flat. Maybe you could check that. And maybe you also could share your calibration values.

I think you're using an ensys NT imu. Is it one with a factory-installed calibration?
Jul 04, 2017, 12:09 PM
Registered User
buckker's Avatar
I did the 6 point calibration a few minutes ago. The roll axis drift seems to be gone, at least on the ground. Even after a few yaw turns the axis is still in position. I will perform another flight test later. I will keep you updated

BTW, I found a general issue on the storm32 boards in combination with the HC06 bluetooth module. With the most boards the connection breaks up after after a short time. I believe that the onboard voltage regulator are too small.. I have only one board without this problem, I think it's 1.3 board.



Cheers Michael
Jul 04, 2017, 02:23 PM
Registered User
Congratuation!!! The wolrd's first T-STorM32 from DIY user works.
Jul 04, 2017, 02:33 PM
Registered User
buckker's Avatar
Quote:
Originally Posted by zyawooo
Congratuation!!! The wolrd's first T-STorM32 from DIY user works.
Thanks, I hope I will not be the only T-Storm32 user in the future

I'm back from my test flights. To be honest, the T-Storm is really a big step forward. The video quality is amazing. I'm impressed Only the yaw axis makes some problem. But I know this behavior allready. It stops sometimes for a short moment and then it moves further. It can be reduced by setting the yaw pan value to 0.2 or similar.

Unfortunately I can't use my NT logger right now. I miss the connector cable...

Cheers Michael
Jul 04, 2017, 02:43 PM
OlliW
Quote:
Originally Posted by buckker
I'm back from my test flights. To be honest, the T-Storm is really a big step forward. The video quality is amazing. I'm impressed
in light of post #3 I admit I'm surprised, but from what I have seen so far on my own T-STorM32 gimbals I'm not thaaat surprised, but it is certainly very cool to get such a clear statement from an independent trustable source

I guess I have to surrender and admit that I should have went encoders much earlier

Quote:
Originally Posted by buckker
Only the yaw axis makes some problem. But I know this behavior allready.
oh noo, again? I guess we should work to finally get rid of that ... I think with now having reliable info from the yaw encoder it's doable ... but, I guess, it will need real data ... NT Logger data ...

thx for your efforts and support
Olli
Jul 05, 2017, 12:53 AM
Registered User
buckker's Avatar
Hi Olli

If you look on the ground in the data display you maybe think its not better. But in the air, its really better. I believe the behaviour in wind disturbance situation is much better. Also the motors have an enormous torque and stay cool.

For the yaw problem. I never got completely rid of this problem. With some tuning you can reduce this issue to a minimum, but its still there.
I hope to find some time to upload some videos this evening.

Cheers Michael
Jul 05, 2017, 02:00 AM
OlliW
as said, I think I really would need a NtLogger log of a flight showing this yaw "Ruckler" ... at that earlier time I was looking at these videos soo often and intensely, but this - obviously - didn't led me to sufficient insight ... the problem is that I myself never could create that, and from the code I do not see how that should be possible, so, I would need to "see" it in more detail than what videos offer.

as regards the better quality, I know this is asked for quite a lot, but it would be cool if one could compare that directly, i.e. to have a flight with NTLog with encoders and a nearly identical flight with NTLog but with the StorM32 in normal mode (and tuned properly).

this is exactly my point I started trying to make since I saw my first gimbal results ... that in the Data Display it might not look that much better (and in fact worse if compared to normal+2nd Imu activated), but that in air it should be better because it should have higher bandwidth and hence better vibration rejection. I'm happy to hear you confirming this, and very clearly so, as it seems.

If these findings solidify, I think one can conclude that the STorM32 has caught up quite a bit in performance.

It's really amazing how things have developed. I recently watched the video of hexacopter ca 3 years ago, when the STorM32 was quite fresh, and I remember how good folks considered what they saw at this time ... but now, when I'm looking at it, I just see micro vibs all over the place ... expectations have risen enormously in these 3 years. The STorM32 fell behind lately, so it's good that it seems to catch up.

Cheers, Olli


PS: if you need a 2nd NTLogger, I would have a spare lying around
Jul 05, 2017, 02:33 AM
Registered User
Quote:
Originally Posted by buckker
BTW, I found a general issue on the storm32 boards in combination with the HC06 bluetooth module. With the most boards the connection breaks up after after a short time. I believe that the onboard voltage regulator are too small.. I have only one board without this problem, I think it's 1.3 board.
Cheers Michael
I had the same issue. If you have Storm32 serial-connected to flight controller, unplug TX/RX wires on Storm32 before bluetooth usage.
Jul 05, 2017, 03:04 AM
OlliW
you guys want a v3.x board
Jul 05, 2017, 08:23 AM
Registered User
buckker's Avatar
@ Olli

I try to create a flight mission with my hexacopter. The goal is to fly exact the same mission twice. One with encoder enabled and one with encoder disabled. With that we can compare better the performance.


Yaw Problem: Yesterday it was very good visible when the Yaw Pan Value is higher (around 2.0) I did a small yaw turn, then the gimbal moves a little bit and stops. I rotate the copter further, the gimbal starts to move and the stops again. Its like a stop and go This ruins the most footage.. ;-) I hope we find a solution for this

Of course we want a 3.x board

Cheers Michael
Jul 05, 2017, 08:56 AM
OlliW
Quote:
Originally Posted by buckker
I did a small yaw turn, then the gimbal moves a little bit and stops. I rotate the copter further, the gimbal starts to move and the stops again. Its like a stop and go
hm ... isn't this exactly what it is supposed to do ??? I mean, when you stop doing a yaw turn, the camera should eventually stop too ... and after a stop of the yaw turn, how should any electronics be able to anticipate if you are going to do another yaw turn within the next few seconds, or not at all ??? If you do stop-and-go, the camera will also do stop-and-go. somewhat smoothened according to the Pan setting, but stop-and-go.

I really don't understand how it could behave differently, and I can't imagine how AM possibly could do that (I think this is that's underlying statement).

I quickly made a sketch to show that as diagram.
Jul 05, 2017, 12:17 PM
Registered User
buckker's Avatar
Hi Olli

I think about it. Your controller does what he has to do But it's not usable for smooth aerial footage.. So we have to find a way to improve the yaw behavior around the zero position.

I remember that Alexmos needs a very long time to stop the yaw movement (only for the last few degrees). Probably around 30 seconds or something like this. Is it possible to tell the controller, that he should take 30 seconds for the last 2 degrees? or maybe a second expo function the flatten the curve around the zero position?

BTW, here is a video from the yaw behavior:

T-Storm32 Yaw Bug (0 min 12 sec)
Jul 05, 2017, 02:55 PM
Registered User
buckker's Avatar
et voila

T-StorM32 Test Flight (1 min 2 sec)


Cheers Michael
Jul 05, 2017, 09:28 PM
OlliW
yaw:

first, please send me your yaw pan settings!

so, if I understand you correctly, what you want is that you command the copter to do stop-and-go yaw turns, but that the camera should not follow that?

-> if so, I would strongly object the notion that there is a "yaw bug", one also could argue it's a pilot bug

-> seriously, why are you not commanding the copter to do a slow turn when you want to record a slow turn? (this I have to tell was the underlying premise of whatever I was trying to design here)

-> in some sense, if I do get you correct, you actually do not want to have a deadband, you want to have an "outer band" with a relatively fast pan, and an "inner band" with a relatively slow turn, right?

-> this kind of behavior is obtained with Deadband = 0 and an Expo, which makes it slow near zero and fast away from zero; Are you saying that this isn't preventing the stops in slow turns? Or why else isn't this working for you?

-> you do understand that one would not always want this behavior, i.e. that it's a user dependent setting? (e.g. if one wants to point the camera at an object one usually wants the camera to remain pointing at the object, and not to drift in yaw by a few degrees over few 10 secs. Your suggested mechanism would spoil doing that.) The point I made in the above remains true, one can't know what's going to happen next, another short yaw turn to mimic a longer slow turn or a stop, one can't have it both ways, it must be decided by the user.

-> since it's a user choice, wouldn't it be a reasonable approach to have an RC switch, with which to set a very low Pan value and deabdand = 0, whenever you want to do a slow turn?

Quote:
Originally Posted by buckker
I try to create a flight mission with my hexacopter. The goal is to fly exact the same mission twice. One with encoder enabled and one with encoder disabled. With that we can compare better the performance.
that's a fantastic idea. Pl include especially several of those situations which in the past you've seen to produce vibs, such as your decents.

Thx for the last video.
Jul 06, 2017, 03:39 AM
Registered User
buckker's Avatar
Hi Olli

Remember, the pilot never has a bug

I will post my yaw settings this evening.

I can do a slow yaw turn, but if I'm too slow we have the stop and go effect. If I do the yaw turns quicker the problem does not exist.

" in some sense, if I do get you correct, you actually do not want to have a deadband, you want to have an "outer band" with a relatively fast pan, and an "inner band" with a relatively slow turn, right" =>Yes thats absolutly correct. I understand that this mode only make sense for aerial videos. For take some pictures it's not right thing. Maybe you can create a cinematic yaw mode or something like this?

I fear that a yaw deadband of 0 ruins video in straight forward flight. the copter...

Cheers Michael
Jul 06, 2017, 04:06 AM
OlliW
Quote:
Originally Posted by buckker
I can do a slow yaw turn, but if I'm too slow we have the stop and go effect.
that's the key point, I put this statement into question!

I'm arguing that if the yaw turn is slow but consistent (constant rate), when you will get a smooth slow camera turn. From what you were saying in post #220 I concluded that you are not commanding a smooth yaw turn, i.e. that the copter itself is actually doing stop-and-gos.

That's why I think we would need a nt log. It would (with a 2nd Imu installed and its data recorded) very clearly tell us what's going on.

Quote:
Originally Posted by buckker
I fear that a yaw deadband of 0 ruins video in straight forward flight. the copter...
ah, thank you, another good example of a situation there you would want no motion within the deadband.

So, now tell, how should this fit together? On the one hand the gimbal should slowly drift by about 0.1/sec towards a "center" when it is within a deadband but on the other hand it should not drift but stay pointing forward when it is within a deadband. I still don't understand how both should be possible at the same time.

Btw, it is correct that AM has a slow drift in the deadband zone. At least there is a parameter which is said to exactly do that. But as said, with that parameter set, you should also see that drift when you are flying forward.

What I was thinking for a while is to also make use of the yaw RC command, as it is received by the receiver. This would in fact allow one to discriminate between "it is going forward and a deadband should be active" and "it is turning and a soft pan should be active". DJI e.g. uses the yaw RC signal. However, this is not your configuration (and I presume also wasn't it with the AM controller).

cheers, Olli
Jul 06, 2017, 02:46 PM
Registered User
buckker's Avatar
Hi Olli

I see it's not that easy...

I totally agree with you that the yaw turn of the copter is not that smooth. If it would be that smooth, we don't need a 3rd axis on our gimbal

Is it a easy thing do implement a drift in the deadband like alexmos? Just for testing Maybe the problem is solved with this additional feature.

NT Logger and 2nd IMU. Can I only connect the 2nd IMU and everything works for logging? Or do you need to modify your code?

I never used the rc yaw signal for any gimbal functions...

Cheers Michael
Jul 06, 2017, 05:51 PM
OlliW
Hey Michael

don't get me wrong, I'm very interested to improve things if possible, it's just important for me to properly understand the situation, and not to hunt a ghost

it is relatively easy to implement, that's not the point of concern, it's difficult to know what exactly one wants to implement ... for this "drift in deadband" feature I from scratch do see at least to different methods of how to achieve such a thing, there are probably more, but they won't behave identical, so on

not sure I understand the NTLogger/2nd Imu question, just connect both to the NT bus as usual, set logging to full, and it should work

Cheers, Olli

EDIT: Pl do not forget to share your pan settings
Last edited by OlliW; Jul 07, 2017 at 12:39 AM.
Jul 07, 2017, 06:43 AM
Registered User
buckker's Avatar
Hi Olli

First the yaw settings:

Yaw Pan:0.2
Yaw Pan Deadband: 2.0
Yaw Pan Expo: 80
Yaw Pan Deadband LPF: 1.5s
Yaw Pan Hysteresis: 1.0

I thought with the encoder setup only one imu is usable. But if I'm right you save some time to attach a 2nd imu (but not sure if the update is already there) That's the reason for my question

Cheers Michael
Jul 07, 2017, 06:53 AM
OlliW
thx

one should either use LPF or Hysteresis, not both
I recommend LPF, so pl set Hysteresis to 0
(I don't think this will resolve the yaw stops, but nevertheless one shouldn't use both)
otherwise I think the parameters make sense if one wants to optimize for slow ya turns

with encoders only the data of Imu1 is used for internal calculations, but you can connect two Imus
the raw data of Imu2 is not used for anything but written to the log (it's similar to how it is with Imu3 for the non-encoder setup)

you are using Pixhawk/ArduCopter, right?
If so, I realized, you do already have some crucial info recorded in ArduCopters data logs. So, if you would download the log from that flight you were showing in the yaw-stop video, one could look at (i) the yaw rc input and (ii) the actual yaw angle of the copter. This would tell me already quite a lot about the situation !!!

Cheers, Olli
Jul 07, 2017, 07:42 AM
Registered User
buckker's Avatar
of course I have a data log you will be surprised how smooooooth I control the yaw stick

ok, thanks, I will set the yaw hysteresis to 0

Perfect, then I will print a imu holder for the 2nd one

Cheers Michael
Jul 07, 2017, 07:58 AM
OlliW
excellent!
I will look at it later.
Would there be a way to synchronize the data log with the video in post#222?
(i.e., which value of the timestamp in the log corresponds to the beginning of the video).
Jul 07, 2017, 08:22 AM
Registered User
buckker's Avatar
It about 30s after the first arming (big yaw throttle stick input)
Jul 07, 2017, 01:31 PM
OlliW
hey Michael

I'm looking into the .bin, but I can't really determine where the start of the video is supposed to be

the time axis isn't showing meaningful values, the Line Number seems to be more useful (Mission Planner is great, overall, but sometimes one just can scratch ones head)

I'm looking at AHR2.Yaw, ATT.Yaw, and ATT.DesYaw, anything else I should look at?

cheers, Olli
Jul 07, 2017, 04:13 PM
KD2PBU - Fly No Evil
davidbitton's Avatar
...
Jul 08, 2017, 12:21 PM
Registered User
Hello,

Some hardware question.
See no BOM for motor module v2.4e. What resonator need for this board?
Jul 08, 2017, 09:11 PM
OlliW
for parts you can search here: http://www.olliw.eu/storm32bgc-wiki/...for_NT_Modules
maybe you want to volunteer and add a chapter for the v2.4E modules
Jul 09, 2017, 04:55 AM
Registered User
Thank you.
8 MHz.
Jul 15, 2017, 10:54 AM
Registered User
Why there is 5V rail going to NT modules while there is already VBat ? Why not going from Vbat to 3V3 directly ?

Why V2.4 is deprecated ? Is there a newer version ?
Jul 15, 2017, 11:36 AM
OlliW
well, you can do that, but you have to put a BEC, which can handle the currents&voltage, on each NT module, or somewhere else
(on my first NT motor modules I in fact had bigger BECs on them, but it makes them big)

mainly because of the v2.4's LDOs
v3.x is coming
(I generally like oshpark, but sometimes delivery times are annoying ... the pcbs are due for one week now ...)
Aug 13, 2017, 04:13 AM
Registered User

Hi All


I do see that you are discussing angular sensors like TLE5012B / AS5048A - I use the 01-Mechatronics parts.
Please check their site :
http://www.01mechatronics.com/
Aug 16, 2017, 04:56 AM
Registered User
Hello Olli.

I just would like to suggest one thing. In "Release Note" about new Storm32 2.3 Firmware I didn't find ANY information which encoder is supported. I think You should add this information for people like me who are looking for proper encoder. I have read the topic that it is probably A5048a, but I am not sure. Can You please let me know?

It was the main issue why I did write to You, but not the last. Can You also make little tutorial or just mention how to make "encoding brushless motor" from "non encoding one"? I am not sure what should I do with magnet - is it just placed, glued or adjust with +/- H7/h6 into axis hole?

I do really fight with myself about making own gimball. Information about above would safe a lot of money and time!


Kind Regards,
Arek
Aug 16, 2017, 05:17 AM
Registered User

Latest main board


Hello OlliW,
what is the latest design for main board, I see that 2.4 is deprecated?

Thank you, Marek
Aug 16, 2017, 05:29 AM
OlliW
hey Arek

thx for the suggestion

but I think the "issue" is a bit deeper, it seems obvious to me that you are kind of thinking along what is familiar from the AlexMos/Basecam system, however, the T-STorM32 is different in some crucial aspects. It's probably helpful to forget whatever one knows about AlexMos/Basecam when talking about T-STorM32.

specifically, the question "Which encoders are supported" has a totally different meaning here. The point is that you don't need encoders, but NT encoder-motor modules. Maybe it would be worthwhile to (re)read http://www.olliw.eu/storm32bgc-wiki/...orM32_about%3F, and (re)watch the 2nd video linked there. If that didn't resolve your questions, pl don't hesitate to ask further questions.

Currently, the NT encoder-motor modules use the TLE5012 encoder.

As regards of how to convert a gimbal, a tutorial certainly would be helpful. However, so far the situation is soo much dependent on the particular setup, that I'm not sure what it would be worth it. E.g., in my gimbals I'm using 5 different types of motors, and my solution is very different for each type ... and pl recall that I can only talk about my solutions. Buckker's solution e.g. is so much more professional. Sadly, so far there is no "standard" approach for doing this.

The magnet should be well mounted to the motor axis so as to not slip out of place, just placing it can work for a while (I did that myself) but can't be recommended as permanent solution. Otherwise, any other method which does the job is acceptable.

I guess, here again, if you have more specific questions, pl ask.

BTW: Building a well-working gimbal requires some experience.

Cheers, Olli
Aug 16, 2017, 05:30 AM
OlliW
Quote:
Originally Posted by MGMGMG
what is the latest design for main board, I see that 2.4 is deprecated?
v3.1
not yet officially released though

sneak preview is here: https://www.rcgroups.com/forums/show...&postcount=194
Last edited by OlliW; Aug 16, 2017 at 05:41 AM.
Aug 16, 2017, 07:36 AM
Registered User
Hello Olli,
Thank You for Your answer. To be honest, 2nd movie was the only thing I missed...

Can You tell me where I can find encoder board module, because I do really can not find this thing

Kind Regards,
Arek
Aug 16, 2017, 07:45 AM
OlliW
NT encoder-motor modules are not commercially available
you would have to build them yourself, or find someone who would volunteer to build them for you
Aug 16, 2017, 07:54 AM
Registered User
Ok, so everything is clear right now! Thank You!
Sep 18, 2017, 02:43 AM
OlliW
AS5048A Motor module board discussion:

discussions with mike_kelly and the comments by you guys in here convinced me to do something to support the AS5048A encoders (and to thus make it "simple" to use the available motors with encoders). As I said somewhere earlier, it should be actually not difficult to do, however, some practical aspects are quite unclear to me. I don't have any opinion on them (largely because it's not my use case), so, I would be happy to hear your suggestions.

The two points which would be fix is that we would have one of the available "main board" (e.g. the v3.1)(I'm not going to do a new main board). Also, the motors and encoders would be separate from the electronics, and both the motors and encoders would be connected to the to-be-designed modules (and not the main board). So, we are talking here about the motor modules to be placed "inbetween" the main board and the motor with encoders. For each motor we need a mcu controller and a motor driver, which need to be arranged into the system, and this leaves many choices open. E.g.:

separate motor boards for each motor? or one "big" board with all three?

which motor drivers? the proven DRV8313?

double sided PCB (= more compactness)? single sided PCB (simpler to mount)?

rectangular? square? round?

mounting holes?

plugs?
for the NT bus: 1mm? 1.25 mm JST? Dronecode 1.25mm? for the motors: pin header? for the encoder: pinheader? or else????

spi only for the AS5048A ok? or also support for PWM required?

etc. pp

As example: What I would have in mind (but which will change according to your suggestions) is a rectangular, single sided board for each motor, which each would carry 2 plugs for the NT bus, one mcu and one DRV8313, a 3 pin header for connecting to the motors, and some plug for the connecting the AS5048A via spi

cheers, Olli
Sep 18, 2017, 10:46 AM
Wisconsin
For me personnally and just thinking out-loud. The 3-axis gimbal for the simplist case where you are using the on-board IMU for second IMU needs to be mounted over the yaw motor probably near where the gimbal attaches to the airframe. The advantage of the separate motor modules is the fewer wires need to come up to the through the hollow shaft roll and yaw (slip-ring) motors. The advantage of a single motor driver board is simplicity of manufacture and installation. If it was a single board it might be nice to be the same form factor as the gimbal controller board so they could stack?

For me SPI for the encoders is fine because they are dedicated to this purpose and it sets no standard for using spi over 12c, or UAVCAN for the that matte,r anywhere else on the system.

Cables likewise it would be nice to use standard cables available and used in other places on the aircraft but for me that includes picoblade, 1 and 1.25 jst and the new connectors the click that Pixhawk 2.1 uses (GH?)

The common 8313 makes sense to me.

Mounting holes in the corners of the boards, especially if stacking. IS there a benefit to conforming to one of the standard square sizes adopted by FC designers the 20x20, 31x31 for 45x45 shapes?
My two cents!
Last edited by mike_kelly; Sep 18, 2017 at 11:18 AM.


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