I was wondering… Is there any reason why the PICK command can only retrieve a value up to 64 down on the stack?
whenever I try:
64 PICK
or any value above 64, it will return 0 - even though the value is definitely not 0.
A way to get around it is to do:
DEPTH 64 MINUS PEEK
which works, but then it adds 2 commands. No big deal, but in a script where I already have to compensate (lower) delays to accommodate for the processing time of the Mini Maestro, every ms count! Just thought I’d put it out, since there is no mention of that limitation in the manual.
I do have a question however:
The command SERIAL_SEND_BYTE “interprets” a value as a byte and sends it over TX. Given the initial value can be anything from -32768 to 32767, how is the “interpretation” calculated? Do I have to make sure the value is between 0 and 255?
Thanks,
-A
Hello, alevesque.
Sorry for the inconvenience. We originally wrote the PICK command for the Micro Maestro, which has a much smaller stack, and when we made the Mini Maestros we didn’t realize it had this limitation. I have updated the “Command Reference” section of the user’s guide to say that the argument of PICK needs to be between 0 and 63.
Thank you for telling us about this, and thanks for the workaround. I have packaged it into a subroutine which might be useful to you or other Maestro scripters:
sub deep_pick
depth swap minus 2 minus peek
return
You can use deep_pick just like you would use pick, but there are no limitations on the argument besides that imposed by the stack size.
The interpretation is the same thing that happens in most C compilers when you do “unsigned char my_byte = 8000;”. The byte you get is the original number modulo 256. For positive numbers, this is the same as taking the remainder after dividing the number by 256. So you don’t need to make sure the argument is within 0 to 255. For clear, readable code, that is a good practice, but if you want to save a few instruction cycles and know what you’re doing then it’s not necessary.
–David
Thanks David, sorry I didn’t catch your reply earlier - been keeping busy on that motion control project…
As it keeps evolving (the project), it becomes clear that a micro-controller will be needed; I am hitting the limits of the mini maestro processing speed and scripting capabilities. However, I am not quite sure which one I should pick… pretty new to all this, and a bit intimidated by the programming language (I am comfortable writing in Python, JS, AS2/AS3 and… maestro 
).
I wrote a script on the maestro that “records” the data from a pot (for 25sec.), and then allow to play it back as many times as wanted, or erase it and re-record a new motion. It works well on my test bench (one servo, one pot, a few LEDS and buttons), but I get a few ms lag here and there… so many IFs, ELSEs and calculation per cycle that the poor mini maestro has a hard time keeping up… So far I’ve been compensating by lowering the delays here and there, but for sure once I put it in the system (with 6 servos and 6 pots), the lag will become unacceptable.
Ideally, all that calculation would be handled by a more capable micro-controller, and the maestros would only interface between the controller and the devices… Also, it would hopefully allow me to use optical encoders (6) instead of pots, to increase the level of precision and get rid of that noise problem… Any suggestion that would fulfill these requirements (without breaking the bank, ideally 
)?
If anyone’s interested, here’s a link to the full script (not copying here as it is 455 lines!):
http://www.newreel.ca/motionControl/fullProgram.txt
It features a calibration sub that establishes the neutral (centering) and speed values forward and reverse, a recording sub that records (saves into the stack) pot position every 250ms, and a playback sub that plays the recorded motion by picking every values from the stack (without erasing them), and apply the corrects the speed (checking the calibration data) every 125 ms to stay on target. I am pretty proud of that “program” - seems like it squeezes pretty much everything out of the maestro.
We have plenty of programmable controllers you can pick from:
pololu.com/catalog/category/64
All of them would be much more powerful than the Maestro scripting. Most of them would require you to learn C, but there is plenty of example code available for each platform. I think you might like the Orangutan SV-328 because it’s one of the cheapest controllers we sell that has an LCD, which can be very useful when you are debugging your programs. Once you have developed your code, you can load it onto a Baby Orangutan B-328 for the final deployment if you want. Both of these boards are based on the ATmega328p which has 2KB of RAM, so you could store much longer or much higher resolution movement sequences.
–David
