Project is a OWI 535 arm controlled by a "counterfeit" adafruit motor controller, connected to an Arduino Mega ADK, riding on top of a 4000 series Roomba and the user interface is a PS3 controller over a bluetooth connection to a cirago USB/BT adapter. Things are working and I have proper communication, but I am having a problem dealing with input from the PS3 controller.
Summary:
I'm working with a bluetooth PS3 controller and want to make use of pitch and roll to control specific motors of the OWI arm. I am encountering something strange. The PS3 controller likes to send data (it sends a lot), and it looks like somehow it's getting queued up, as a short twist on the controller causes 4-6 seconds of activation on the motor. Right now I am only testing with 1 motor.
The controller roll is going to turn on a motor for a short period of time, then turn it off. My idea was to do like the drive I am using for the Roomba so that continued moving of the controller will keep the motor moving.
So I'm thinking that somehow that input from the controller is getting queued up (or something similar enough to it) because there is lag on my trace output. For ~.1 sec movement of the controller, I get about 4 - 6 seconds of movement out of the motor. I don't think that's quite right.
Hopefully I'm doing something stupid and you can point that out real quick-like.
Snippet of the function I am working with / talking about (whole program attached due to size):
if(armMode){
if(PS3.getAngle(Roll) < 150){ // move motor 1 left
Serial.println(PS3.getAngle(Roll));
motor1.setSpeed(200); // set the speed to 100/255
motor1.run(FORWARD);
delay(250);
motor1.setSpeed(0);
} // end left
if(PS3.getAngle(Roll) > 200){ // move motor 2 right
Serial.println(PS3.getAngle(Roll));
motor1.setSpeed(200); // set the speed to 100/255
motor1.run(BACKWARD);
delay(250);
motor1.setSpeed(0);
} // end right
...
holmes4:
Delay() means not nothing at all. So your code will not see any input while its in the delays. Look at blink without delay in the examples.
Mark
I understand that. The delays arent going to be permanant, this is just to get things up and going "quick and dirty". I dont understand why you are pointing this out though. If the delays were the problem, wouldnt I have the oposite problem? Wouldnt it be almost nonresponsive?
Then, get rid of them now. You are heading down a path that is going to make removing the delay()s later nearly impossible. Write the code, from the beginning, so that a complete rewrite later is not required.
Write the code, from the beginning, so that a complete rewrite later is not required.
Can't do that... I'm testing each leg of communication one at a time as I get the parts online. Eventually the PS3 controller is going to be connected to an android phone via USB, which will be connected connected to another android phone via wifi, which will be connected to the ADK via USB and that's how the data will get there. NOT directly to the arduino the way things currently are. I'm several steps away from that, hence my "quick and dirty" approach here.
I don't have any problem rewriting the code to make use of a counter variable, but I don't understand this phenomenon and would like to.
I had originally thought that the queuing up of data was not occurring with the keyboard presses, but after a bit of observation I noticed it was, just I wasn't typing as fast as the PS3 controller so the effect was more pronounced with the controller.
I tried just removing the delay by commenting it out. I got some weak noise from it so I figured that was no long enough to run.
Then I tried a delay of 10ms and it's working the way i expect it to. I know it's not good form, but it allows me to get the directions set up and things moving (punny, yes?). I'm more comfortable with the way the program flows using delay() even though I know it's not a good thing to use. I'm familiar with the counter based timer (ie looking at a stopwatch), but the last time I used it, I needed a bunch of semaphores and it was hard to wrap my head around even though it was working.
In the process the battery on the roomba died (main supply for this bot), so I have to let it charge up for now.