Thread Tools
Apr 09, 2020, 01:59 AM
Registered User
shuricus's Avatar
Quote:
Originally Posted by OlliW
great

ah
the reason is that now all settings can be imported, also e.g. the settings for the NT IMU which are stored internally into it. For that the STorM32 needs a connection to "see" the NT Imu

so here it's a disadvantage that I remove the "old" load settings as this would still work LOL

I see your point, I'll think about it how it possibly could be solved
Can it just ignore writing calibrations if it's not connected?

Quote:
Originally Posted by OlliW
I often would wish to have that option too ...

so one would need to have three options now for writing now:
- all vs only current page
- write vs write+store

from scratch I have no good idea how one could/should bring that out by GUI elements and still keep it fluid and intuitive ... three write buttons?? Two checkboxes next to it??
Can it be just two buttons next to each other - Write current, Write all? Store checkbox remains the same with same function for both buttons, just located underneath both buttons. Looks absolutely intuitive to me.


You are right about saving - I missed back compatibility.
Sign up now
to remove ads between posts
Apr 09, 2020, 02:15 AM
OlliW
Thread OP
ok, 1&2 had been easy
- removed the save settings (people hopefully will not miss it LOL)
- allowed to import params&scripts also when not connected
the write thing is much more difficult

take the files of the attached zip and copy it into your STorM32 folder
Apr 09, 2020, 02:25 AM
OlliW
Thread OP
Quote:
Originally Posted by shuricus
Can it just ignore writing calibrations if it's not connected?
that's exactly how it now is
gladly the code structure was well prepared for it LOL

Quote:
Originally Posted by shuricus
You are right about saving - I missed back compatibility.
I concluded to just removed it

Quote:
Originally Posted by shuricus
Can it be just two buttons next to each other - Write current, Write all? Store checkbox remains the same with same function for both buttons, just located underneath both buttons. Looks absolutely intuitive to me.
yes ... maybe
I also fight a size issue. For instance, it seems some folks use the gui on smaller screens, so I try to stay within it. You may notice that since a long while the outline of the gui has not changed, that is I always worked to add the additions such that I wouldn't have to change the gui size (e.g. I would prefer to have the interfaces as a tab and not a menu option, but ...)(AlexMos gui "resolves" that by scrollers ... which I however really would hate)

and I fight a personal issue: for some strange reason, when there are two buttons in close proximity, I have a good probability to hit the wrong button ...

since it's not so easy to write the underlying code we still have good time for brain storming on the GUI side
Apr 09, 2020, 02:43 AM
Registered User
shuricus's Avatar
Considering all your remarks.
Apr 09, 2020, 02:48 AM
OlliW
Thread OP
yes, this is the direction I am thinking about too

btw, I see these <> in the top right for the tabs ... why is that? Is this because you have increased the font size, or is this there also per default?
Apr 09, 2020, 03:10 AM
Registered User
shuricus's Avatar
most likely because of font size
Old Apr 10, 2020, 03:20 AM
Victor.K
A moderator felt this post violated the following rule: Excessive Advertising (Spam). It is temporarily hidden while Victor.K edits it.
Apr 10, 2020, 10:58 AM
Registered User
Quote:
Originally Posted by OlliW
generally you should note that the user base for STorM32 has become very small.
Given the still high number of ebay sales of the Storm32 1.31 controller and Storm32 based gimbals, i wouldn't agree to that
Apr 10, 2020, 11:11 AM
OlliW
Thread OP
Quote:
Originally Posted by fs008
Given the still high number of ebay sales of the Storm32 1.31 controller and Storm32 based gimbals, i wouldn't agree to that
very interesting comment
how would I find these numbers?
you are correct however in that my estimation is based only on what I see, and not what I know
what I see is that the traffic in the threads (as well as on my yt) has enormously dropped in the last years
also I would think that if some of our Asian friends would think that there is a substantial market they would pull out more stuff (e.g. the banggood NT offer seems to be gone no)
anyway, it's all a bit speculative I guess
and ultimately it doesn't really matter LOL
Apr 10, 2020, 11:59 AM
Registered User
Quote:
Originally Posted by OlliW
how would I find these numbers?
You won't get the total number of sales of course, but entering "storm32" in ebay serach gives me 350+ offers for controllers and various gimbals. That hasn't dropped.
imho Storm32 is the only diy gimbal solution right now, or am i wrong ?
Apr 10, 2020, 12:11 PM
OlliW
Thread OP
it's AFAIK the only one which still has some sort of "life". I believe you still can get AlexMos stuff, even the older stuff, and I think it's also still used. So I guess when talking about the level of STorM32 v0.96 alternatives are there, and I would think v0.96 is still mostly used by those ebay buyers.
Apr 13, 2020, 09:47 AM
OlliW
Thread OP
news about the STorM32 RPiHat, sneek preview into the lab

