I think Nathan has found a fix. “resetting the configuration” seems to have worked. libusb now detects my Micro Maestro on OS X and pyusb now finds my device
Patches have been committed to a libusb development branch and hopefully should be included in the next release of libusb. Note: this is not an OS X driver that provides virtual com ports. It’s just the libusb user space tools.
hi
sorry about this being a late post but has anyone successfully completed this? im new to all of this coding and i have only really worked in apple’s Xcode but i want to venture out for the mini maestro 6 and dont know where to start
Please note that one flaw of the code above is that it does not check any of the return codes provided by the libusb functions so it will be hard to debug if something goes wrong.
Even though this code was written for Linux, I think it will work with minimal modification on a Mac. You will need to download, build, and install Libusb. Then should be able to compile the code above either in XCode or with a command like:
thanks david, i will give that a try. one more thing, do you know of and material to learn these codes, i have only done one or two projects with C and C++ so it is extremely new to me.
If you need to send any commands to the Maestro other than the Set Target command, you should look at the functions in the Usc class in the Pololu USB SDK in order to see what commands are available and what the protocol is.
I’m replying almost a year after this was first asked because I ran into the same problem.
Here is the solution.
The Micro Maestros ship with SERIAL_MODE_UART_DETECT_BAUD_RATE as the default.
This seems to enumerate as a CDC device, but the Maestro is not listening to USB in its default mode.
Using “Maestro Control Center” while running Windows is somewhat inconvenient for Linux and OS-X, but that is the easiest way to change the default serial mode setting.
Once SERIAL_MODE_USB_DUAL_PORT is set as the serial mode,
the Maestro will listen to commands over USB.
I also use pyserial. Here is a code fragment:
import serial
s=serial.Serial()
# lower port # is command port
s.port="/dev/tty.usbmodem00022961"
s.baudrate=115200
s.timeout=1
s.open()
def setpos(pos):
"""pos is 0.25us increments centered about 1500us +/- 500us
so range is 4000..8000
"""
low=pos&0x7f
high=pos>>7
#print low,high
# cmd, chan, low, high
s.write(chr(0x84)+chr(0x00)+chr(low)+chr(high))
It is also possible to use libusb via pyusb after unloading the USB CDC driver.
Read the man page for kextunload.
There are separate drivers for Control, Data, and the base class.
Here is a pyusb code fragment to set the serial mode to “USB Dual Port”:
device.ctrl_transfer(0x40, 0x82, 0, ((1<<8)+3))
Use kextload to reload the CDC drivers to use pyserial.
Hello. We don’t support running the Maestro Control Center on Mac OS X, but from the error message I would guess that you didn’t install the right version of libusb (1.0).
I guess you are talking about the bash script found in the Serial Example Code > Bash Script section of the Maestro user’s guide. That bash script has instructions at the top of it that tell you how you need to configure the Maestro. Did you follow those instructions? What serial mode is your Maestro in?
I’ve read info that recent versions of OS X do not allow the USB CDC drivers to be unloaded, which is required to claim the device and communicate using native USB control transfers.
The current solution offered is to write a codeless kernel extension (kext) which matches the USB device Vendor ID and Product ID, so that the OS X CDC driver wont claim the device. I think that the codeless kext can then be unloaded and a userspace app can then claim it and use the native usb control transfer.
To me that seemed like a bit of a hassle, especially if you are not a developer. It would be good if someone could contribute such kext to Pololu so they can upload it to the resource page
Now another solution could be if the USB descriptors in the Maestro did not contain the CDC interface classes (2 and 10), and just have the proprietary interface class (255). That way no kext should claim the device and the userspace app is free to claim it and use it
Is it possible to have two versions of the firmware – one with the full usb descriptors, and one with only the proprietary descriptors ??
Given that native usb is the preferred/recommended method of communication, one could suggest that the having only the proprietary descriptors should be the default ??
I think that’s true, but it should not be a problem for the Maestro. The Maestro is a composite device with 5 interfaces. If I recall correctly, the first interface is the native USB interface, the next two are linked together and represent the CDC ACM command port, and the last two are linked together and represent the CDC ACM TTL port. The USB CDC drivers should not be messing with the native USB interface, so you should be able to connect to that one and do control transfers using libusb.
We made “UART, auto detect baud rate” mode be the default to give people the option of using the Maestro without touching USB at all.
I’m not sure that is true on OS X (I’m using 10.7.5). Nathan (libusb OS X author) says:
So it sounds like we need to make OS X not load the drivers (because one of them wont release the device when asked). Codeless kext is a solution, but it feels a little messy to me, and you may have to have several for different USB devices and different versions of OS X.
Having a version of Meastro firmware with only the descriptors modified so that only the proprietary interface is present means the OS will not load the CDC drivers, and OS X would be free to talk using native USB So could we have two versions of the firmware? One with full descriptors and one with minimal descriptors ?? I’m happy to use Windows (via VirtualBox) to reprogram my Meastro. BTW, using native USB in Windows/VirtualBox works fine
BTW, interface class 255 is proprietary. Is there any information on how to use this proprietary interface ?? I believe this is different to native usb using control_transfer() – but maybe I misunderstand ??
You should do what Nathan suggests above. (You don’t need to claim the USB interfaces used for the virtual COM ports; the native USB interface is more powerful than those interfaces combined.) The only documentation we have for the Maestro’s native USB interface is in Usc.cs in the Pololu USB SDK, but that should be enough for you to figure out what you need. For basic use, you should look at the setTarget method and see what kind of control transfer it uses.
If you have trouble doing this, please post your code here. We have a Mac here that runs 10.7.3 so I can test your code on my machine and probably get it working. I recommend using libusb 1.0 and libusb_control_transfer.
Hi all, I realize this is an ancient thread. However, after dealing with lots of strange issues with the serial device on Mac/OSX I just broke down and used libusb. Here’s a really crappy UDP server that reads x y data from UDP packets and controls 2 servos accordingly: gist.github.com/asm/8b5217ed6d688c26ad70. Hopefully this will help someone
Note the controller sends its data back in packed form so the structs in the protocol.h that comes with the SDK won’t work on architectures that byte align.