Thank you DOOS, once I have a working program that does what I want for me, I usually don't have the courage or the will to optimize it further. I will definitely apply your recommendation. That Matt's LIB contains the commands of the basic servo positions is difficult as I mentioned. You can disagree about the speed of the servos. When I use them in my dolls without speed reduction, the movements are much too wooden.
Op maandag 17 januari 2022 om 13:49:51 UTC+1 schreef Kiste: > Hi hans, > > heel mooie video's :-) > > Your program fragment can be optimized a little, with no loss of function > but saving code and data space and also execution time (which is not so > important, as the purpose is to delay...) > > tell=0 > for 4 loop > [...] > servo_move((old_pos[tell] + 1),tell+1) > [...] > tell=tell+1 > end loop > > This can be done like > > --tell=0 > for 4 using tell loop > [...] > servo_move((old_pos[tell] + 1),tell+1) > [...] > -- tell=tell+1 > end loop > > This way an invisible loop variable is omitted. In that special case, > there's another way to improve: > > tell=0 > for 4 loop > tell=tell+1 > [...] > servo_move((old_pos[tell] + 1),tell) > [...] > end loop > > Now, "tell" is always one count ahead. In each servo_move call, you're > saving the "+1", which takes code and possibly data space. So, why didn't I > just state "tell=1" and leave the increment at the bottom of the loop? Very > curious PIC assembler details... Setting a variable to zero is cheaper than > setting to any other number. The increment is done four times anyway, so > there's no extra cost to move it. What about combining both optimizations, > like "for 4 using counter loop; tell=counter+1 ;[...]"? Terrible. > Incrementing a byte "tell=tell+1" is a single assembler instruction. > "tell=counter+1" is quite a complex calculation which takes code and data > space. > > </smartassing> > > The purpose of a servo is to move to a certain angle as fast as possible. > How fast, depends on the power of the servo and to the mass (or rotational > inertia) connected to it. It is not the responsibility of a library to > slow the movement down, although I think such functions wouldn't hurt as an > extra. > > Unfortunately, the communication to the servo is one-way, so, when > switching on, the controller can not know in which position the servos are. > Thus, IMHO, a library shoudn't move to any "initialisation position" on > it's own. It's the responsibility of the application program to move to a > starting position. There may be a certain procedure that works from all > possible starting positions, like e.g. > > 1. bend elbows > 2. wait for elbows are bent > 3. move shoulders outward > 4. ... > > That example is clearly wrong for the linked video, as when shoulders are > up and inward, bending elbows might have the hands collide. But there might > be another order, which works from any starting position. > > > > Greets, > Kiste > > (Jij kunt me ook "Doos" noemen :-) > > > > Am Montag, 17. Januar 2022, 12:43:56 MEZ hat hans <[email protected]> > Folgendes geschrieben: > > > Here is a program part which i use for reduce 4 servo's speed : > ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, > -- basic position all servo's > servo_move(124,1) > servo_move(124,2) > servo_move(129,3) > servo_move(121,4) > > --------------------------------------------------- > var byte old_pos[4] = {124,124,129,121} -- start up beiden in centrum > var byte new_pos[4] > var byte tell =0 > ----------------------------------------------------- > > --------------------------------------------------- > > procedure set_servo_pack (byte in x) is > var byte flag = 0 > > var byte tell = 0 > while flag < 4 loop > flag = 0 > tell = 0 > > for 4 loop > if old_pos[tell] < new_pos[tell] then > servo_move((old_pos[tell] + 1),tell+1) > old_pos[tell] = old_pos[tell] + 1 > delay_1mS(x) > end if > > if old_pos[tell] > new_pos[tell] then > servo_move((old_pos[tell] - 1),tell+1) > old_pos[tell] = old_pos[tell] - 1 > delay_1mS(x) > end if > > if old_pos[tell] == new_pos[tell] then > flag = flag + 1 > end if > tell = tell +1 > > end loop > end loop > end procedure > > Op zondag 16 januari 2022 om 19:40:07 UTC+1 schreef vasile: > > Impressive! Congrats Hans! > Perhaps using an encoder to "see" the servo position? The less expensive > it's a japanese amazing potmeter which can be rolled over ( 360 degree > movement, 270 degree cursor). I've used such devices, no failure... > > On Sun, Jan 16, 2022 at 4:05 PM hans <[email protected]> wrote: > > I've been using Matt's servo lib for years. The maximum number of servos > in one project was 12.( see https://youtu.be/ujfMYD5zXNU) > > > > The only problem I had with the lib was that it resets the servos itself > int a fixed basic position and that can conflict with the initial position > in the program. So when you start up, you get a different base position for > a while and that can cause damage. > > A second thing for me is the speed of movement from one position to > another. I now do this in a procedure within the program. > > If this sometimes doesn't work out, I'll take another pic, even the small > 12F683 works perfectly. > > regards > > Hans > > Op zondag 16 januari 2022 om 10:35:02 UTC+1 schreef [email protected]: > > Hello all, > > I sometimes see projects using servo's using the JAL servo llibraries. I > have not yet used any servo's but I regularly have a project with LEDs that > uses PWM (like the servo library). > > The number of PWM channels is limited on a PIC and it may be that the > timers on the PIC are needed for something else. > > A solution would be to use a PCA9685. There are modules available to > control up to 16 servo's (or LEDs) using this module. > > I was wondering if there are JAL users that have plans to use this device. > If so I might make a library for it in some near future. > > Thanks. > > Kind regards, > > Rob > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jallib/5cded4d9-1760-45a0-a8b0-d1f79718afaan%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/5cded4d9-1760-45a0-a8b0-d1f79718afaan%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > > https://groups.google.com/d/msgid/jallib/c72da766-937f-4e05-9971-7f50f2ac858fn%40googlegroups.com > > <https://groups.google.com/d/msgid/jallib/c72da766-937f-4e05-9971-7f50f2ac858fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/bae15549-0e90-45f7-a3e5-76442463f6edn%40googlegroups.com.
