uint32_t size to uint64_t for specific platforms. What do you guys think about this?
There is currently nothing to draw arbitrary shapes (other than the SHAPE ones).
I think there should be an API to create a map layer, and to populate it. The GVF would be one particular application for it.
The API could allow primitive shapes, it could also match the QPainterPath methods?
- Krooz board + IMU @softsr
- GX3 AHRS @podhrmic
- Drotek_10dof_v2 IMU @gautierhattenberger
- gl1 IMU @agressiva
- ppzuav IMU (From TWOG/Tiny board which are already gone because of LPC)
- swing board + IMU (never fully supported, made by me)
- UM6 IMU @podhrmic
@noether The problem comes forward if you for example do integration using the timestamp difference. Usually also there the problem is minor since you will divide by a very large number so you end up with a 0 measurement when it overflows.
yeah, for the integration I also take the clock in milliseconds, and take the difference (and pray that difference will not be between before/after the overflow). I think for avoiding this kind of issue is to start a clock and reset it every time, maybe chibiOS offers this kind of service
Hi @jesusBV20. I have been thinking about how to implement it, but I had not time to do it, and it's not trivial...
There is currently nothing to draw arbitrary shapes (other than the SHAPE ones).
I think there should be an API to create a map layer, and to populate it. The GVF would be one particular application for it.
The API could allow primitive shapes, it could also match the QPainterPath methods?
I remember I was using Cairo in the past with GTK. Is there something similar with QT?
I'm now also finishing a big IMU rewrite and will make a PR for that soon. Main feature is Multi-IMU support, next to that FiFo IMU's(running at ~9kHz) and integration at IMU level.
Also makes use of ABI where sensors generate IMU_...RAW(not-scaled, sensor frame) ABI messages which the IMU translates into IMU...(scaled, IMU frame) and IMU_..._INT (scaled, IMU frame, integrated, optionally enabled).
There is one question/doubt I'm having on where to apply the body_to_imu rotation. Currently you have a 'sensor', 'imu' and 'body' frame. The new IMU has support for sensor rotations(with RMAT) and converts it automatically to IMU frame. But is there even a need for being able to access the sensors in IMU frame? Else I would prefer to move the body_to_imu rotation to the IMU and let it output IMU_GYRO, IMU_ACCEL and IMU_MAG in body frame. The other advantage is that I can combine the imu_to_sensor RMAT with the body_to_imu RMAT.
This would also mean that the body2imu can be removed from all the INS's since they will receive everything in body frame. The weird fiddling wit the BODY_TO_IMU abi message can then also be removed.
void imu_set_defaults_...(uint8_t abi_id, const struct Int32RMat *imu_to_sensor, const struct Int32Rates *neutral, const struct Int32Rates *scale); and then they can do a AbiSendMsgIMU_..._RAW(IMU_ASPIRIN2_ID, now_ts, &mag);. The imu.c will then take this: scale it, rotate it (to body frame, by combining with the body2imu rmat) and send these values over ABI.
{
rb->p = m_b2a->m[0] ra->p + m_b2a->m[3] ra->q + m_b2a->m[6] ra->r;
rb->q = m_b2a->m[1] ra->p + m_b2a->m[4] ra->q + m_b2a->m[7] ra->r;
rb->r = m_b2a->m[2] ra->p + m_b2a->m[5] ra->q + m_b2a->m[8] ra->r;
}
2 replies
But okay, it's not good that we have these bugs, I'm involved in a PhD on code verification, I will ask my colleagues expert in that area if we can analyze this easily or not. At least for this function, the invariant filter seems to be the only one doing it wrong. Thanks