Thanks for your reply. I think my problem is largely in the implementation of sendCommand(). But let me answer your questions.
Maybe one problem is that your Maestro is not in the right serial mode, which is “USB Dual Port”.
My impression is that there is no setSerialMode() command, so it’s really more about how you connect to the board over USB (which virtual TTY device or which USB interface).
One Pololu-published option is to use the virtual serial device which appears upon plugging in the board. However, I believe this can be made even simpler to the user if we have a CDC ACM based class. This would eliminate the need for the usb-serial-for-android library, and would avoid conflicts with virtual device naming conventions (e.g. /dev/ttyACM0). This approach depends on which USB Device, Interface and Endpoint you send your commands to. When you plug in the board it surfaces a Pololu device with 5 interfaces (copied from lsusb command on linux):
Interface 0: Command Port, Communications Class
endpoint 1: IN, Transfer Type = Interrupt
Interface 1: Command Port, CDC Data Class
endpoint 2: OUT, Transfer Type = Bulk
endpoint 2: IN, Transfer Type = Bulk
Interface 2: TTL Port, Communications Class
endpoint 3: IN, Transfer Type = Interrupt
Interface 3: TTL Port, CDC Data Class
endpoint 4: OUT, Transfer Type = Bulk
endpoint 4: IN, Transfer Type = Bulk
Interface 4: Vendor Specific Class
Based on this I used Interface 1 with endpoint 2 for sending/receiving commands.
Another problem is that you have the wrong second argument to sendCommand when you call it from setServoPosition. You shouldn’t need that second parameter anyway; in Java, arrays know how long they are.
Since I use one array for all the commands, I wasn’t sure if sending the extra bytes would cause a problem. I do need to simplify that though.
How are you planning on implementing MaestroUSBDevice.sendCommand(byte buffer, int length)? …
The code is implemented and available at github.com/pryan1068/maestroSSC. I’m under the impression that I can just push that entire buffer over the command port and it will magically work. Once I figure out how to do the low-level USB transfer command correctly, I can clean up the code.
I would copy all the features of MaestroSSC into the MaestroSerialDevice class, and get rid of MaestroSSC.
The intention is to separate the data format from the device(s). This will allow us to use the same data format class on the PC side, and simply use a PC-centric device class over there. Otherwise we end up maintaining the same code in multiple places.
Also, I think you should use a namespace other than “com.pololu” in order to avoid confusion if we ever release our own java class for the Maestro.
The intention was to create this for Pololu, and transfer ownership. I can change it to a fictional namespace.
Let us know how it goes! If it works well, then maybe we’ll make more software like it.
I think we’re on the leading edge of a increasing smartphone presence in the USB devices space. The adoption of products is accelerated and made easier through good API documentation and example code.