Simple Motor Calculator for Linux/OS X

[Andrew Schreiber]

Several years ago Ether released a Simple Motor Calculator (http://www.chiefdelphi.com/media/papers/2432) that lets you specify a motor and some parameters and it will tell you what the motor is doing at that point (ex specify the current a motor is running at and it will tell you torque, speed, efficiency) The issue is it was only for Windows and a handful of folks don't run Windows... so I took the equations he provided and put them in a simple command line application.

https://github.com/schreiaj/motorcalc-uni Here is the code, or for those of you who just want to try it here's the releases page https://github.com/schreiaj/motorcalc-uni/releases please try it out and let me know if I can make it more useful to you.

Currently supports CIM, 2xCIM, 3xCIM , Bag, AM775, 775pro, and AM9015 and specifying amps or torque. I'm aiming to add in rpm soon.

Hope you find it useful.

[SoftwareBug2.0]

You may want to document your build dependencies. On Ubuntu 15.10 I installed go-bindata and golang-go.

To build I had to change "motors.csv" in the makefile to ".". At least the version of go-bitdata that I have only expects to see directories in that position.

The clean target of the makefile can sometimes fail. Consider adding the "-f" flag to "rm".

When the program is run with no arguments it prints an out of range exception rather than an error message that says what it expected. Similarly, there is no "--help".

When an unknown motor name is encountered the output is lots of NaN rather than an error that the program doesn't know about the motor. For example, try typing "cim" rather than "CIM".

[Andrew Schreiber]

Originally Posted by SoftwareBug2.0

You may want to document your build dependencies. On Ubuntu 15.10 I installed go-bindata and golang-go.

To build I had to change "motors.csv" in the makefile to ".". At least the version of go-bitdata that I have only expects to see directories in that position.

The clean target of the makefile can sometimes fail. Consider adding the "-f" flag to "rm".

When the program is run with no arguments it prints an out of range exception rather than an error message that says what it expected. Similarly, there is no "--help".

When an unknown motor name is encountered the output is lots of NaN rather than an error that the program doesn't know about the motor. For example, try typing "cim" rather than "CIM".

Yup, it's on my todo list (pull requests are also accepted)

So --help and some warnings for not supplying enough args, and throw an error on incorrect motor names.

[Andrew Schreiber]

So some updates and questions for your Software Bug - I'm going through and have added some better command line parsing, so I'll release that as soon as I nail down this next issue.

Getting the name of a motor wrong - When this happens do you think a best guess and run approach would be preferred to a "Did you mean CIM" and exit approach (similar to git's cli when you screw up a command)? I'm working on getting some fuzzy string matching working in and was curious what would be preferred. If it were a long running command or one with side effects I can see the benefit of the git "suggest and exit" approach. But being as it takes very little time to run and changes nothing except standard out I think the "best guess" approach might work fine.

Sorry this took so long, turns out build season is time consuming.

[SoftwareBug2.0]

My general feeling is that if there's any chance of the program being wrong it shouldn't try to run based on a guess. So for example, running with the 'closest' name to a user argument might be problematic because if they typed in something that there wasn't data for you might get wrong data out. But on the other hand, a case-insensitive matching wouldn't have that problem since it's reasonable to assume that there won't be a new motor whose name differs only in capitalization.

[Andrew Schreiber]

Originally Posted by SoftwareBug2.0

My general feeling is that if there's any chance of the program being wrong it shouldn't try to run based on a guess. So for example, running with the 'closest' name to a user argument might be problematic because if they typed in something that there wasn't data for you might get wrong data out. But on the other hand, a case-insensitive matching wouldn't have that problem since it's reasonable to assume that there won't be a new motor whose name differs only in capitalization.

Ok, then I'll go with the git cli model of Exit and say "hey maybe you meant this"

And yes, the search will be case insensitive, that was an oversight... still new to Go.

[marshall]

Originally Posted by Andrew Schreiber

Ok, then I'll go with the git cli model of Exit and say "hey maybe you meant this"

And yes, the search will be case insensitive, that was an oversight... still new to Go.

Fair warning with Go if you use any external libraries and don't explicitly pull them in and instead use the functionality to just have Go update them via Git.. you can end up in a situation where your program breaks because the external library is broken. That being said, I do enjoy me some Go programming... anyone want to port it to the RoboRIO?

[Andrew Schreiber]

Originally Posted by marshall

Fair warning with Go if you use any external libraries and don't explicitly pull them in and instead use the functionality to just have Go update them via Git.. you can end up in a situation where your program breaks because the external library is broken. That being said, I do enjoy me some Go programming... anyone want to port it to the RoboRIO?

Yeah, I've found that version locking dependencies isn't quite as robust as I've come to expect from things like ruby gems and npm.

Also fair warning about cross compiling - it's fine with plain old go code, but the second you start dealing with cgo your life gets complicated quick.

I too would welcome a WPILib port of Go, but I don't know if it really gives you much benefit over the other languages out there. Python/Lua are nice because they are a very different type of language.