well, the STorM32 RPiHat pcbs have arrived last week, and not uncommon for a first version I see room for some small improvements I'd like to make, but overall they seem to work really great

The software-side gave me a bit more issues.

It's a great exploration into open source: Everything is possible, but nothing just works.

I've done the layout for the dual-UART hub following a project of ca 3 years ago which was saying that it is fully supported by Raspbian. However, it now turned out that Raspbian only supports the hub for when it's on SPI1 but not SPI0 as done by that project and thus me. Thus, I had a great time now with exploring device tree overlays...

when all these so fantastic tools from the open source flight controller community (ArduPilot, PX4)...

pymavlink, a well-known thing, but due to some - should I call it silly ? - small inconveniences one really can't use it for anything than the most basic straightforward use cases without monkey patching ... so, I worked out the monkey patches ...

mavlink-router, a great thing and v2 just came out, but due to some small mistakes it wouldn't do the routing correctly ... so, I work this out (hopefully this will be corrected soon in the upstream branch), but with that it's now really working great, I have to say

drone kit, a well-known thing too, but ... omg ... too many - should I call them silly ? - small little inconveniences ... so, I've ended up starting to essentially do my own thing. I of course follow DroneKit's spirit where possible, but some key parts I just had to redo.

and lastly, linux ... omg ... endless cryptic command line exercises just for doing some simple things ... I strongly feel confirmed in my opinion about linux

but it's the best we the have, right? Well, "best" doesn't imply "good", so, I rephrase: It's all we have, right?

Anyway, finally, it all seems to work, and seems to provide me the framework in need to do the real beef now, such as e.g. combining it with the MAVlink OpenTX and doing some drone quick shots, or implementing the new MAVLink gimbal messages, and so on...



Needless to say that the STorM32 RPiHat may be useful for other things too. The combination with OpenHD was discussed already in the above (and it admittedly revived my interest into RPis). However, it also should make it quite simple to e.g. build a STorM32 antenna tracker. One also just could load ROS on the RPi and use the STorM32 in robotics applications ... well, all that was possible before, but it's of course easier now hardware-wise with a STorM32 RPiHat ...

cheers, Olli
Apr 13, 2020, 07:42 PM
Registered User

DRV8313 Short Circuit


Hey everyone, I'm back!

I finished up all of the modules (I was experimenting with the new Storm32 PCBs (The ones with NT modules and encoders). I built a crude gimbal system where I connected in all the modules. When I plugged the battery in, some smoke started coming out of the DRV8313 motor driver. After this I measured continuity at Battery + and - there was a short. I'm guessing internally from the motor driver. I built another motor PCB (NT 251E) and the same thing happened again. I was super careful that there were no shorts and even measured with a multimeter beforehand.

Has this happened to anyone? Any ideas on what it could be?

Thanks in advance!
Ed
Apr 13, 2020, 11:52 PM
OlliW
Thread OP
sad to hear this
I think you need to share some photos of your setup so we can see how you wired it up
for instance, one way to produce smoke is to apply the bat voltage reversed, or to a wrong pad
it read as if you did build the modules yourself, this also suggests that you may have populated it incorrectly, e.g. that the DRV8313 was soldered in reversed
Apr 14, 2020, 11:40 AM
Registered User
Here are some pictures of my setup.

I did solder everything on by myself, it's not the most professional work but it's something. Like I said, before plugging in the battery I checked for shorts with a multimeter and came up with nothing. The battery wasn't reversed since I could read the voltage on the GUI through the main board.

I wonder if I received bad PCBs or perhaps the DRV8313 drivers were faulty?

Ed

Edit: I removed the DRV8313 chip and all of the components that were connected between Batt and Gnd. The multimeter still shows that there is a short, so it appears to be a PCB error. I manufactured my PCBs with JLCPCB, so I had to export the Gerber files from Eagle. Could it be possible that there are some incompatible dimensions or something and when the battery gets plugged in it somehow shorts the PCB?
Last edited by edlang90; Apr 14, 2020 at 12:19 PM.


Quick Reply
Message:

Thread Tools