Hey there! I was wondering if there is any way to minimize the wait time between movements with OkapiLib. Say I initialize a theoretical Okapi chassis, and execute the following commands;
chassis->moveToPoint({1_ft, 1_ft});
chassis->turnToPoint({3_ft, 3_ft});
There’s a rather uncomfortably large delay between these two. Is there a way to minimize this? Please do tell if there is. It would be a big help for us. Thanks!
Try to generate paths either before the autonomous period (during competition_initialize / initialize), or generate them during other movements so you can have routes ready when another is done
Is there potentially a way to do that with odom movements? I know that with pathfinder what you said would work
20 character bump sentence.
are you using pid right now? if it’s badly tuned, it might cause a big delay before moving on to the next command.
Well, we’ve tried both using it and not using it, and regardless, the wait time stays the same.
But I get what you mean. If anyone else stumbles upon this with the same issue and is using PID, try to make sure that it’s not your incorrect gains that are causing the long rise time.
I am wondering now, is there a way to allow the robot to begin movement while it calculates? Such that it calculates the actual vector for movement on the fly…
Well guys, if anyone else was looking for a “solution”, we mounted the quadrometric encoders on our robot earlier today and all movements are far sped up. We were previously using the internal motor encoders. So… I guess that’s sort of a solution? Be wary about getting encoders though, we ordered ours last month and despite the fact that our meeting place is probably only 10-15 mins from RobotMesh, we only got them now. Though to be fair, there was a large snow storm these last 4-5 days. Anyhow, if anyone was wondering, just mount encoders I guess.
If anyone really wants I can send a picture of how we set up our encoders but there’s probably far better setups elsewhere on the forum