Search options (Page 69 of 135)

The sensor glove is very interesting!
My know-how in electronics is close to zero a the moment but hooking an accelerometer to a small Arduino board has been done. Many applications. And accelerometers are probably quite cheap since they are manufactured by the millions for smartphones. This could probably be used to measure rotation speed of the arm or racket/bat, something impossible to do on 2D video.

I hadn't even thought about capturing EMG data. I can't comment on the science of muscle shortenning as my biomechanical courses are too far away and I have filled my memory with other stuff…

This log reports version 0.8.15 but the original dump you posted was for 0.8.20… Do you happen to have the two versions installed side by side ? Does the issue happen with both ?
In 0.8.20 the log should be much more verbose because it's an "experimental" version and the logs are set to "debug" level.

In the spreadsheet it is the x,y coordinates of each point.
In recent versions, these coordinates are relative to the origin of the coordinate system, as set up from Image > Coordinate system (or set up from a perspective grid system if using 0.8.20).

When using the "Distance" measurement label from the path configuration dialog, the label shows the total distance covered by the path up to the current point.

So the two functions are not meant to display the same values. In a way the data exported in the spreadsheet is lower level. You could recompute the total distance from the coordinates if needed.
Similarly, speed is not exported in the spreadsheet, but could be recomputed from the x,y,t coordinates.

Hope that helps.

The next experimental version(s) should be dedicated to updating/upgrading the capture features.

Voici une formule pour calculer la durée max du délai:

 durée = (mémoire × 1048576) / (largeur×hauteur×3×images par seconde)

Avec
- mémoire : voir dans Options > Préférences > Capture > Mémoire.
- On multiplie par 1048576 (=1Mo) pour avoir la valeur en octets.
- largeur, hauteur : en pixels, voir dans la fenêtre de configuration de la caméra.
- On multiplie par 3 pour avoir la valeur en octets.
- images par seconde : voir dans la fenêtre de configuration de la caméra.

Par exemple, 640×480 px @ 30fps avec en préférences mémoire 768Mo.

(768×1048576)/(640×480×3×30) = 29.13 s.

Il peut y avoir des variations car le nombre d'images par secondes est estimé à la volée plutôt que lu dans la configuration.

J'espère pouvoir faire dans le futur une version avec la possibilité de stocker les images pour le délai sur le disque plutôt qu'en mémoire vive, ce qui permettrait d'avoir des délais beaucoup plus longs.

Bonjour,

Pas tout à fait. Cependant dans la prochaine version on peut utiliser la grille de perspective en tant que système de coordonnées. Donc après avoir calibré la grille, en indiquant les dimensions de la table, il sera possible de récupérer les coordonnées des impacts dans le « repère table ». À partir de là il devrait être possible de recréer le nuage de points des impacts sur la table.

Ça me parait difficile en 2D. Si jamais la trajectoire de la balle est pile sur le plan de la caméra on ne verra pas de changement de trajectoire au moment du rebond… Surtout en vue verticale ? À moins que l'effet modifie systématiquement la trajectoire… J'avoue que je n'ai pas d'exemples de tennis de table vu de haut, si vous en avez ça m'intéresse.

Je ne sais pas si le suivi de trajectoire est suffisamment robuste pour faire le tracking d'une balle de tennis de table… Il faudra surement une bonne caméra à l'entrée.

En tout cas avoir un système qui dissémine des marqueurs le long d'une trajectoire en fonction d'évènements particuliers de cette trajectoire serait intéressant. À creuser.

Pour le tennis le système utilisé (Hawk-Eye) est très avancé. Il me semble qu'il y a 10 caméras haute-vitesse réparties autour du court et le logiciel reconstruit la trajectoire de la balle dans l'espace…