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.
Bart
On Tue, May 24, 2011 at 8:18 AM, Josh Triplett <j...@joshtriplett.org> 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
> psas-t...@lists.psas.pdx.edu
> http://lists.psas.pdx.edu/mailman/listinfo/psas-team
>
> This list's membership is automatically generated from the memberships of the
> psas-airframe, psas-avionics, and psas-general mail lists. Visit
> http://lists.psas.pdx.edu to individually subscribe/unsubscribe yourself from
> these lists.
>
_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
