Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 25 14:07
    fvantienen synchronize #2883
  • May 25 14:06
    fvantienen synchronize #2883
  • May 25 12:11
    fvantienen edited #2884
  • May 25 12:10
    fvantienen opened #2884
  • May 25 12:10
    fvantienen labeled #2884
  • May 24 21:35

    gautierhattenberger on master

    [sphinx] Adds Logging section i… (compare)

  • May 24 21:35
    gautierhattenberger closed #2882
  • May 24 10:34
    matteobarbera commented #2882
  • May 24 10:29
    matteobarbera synchronize #2882
  • May 24 10:25
    matteobarbera synchronize #2882
  • May 23 13:56
    fvantienen edited #2883
  • May 23 13:01
    fvantienen edited #2883
  • May 23 12:54
    fvantienen synchronize #2883
  • May 23 12:54
    fvantienen synchronize #2883
  • May 23 12:48
    fvantienen synchronize #2883
  • May 23 12:43
    fvantienen synchronize #2883
  • May 23 12:00
    fvantienen synchronize #2883
  • May 20 13:17
    fvantienen synchronize #2883
  • May 20 09:41
    fvantienen synchronize #2883
  • May 20 08:07
    fvantienen opened #2883
Jesús Bautista Villar
@jesusBV20
Hello @Fabien-B. I'm working on trying to integrate GVF with your C++ version of GCS. My objective is to design a custom layout that will introduce a "draw GVF" buttom. When you press it, GCS should read (or send the order to read) the specified messages info (GVF, GPS, NAVIGATION...) from the Ivy bus and draw the desired trajectory + vector field. We already have an example external app built in Python: "sw/ground_segment/python/gvf/gvfApp.py". Is there any tool from PprzGCS that we can use to build this feature??
Jesús Bautista Villar
@jesusBV20
I know that I can send the "SHAPE" msg from python with indications to draw lines and custom polygons. But I think that It's a little tricky to draw a vector field with this tool
Freek van Tienen
@fvantienen
I got a simple question.. since we are currently flying > 71 minutes with different platforms if it would be a good idea to introduce a time_t typedef? That way we can increase the default uint32_t size to uint64_t for specific platforms. What do you guys think about this?
This is specifically for the abi messages
Since we are also missing a lot of overflow protections and multiple points
Gautier Hattenberger
@gautierhattenberger
@fvantienen I don't mind introducing a proper time or timestamp type. I'm even wondering if this should not be included to the mandatory fields, but maybe it is too much work to update all the callbacks.
Hector Garcia de Marina
@noether
@fvantienen where is exactly the problem (overflow I guess?) ? I remember flying for almost 3h with two airplanes, and the displayed mission time in the GCS was okei (I believe it comes from the autopilot)
Fabien-B
@Fabien-B
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?
Freek van Tienen
@fvantienen
@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.
There might also be other problems, thus I wanted to prevent those. I didn't check everything, but not handling an overflow seems like introducing problems for the future. Especially in the abi calls it isn't meantioned when the stamp is overflowing
We also have flown for more than 3 hours with 1 drone, but sometimes it can also be luck with overflows
Freek van Tienen
@fvantienen
Anyone against removing (not used in any conf file):
  • 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
Will make a PR but giving you guys also a chance to respond here
Since I'm rewriting and updating larger parts I don't want to spend time on non-used/supported platforms if needed
Freek van Tienen
@fvantienen
Gautier Hattenberger
@gautierhattenberger
@fvantienen At least for my part, I don't mind. And we don't have much news from the people who have developed those drivers since a long time
Too bad for the swing, I have one standing behind me for years...
Freek van Tienen
@fvantienen
It is also not that it is lost forever, it is still somewhere in the git history. But it seems a bit pointless to keep updating not-used parts
But thanks for your response :+1:
Freek van Tienen
@fvantienen
I fixed the apogee again @gautierhattenberger paparazzi/paparazzi#2859
Jesús Bautista Villar
@jesusBV20
Okey @Fabien-B, thanks for your answer. I'll give it some time to search for a solution. I'll tell you if I find something.
Hector Garcia de Marina
@noether

