All of this seems highly moot to me. It seems to me that a timestamp
applied when the flight computer collects data from USB should be
plenty accurate for most everything we're doing, and will be perfectly
synchronized; the exception is probably the IMU, because it runs at
high rate and will have a lot of buffered traffic. We can play games
there if we need to with getting the IMU to report its internal
timestamp periodically through a separate interrupt endpoint so that
we can calibrate the local timestamps on the individual IMU packets.

I'm with Josh: I don't understand why sensors running at different
rates should be a particular problem for BPF? One of the reasons we
chose BPF over Kalman was precisely because BPF could accommodate
asynchronous updates.


On Tue, May 24, 2011 at 8:18 AM, Josh Triplett <> wrote:
> On Fri, May 20, 2011 at 12:52:30AM -0700, Chris Crase wrote:
>> What concerns me about about the time stamp is two fold especially with the
>> particle filter.
>> 1.  Multiple sensors at different rates are troublesome.  Say sensor A is at
>> 60 Hz +- 1 Hz and then sensor B is at 100o Hz with +- 0.05 or something.
>>  This can make particles behave very badly.
> How so?
> From what I understand, we can theoretically run most of our sensors at
> about the same rate, with the likely exception of GPS unless we do BPF
> on raw pseudoranges.
>> 2.  Without a common time stamp and a way to adjust/filter the measurements
>> coming in how can we calculate a dt ? for the predictive part of either
>> filter.
> Not sure what you mean here by "dt for the predictive part"; could you
> explain?
>> The big problem with particle filters is that they degenerate and we want to
>> be able to give many  particles the opportunity to participate in the
>> update.
>> Are there any tech specs about the sensors?  Online or somewhere?
> Likely, to the extent we've selected the sensor hardware we plan to use.
> We should also have specs for the sensors we used on the previous
> rocket.  I don't know where we keep either of those, though.
> - Josh Triplett
> _______________________________________________
> psas-team mailing list
> This list's membership is automatically generated from the memberships of the 
> psas-airframe, psas-avionics, and psas-general mail lists. Visit 
> to individually subscribe/unsubscribe yourself from 
> these lists.

psas-avionics mailing list

Reply via email to