search

michaelcheng1991 / Golf-Training-Aid-

Using sensors to create a golfer-friendly teaching device
0 stars 0 forks source link

3D tracking using MatLab #23

Open michaelcheng1991 opened 8 years ago

michaelcheng1991 commented 8 years ago

the code doesn't work but it's worth a try later?

http://www.mathworks.com/matlabcentral/fileexchange/25730-inertial-measurement-unit-position-calculator

michaelcheng1991 commented 8 years ago
screen shot 2015-10-26 at 6 13 50 pm
michaelcheng1991 commented 8 years ago

Great Example of how to log data using Matlab http://robotgrrl.com/blog/2010/01/15/arduino-to-matlab-read-in-sensor-data/

Read again if stuck/ backward This solved everything up to returning data using MatLab http://www.mathworks.com/matlabcentral/answers/144385-storing-arduino-serial-data-to-cell-array

michaelcheng1991 commented 8 years ago

data is sending fine on arduino Serial monitor but matlab won't get data, and this could be caused by http://www.mathworks.com/matlabcentral/answers/247471-arduino-serial-read-bug

USB is not a dedicated channel. USB is a system whee a master device goes around polling the attached devices asking each one in turn if they have any data to send. If they do and it is a relatively small amount of data they might reply with the data, but if it is more data they they are just to reply Yes and the master will get back to them when there is time for them to send the data.

Because of this behaviour, when data is ready to send, it cannot just be sent: the device has to wait for the master to tell it to go ahead.

In documents I read a few years ago but am having difficulty locating now, I found that furthermore, for serial-port emulating devices, USB is designed to wait until either a complete packet is full or else that no data has been received for a time before it will release the packet. This is good for efficient use of shared bandwidth but it is not good for latency. If your bytes are available more slowly than the wait for data then you don't really notice much (provided that your data is not too time sensitive), but after a point you get stuck: before the end of the wait period you get another byte and since the packet isn't full yet the timer restarts.... only to be interrupted by the next packet. And so on, until the packet is full. This can end up with longer latency than if the data rate was slower. But, hey, it is efficient use of the bandwidth and that is what is important, right?

So... you might not get data for a while. And you might time-out if you are not set to handle the worst-case of the timer being reset just as it was due to expire, over and over again. And even if that does not happen, batches of bytes arrive rather than single bytes and your code might not expect that...

Serial over USB is... Bovine Growth Hormone... for data acquisition unless both sides know how to trigger immediate data sending (which requires talking to the master device, and which MATLAB does not provide an interface for.)

michaelcheng1991 commented 8 years ago

this is a matlab code that use to get data/ using tic toc, take a look if you change your mind to use matlab to code completely http://www.mathworks.com/matlabcentral/answers/56911-how-can-i-optimize-data-acquisition-e-g-buffer-and-sync-inputs-using-arduinoio-package

michaelcheng1991 commented 8 years ago

Dead reckoning (https://forum.sparkfun.com/viewtopic.php?f=14&t=24187)

It is useful to first summarise the core process we are dealing with: Accelerometer and gyroscope data are fused into a single orientation measurement. This attitude relative to the Earth surface is then used to remove gravity from the accelerometer measurement. The result is integrated to obtain a velocity. Integrating this velocity then yields the position.

As Cannibal has already suggested, the dominant error behaviour comes down to any non-mean-zero error in the velocity resulting in a run-away error in the position.

Errors in the accelerometer measurement obviously play a part but both these errors and errors in the gyroscope will affect the orientation measurement. It is errors in the orientation measurement that are by far the most significant source of error you must deal with. Consider that an off-the-shelf IMU (e.g. xsens, VectorNav, MicroStrain, etc) typically costing $1000+ will quote pitch/roll errors of 1 degree. This would result in an acceleration error of approximately 9.81*sin(1) = 0.171 m/s/s. After 10 seconds the velocity error is already 1.71 m/s so even just sitting still for a few minutes could see the estimated position in the next town.