@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?

for our case, since we are generating trajectories pixel by pixel from a parametric equation, it should be okei if we can just plot a dot xD, but indeed to have a canvas would be great
Gautier Hattenberger
@gautierhattenberger
For timestamp, I think that as long as you use it as compute a time difference it should be fine, but if you use it as absolute time, then it is problem. In most places, in particular IMUs, it is used as a time difference.
Freek van Tienen
@fvantienen
@gautierhattenberger If you have time could you check and merge/approve paparazzi/paparazzi#2878 paparazzi/paparazzi#2880 paparazzi/paparazzi#2881 ?
Freek van Tienen
@fvantienen

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.

Freek van Tienen
@fvantienen
Thanks a lot @gautierhattenberger !
Gautier Hattenberger
@gautierhattenberger
@fvantienen I have not yet looked at your new driver, but I think that only IMU drivers should see the sensor / IMU frames (and send it for calibration), and ABI messages should send scaled data in body frame (so that each IMU have it's own configuration of imu2body and calibration).
Freek van Tienen
@fvantienen
I have that sort of now, though it has an intermediate sensor2imu, since you want to be able to rotate/calibrate between sensors. But as you suggest I think it is best to use that RMAT and combine it with the imu2body to create a sensor2body RMAT. That way RMAT translations are only done once.
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.
Currently an IMU driver can at init do a 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.
Freek van Tienen
@fvantienen
@gautierhattenberger Does anyone of you know why some of the semaphoreci outputs are empty like this one: https://semaphoreci.com/paparazziuav/paparazzi/branches/pull-request-2883/builds/3
Fabien-B
@Fabien-B

It says

Errors during submodule fetch:
    sw/ext/pprzlink

at some point it used to fail with the same error for Eigen submodule, don't know why.
Try launching the build again?

Freek van Tienen
@fvantienen
Hmm might know why.. it updates to a newer pprzlink
For me everything is empty. Does it have to do that I have no rights to see these outputs somehow in smephore?
If that is the case could I maybe get some more rights, as it makes it easier to debug
Freek van Tienen
@fvantienen
I pushed the update to a branch of the original pprzlink repo, so that it should be able to access it. So weird that it is unable to fetch
Freek van Tienen
@fvantienen
@gautierhattenberger paparazzi/paparazzi#2884 there are some bugs maybe laying around in the code that are not easy to find..
With a 0 angle BODY_TO_IMU this wouldn't be a problem, but I think we should make a scanner to search for these problems
I found this one by accident while rewriting the IMU
We could also implement some asserts in the math library to find possible problems
Freek van Tienen
@fvantienen
Does anyone have any suggestions on how to find these problems fast and easy? I can create a grep for each of these functions, but not sure if someone maybe knows a better tool?
Hector Garcia de Marina
@noether
@fvantienen sorry for the question, but I do not see why using the input/output with the same variable is a problem, float_rmat_transp_ratemult(&body_rate, body_to_imu_rmat, &body_rate);
void float_rmat_transp_ratemult(struct FloatRates rb, struct FloatRMat m_b2a, struct FloatRates ra)
{
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;
}
you mean that here, if you assign rb.p first and then you use later ra.p
it is actucally rb.p (the new value) and not the initial one?
2 replies
Gautier Hattenberger
@gautierhattenberger
@fvantienen functional programming is your friend :)
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
Hector Garcia de Marina
@noether
haha
Freek van Tienen
@fvantienen
That would be nice indeed, since there are quite some functions where the input != output. Though finding them with static analysis is harder and sometimes even impossible fully, it will already find some of these bugs I hope.
Then next to that I think it is good to implement a pprz_assert(..) or sth like that. While debugging we can then find these problems way easier
Freek van Tienen
@fvantienen
Hmm.. I'm also doubting to just change the functions to be able to accept the output to be the same as the input. It might cost some performance copying, or if we make them inline the compiler might optimise it out wherever it can. Because for developers it is not very clear while programming that these functions don't allow input equal to output.