paper: Have you noticed that you don't get full speed in FTC Autonomous?

[Mark McLeod]

#2 just sounds like the reason why I thought it might be designed in.
But it depends on if it's a general solution that is setup for synchronization, or a specific solution like Constant speed that never does any synchronization between encoders.

[PhilBot]

Originally Posted by Mark McLeod

#2 just sounds like the reason why I thought it might be designed in.
But it depends on if it's a general solution that is setup for synchronization, or a specific solution like Constant speed that never does any synchronization between encoders.

Here's my reasoning... As far as the register specs for the DC Motor controller goes, the control of the left and right motor "appear" totally independant.

Each motor (two per controller) has a duplicate set of control registers with open/closed loop settings, target positions and speed/power. So it's perfectly legal to run one motor in open loop constant power mode, and the other in closed loop, constant speed, run to position mode. No hope of synching here.

Plus the spec doesn't say anything about degraded speed in Run to position mode. The speed parameter is still 0-1000 degrees per second.

I guess my fiinal piece of logic is that if was going to do synching, why not ALSO do it in Constant Speed mode (even without a target end point). Seems like if it can do 100% in this mode, why not Run To Position?


Phil.

[Mark McLeod]

I'm not buying.
You seem to be arguing against the evidence.

A cap on max power is only needed for synchronization.
Constant speed never needs it, so it doesn't ever have a cap.

If Run to Position ever needs to be synchronized for left/right motors, then the design is simplest to always run as if that's the case, otherwise, additional logic (essentially yet another mode) would be required.
Can more sophistication be added, yes, but the evidence seems to be that the designers didn't.

[PhilBot]

Originally Posted by Mark McLeod

I'm not buying.
You seem to be arguing against the evidence.
If Run to Position ever needs to be synchronized for left/right motors, then the design is simplest to always run as if that's the case, otherwise, additional logic (essentially yet another mode) would be required.

So your argument is that if it may sometimes need to run syncronized, then it should always allocate the overhead for it.

OK, then how does it know WHEN to run syncronized?
There is no bit for it in the Motor Controller.

http://stuyfissionfusiondevelopment....ief%20v1.3.pdf

It's not like a robot where you give it a speed, distance and turn rate and it KNOWS that the wheels need to stay synched, and calculates the correct ratios. How does the controller deal with invalid ratios eg:

If I issue a command for the left wheel to go 1000 clicks at 50% speed and the right wheel to go 1000 clicks at 100% speed, should it synch? Clearly not. One needs to run for twice as long as the other.

How about left 1000 clicks at 50% and and right 2000 clicks at 100%? Probably yes but wait... there is no explicit tie in between the two on my robot, one is a shoulder joint and the other is a batton collector. Please don't synch them... ...

So if the Motor controller IS always trying to synch, then this is an equally big problem..

Plus it's not mentioned in the manual that I can find.

[Mark McLeod]

Since I don't own one, so I certainly cannot say one way or another, however, your protests don't match your reported data...

I wouldn't call it allocating overhead though. I would say it is possibly due to a limitation on flash storage for the sophistication of the algorithm chosen. It might keep the cost of the development/components low.

Originally Posted by PhilBot

If I issue a command for the left wheel to go 1000 clicks at 50% speed and the right wheel to go 1000 clicks at 100% speed, should it synch? Clearly not. One needs to run for twice as long as the other.

I do think of these as potentially sync'able. It's how to get repeatable curving turns.
The way to prove/disprove of course is to see if they both finish at the same time. If that 50%/100% is a maximum limit, then it may choose the lesser. Maybe it'll be a proportional finish. If they don't finish via some derived relationship then maybe it only matches them if the speeds are set the same or encoder totals are close.
A few more experiments to reverse-engineer the algorithm might give you some confidence as to what Set to Position is designed to do.

Whatever other purposes that you decide to put the controller to, it appears that the Set to Position mode might be designed with tank drive in mind.

[PhilBot]

I guess we can agree to dissagree here.

My whole issue with the current behavior is that it's not consistent over the full range of requested speeds (or even close to the full range).

I originally discovered this problem when I was trying to calculate (based on requested distance and speed) how long a particular straight motion "should" take, so I could set a close timeout.

Imagine my surprise when a move of 10000 clicks at 70% "speed" (not power), took the same time at 80, 90 and 100% speed.

My money is still on an integer divide truncation error .
But I'll probably never find out.

Phil.