[Rock-dev] Proposal for adding velocity information in base::actuators::Status

[Leif Christensen]

On 05.04.2012 14:23, Sylvain Joyeux wrote:
> On 04/05/2012 02:11 PM, Javier Hidalgo Carrió wrote:
>> Velocity can be derivate from position, but we would get bigger error in
>> velocity if we do it a rock level.
>> FPGAs in each joint computes the velocity using the encoder (position)
>> information at much faster frequency.
>> The derivation step is smaller at the FPGA. Monster reports this
>> information only every 40 ms.
>>
>> I would say is better to use the velocity coming from the joint/FPGA
> Well. Depends what you call "velocity" here (and this is the underlying
> reason why we need to have a much broader discussion here).
>
> If it is instantaneous velocity at the time where the status is
> generated, then you are right, but it is going to be (1) a very
> quantified and noisy value since it is highly dependent on the precision
> of your encoder and of the sampling time of your FPGA and (2) would not
> give you the big picture about what your system does (since you have
> this instantaneous velocity only once every 40ms).
>
> If it is average velocity over the 40ms, then there is no difference
> between the two methods.
>
> I do not want appear to say that your use case is useless, I want to
> point out that we will need to have a richer representation anyways if
> we want to support every use case.
+1 for broader discussion, since also for the FPGA/BLDC-guys, the 
discussion concerning joint position/velocity/acceleration/jerk(jolt) is 
far from settled.

In most (!all) setups using the BLDC V2 stack we have some sort of 
internal encoder (magnetic or optical, 2 to 6 channel) attached to the 
motor shaft, for example a Faulhaber IE2-512 and some sort of external 
(often absolute) encoder (sometimes ICHouse) on the driven side. In both 
cases, we have a (relative or absolute) position sensor.

But depending on the FPGA-Code in use (I would say this varies from 
project to project) the information is used differently. Just to name a 
few options for the relative position encoders:

a) Count ticks over fixed time interval
b) Measure time from on tick to another
c) Count n ticks and measure time
d) Mix any of a, b and c to get a reasonable trade off between noise, 
frequency, discretization error depending on the ticks per rotation of 
your encoder
e) Use the 2 channels of a quadratur-encoder not only to determine turn 
direction and for the sake of robustness, but for example measure time 
between raising edge channel one and falling edge channel two
f) combine e) with a), b), c) or d) ...
g) Vary time interval, tick amount
h) ...

We also have crazy stuff on the BLDC like microphones, which could 
theoretically be used to "measure" (after learning) torque, speed, or 
deviations from normal conditions.

Someone might try to use the current measurements plus a motor model to 
determine speed if they know the torque form force-torque sensors.

To sum up, there is a wide range of sensors and implementations on the 
BLDC stacks of different quality and also combinations of them, perhaps 
already with real sensor fusion underneath.

I think there is a main decision to be made (perhaps has already been 
made?): Is base::actuators:Status intended as a simple least common 
denominator and therefor can and should be happily extended for most use 
cases, or are we trying to design it to fit as much use cases as possible?

Happy Easter!
Leif