i'm an adurino n00b. i bought the crunchlabs hackpack subscription, and here we are.
the first project is called the iturret. it's a nerf-dart style gatling gun.
at power-on, the turret wants to home itself, but, that's a problem, because it will spike (as in futbol americano spiking the ball) the magazine, if the magazine is tipped too far backward/upward. i have tried a couple of things to stop it, with limited success.
at startup, it seems that:
can't control servo speed, or instruct pitch servo to make limited moves because
can't know what the position is, can only command a move to a position.
whether i command servo.write(40) or servo.write(140), the first move seems to always be to 90°, before moving to the commanded position. the change in momentum is what causes the turret/magazine to to RUD. even the stopping caused by servo.write(90), or servo.write(100) can be enough.
but
is there another way to effectively slow the turret motion, at startup, just with code?
what about issuing a command, e.g. pitchServo.write(90), but then quickly executing pitchServo.detach() - maybe something like
// jog home
for ( int i = 0 ; i < 5 ; i++ ) {
pitchServo.write ( 90 ) ;
delay ( 5 ) ;
pitchServo.detach () ;
delay ( 5 ) ;
pitshServo.attach ( 11 ) ;
}
Welcome anjd thanks for using code tags in your first post
I do not know why you use a for-loop that moves the servo 5 times to the 90 position. But if you want to move a servo slower, you can e.g. use something like:
for ( int pos = 0; cnt < 90; cnt++)
{
pitchServo.write(pos);
delay(200);
}
The IDE has a two servo examples; have a look at the sweep example.
we are trying to home the servo from a random position, slowly. at startup we don't know the servo position. in fact, we have no way of knowing the servo position, ever, right? all we can know is the last position we commanded the servo to move to. all we can do is assume that it made it. at startup, if i servo.write(140), that is not what the servo does. let's say the servo is already at 140. the first thing it does is move to 90. then it moves to 140. after that, moves are as commanded.
That is problematic if you want to achieve that without jumps.
The only way that I see is to save the last position to EEPROM (Uno, Mega, Nano, Pro Mini) or simulated EEPROM; that would then be your starting position at startup. But there is a limit how often you can write an EEPROM cell.
Two ways around that can be
A FRAM module instead of EEPROM; FRAM has nearly unlimited writes
Detect a power down and save the last position by reading the position back using pitchServo.read().
Be aware that there is no guarantee that the servo is still at that position (e.g. somebody might have manually moved it).
the goal was to accomplish this, just with code, so that it is available to the wider audience, with less effort. there are a lot of ways we could figure out the position of the turret, but many of them involve some sort of hardware mod, or adding components.
as you mention, writing the last value to the EEPROM does not ensure that the motor is at that position, when we power back on
well, to anyone who comes along, afterwards, no, detaching the servo immediately after issuing the command didn't cause the servo to stop.
on to the next idea...
We had the same problem at power on. I think it was caused by the servo not being in the correct position when attached. Taking it apart and rotating it fixed it.
but that is the problem, now isn't it? how do we take a stock iturret and improve on its behavior so it doesn't spike the turret?
anyone can add a shield, and a linear guide, or disassemble the servo and add a wire to read the analog signal off the potentiometer, or swap out the motor for one that can be read, or upgrade the magnets, or the base plate, grab some gorilla glue, blah, blah, blah. literally anyone in this community can add cost and complexity to any problem, and probably devise a solution. i'd like to solve it, without doing those things.
