03-05-2011 11:38

Mark McLeod

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

That's probably by design if it's trying to balance two drive encoders.
If you're using feedback to reach a particular position then you can't run at full speed, otherwise, it leaves no room for adjustment.

I don't have FTC though, so this is only empty speculation.

03-05-2011 13:11

DavidGitz

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

I am not familiar with FTC either. Is it possible to go into the Run To Position vi and see if it is limiting it there?

03-05-2011 18:56

PhilBot

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

Hi

The speed limiting isn't being done in the LabVIEW VI's. On the NXT side of things, the only difference between "Constant Speed", and "Run to Position" is that Run To Position sets a target encoder count, and turns on a bit to say "Run to Position". Checking to see if the move is over is an optional VI that just checks a status bit.

The fact that the PID may need some speed overhead to maintain syncronization or something, would seem to be negated by 2 Facts:

1) "Constant Speed" can be run independantly on either or both motors up to 100% capacity,
and
2) Different speeds and endpoints can be selected for each motor when you do a "Run to position". It's legal to set moves that have NO ability to end at the same time.

Anyway, when I ran the finals tests, I was only using one motor, so there was no need to synch.

After doing a lot of integer based math code, my money is on a bug where the controller is trying to calculate a speed ramp at the start and end of the move, and there is an integer divide/rounding error which is artificaially clipping the maximum target speed.

I'd just like it fixed. My replacement LabVIEW code that lets me run to position at 100% speed is not as good when it comes to stoppoing at the correct endpoint.

Phil.

03-05-2011 19:19

Mark McLeod

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

#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.

03-05-2011 19:48

PhilBot

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

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.

03-05-2011 20:11

Mark McLeod

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

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.

03-05-2011 20:41

PhilBot

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

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.

03-05-2011 22:42

Mark McLeod

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

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.

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.

03-05-2011 23:38

PhilBot

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

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.