I did the EV3 pet robot tutorial and I got it working. However when I tried to add some features I have a peculiar problem. When I use a voice command (up or down) on the A motor, it works fine the first time but subsequent commands just cause it to twitch, almost as though the tacho units had changed. I also tried this with RotateInDistance but with a similar result.
Any thoughts?
We would need to see your code Blocks Thomas.
Right-mouse in the Blocks work area and select "Download Blocks as image".
App Inventor
Forum Post
oh, sorry - I had intended to put them in, then forgot
UPDATE - I was able to partially work around this by using Rotate in Duration blocks. These perform consistently in time but do not always yield the desired degree of up / down due to battery state, load, and conditions. But at least it works.
The explanations of exactly what "distance" and "tacho counts" are in these blocks is not explicit and my interpretations may be part of the problem, but still not clear why it would work only once.
Code now looks like this
Hmm - how can the power be -50?
...back to the "works only once" - we need to see all of the Blocks in this process.
The difference between tacho counts and milliseconds - I would guess that tacho counting is a more precise rotation and probably more appropriate for, say, changing the angle of an arm. The milliseconds input might be driving wheels where the Robot has to follow a given path. I could be completely wrong though and often am 
One thing that will cause your issue is a lack of power. Check the spec of the motors and ensure your power supply is adequate for the total number of motors you are driving.
Hi Chris - thanks - negative power values are one way to reverse the direction of rotation - when using the duration setting in Mindstorms, its the only way, because you cannot have negative time. In App Inventor it appears there is a reverse motor command but the negative values are working fine in the duration blocks.
I thought of power so I tried several values but the initial command had plenty of power so unless that is being changed for some reason that is probably not it. The issue with tacho counting is what are the units? In Mindstorms the default unit is rotations, o 0.3 is 108 degrees. However you can also use degrees, in which case 0.3 of a degree is not much and could cause the observed behavior - but it seems odd that the units would change mid-run.
Here is the png of the blocks in the current config, ie using duration. Previously I had tacho where the duration blocks are now
I mean the actual power supply 
yes, understand - the unit was recharged and had plenty of power for the B and C motors; also, low power could affect the up moves but not the down moves
I can see that your code is probably the fault - you have some very strange logic going on there!. Can you tell me what Clock1 timer is for and it's duration/time interval? It looks like you should be able to control the robot without it? Also, all those If-Else-ElseIf blocks.....!
Ah - well, thats how the Tutorial says to do it.
The clock thing is a bit opaque - as I understand it, that is what generates the queries for the voice control. It is set at half a second so that after each successful command you quickly have an opportunity to issue a new command, but it is disabled while the voice command box is open and while the command is being interpreted, which takes a few seconds.
The if then else blocks are simply testing what voice command was received and then acting accordingly. The bottom one is if it doesnt understand the command.
Overall, this is not a great way to control the robot because the time lags are too long and too variable. That is why I wanted an up / down done by degrees or rotations. But the fact that it works at all is downright amazing - I'm going to show it to my girls' FLL team today and it will boggle their minds - and hopefully inspire them to get further into app inventor.
....that's what it is all about at the end of the day 
yep - I was completely unaware of app inventor last summer but the other coach mentioned it and I wanted to try it out. Our team has already programmed a cool fitness app that is kind of like PacMan except that YOU are the PacMan and you must run around a soccer field collecting objects. We tried it out last weekend and it was definitely a workout.
I think it would be wise to ditch the Clock method and have a button for speech input. The button can be disabled until the command function has completed. That alone will reduce lag time.
Do you have to run around in a PacMan stance? 
yeah, good idea - I will try that out
still puzzled about the up / down distance thing but I'll keep plugging away - eventually these things yield
no, you have to RUN because in after a certain level the Devil is after you and although you can outrun him it isnt easy
Hey that looks good
I will have to modify it a bit because the move motors are B and C but the up / down is A and the raise / lower is D - but this gives me an idea as to how to proceed
Thanks
