Knee bending in the wrong direction

daylanKifky

Hi!
yes, as you said the knee problem is more consistent in this video.
The only thing I can think of trying would be to make the test outside, I assume these ones were done in your apartment, right?
It would also help if other users with working suits can confirm this problem is not occurring to them. So far I haven't seen anyone else with this particular issue.
Perhaps you could send us the sensors to test them here

ShiroSaki

in blender 2.9.2

QUATERNION Quaternion (WXYZ), No Gimbal Lock.
with the calib box downloaded from the site, the Chordata_node.cpp should edit the line 449 to

Quaternion q(the_quat.q0, the_quat.q2, -the_quat.q1, the_quat.q3);

I will open a pull-request later

daylanKifky

ShiroSaki
Hi!
Exactly which issue should be solved with this modification?

ShiroSaki

daylanKifky after I modified this, in my blender(2.9.2) all the ceptors worked correctly. before the modify, all the ceptor's x and y are not in the right position. when I lift up my arm, the module in blender will rotate. and when I rotate my arm, the module lift up the arm.

NGWORKS

daylanKifkyAccording to the test, the project does have the situation of X axis and Y axis interchange (that is, the rotation along X axis is settled as rotation along Y axis). I think this situation may be caused by the different properties of the coordinate system (the difference between the Blender coordinate system and the sensor coordinate system).

daylanKifky

ShiroSaki

It sounds strange to me. I still haven't tested it in blender 2.9.2, but it sounds unlikekly that they change the sign of one of the Quaternion components from one release to another.

Could you elaborate why you choose to negate the Y component of the Quaternion and why it was causing troubles before?

I will test it with a suit as soon as possible

ShiroSaki

daylanKifky
The calib box provided in the site https://chordata.cc/wp-content/uploads/2019/04/CalibrationBox.pdf
Seems not the same as https://wiki.chordata.cc/wiki/File:Magnetometer_calibration.gif)
Maybe this difference cause the bug?

ShiroSaki

daylanKifky After talking to @NGWORKS we found out that

is not using the same Coordinate System.
Maybe this is the true reason why the ceptor is bending to the wrong direction

Elediko

ShiroSaki but have you been able to fix with your build?...

ShiroSaki

Elediko after modify the line my blender works. you can make a try.

Elediko

ShiroSaki ok..
Do you experience any jittering?...like sensors moving in the viewport while they are idle in real-world..

You can show a video demonstrating while using the suit..🙂

ShiroSaki

Elediko https://www.bilibili.com/video/BV13K4y1T7R8/

daylanKifky

The translation between coordinates system is done when feeding the sensor data to the sensor fusion, as in Chordata_node.cpp:434

Elediko

ShiroSaki the sensors on the legs are misbehaving..daylanKifky if you look at the video..the sensors on the legs are not stable but the remaining part of the body is ok(almost zero drift)..why is it that way?...or is it because of the hardwares?...I saw in a post you wanted to adapt the new hardwares to DIY... should everybody continue with this build or wait for the adaptation of new hardwares..cause this seems to be very buggy..

I ordered my parts of hardwares few days ago...but not PCBs...

daylanKifky

The problem is that the system currently doesn't implement a translation estimation, take a look here: https://forum.chordata.cc/d/171-displacement-of-x-y
What you see in this video is the base bone fixed in a X-Y position in space, while the feet displace.

The hardware aspect is a completely different question. The translation estimation will be available regardless of the hardware you are using.

With that said, we are working in a new revision of the DIY hardware that will incorporate many of the features we added to the ++ version. In this new revision why might change the IMU sensor because of the current difficulties in finding supplies of the LSM9DS1, see here: https://forum.chordata.cc/d/154-source-for-the-lsm9ds1-chip/8

So if you already have the components a good option would be to build the mini version of the hardware created by @valor with the new Hub as HAT created by @ShiroSaki

daylanKifky

The transformation between different coordinate systems is a pretty common step when dealing with this type of technology. The LSM9DS1 doesn't even have a common coordinate system for all three of its sensors, take a look at the page 10 of the datasheet

But, as I said this transformation is taken into account when feeding the sensor data to the sensor fusion algorithm. The "knee bending in the wrong direction" problem that @AxonSpark is experimenting would probably have to do with a more subtle bug

« Previous Page