Open annalena00 opened 8 years ago
Ah, just replied to your mail. How did you figure out the 60 Hz exactly? That definitely could be (for a number of reasons..), the most prominent being:
std::list
might not have been the best choice for this orI don't have the hardware at hand anymore, but will gladly look into the algorithms
Thanks for your reply! I figured out the 60 Hz by counting the function calls per second of CCrazyRadio::sendPacket() where m_lstLoggingPackets is filled. Changing the default value of sendAndReceive() unfortunately do not increase the frequency. I found out that the length of a crtpPacket is 0 in many cases, which arises from readAck(), which calls readData() where the libusb function is called. Maybe you are right and sending/receiving should be checked.
Hello again,
I find a way to accelerate the data arrival and for my purposes it should be working now but in my opinion there is somewhere a bottleneck, which I do not find yet.
Since I only need the accelerometer and gyroscope data, I set their frequency to 10ms ( -> m_tocLogs->registerLoggingBlock("accelerometer", 10000) instead of 1000 ) and log the other sensor data every 100ms. Additionally, I changed the m_dSendSetpointPeriod to 0.001s instead of 0.01s.
Now I get accelermeter and gyroscope data at round about 100Hz. In my case it works for max. 3 of 6 sensor logs. More logs cause a very low data rate, it seems they split the data rate. Maybe somewhere the bandwidth is not enough, or some functions should be parallelized or something like that.
Greetings!
Hi there,
while using the library, I wondered that I get the IMU data at only 10 Hz. In contrast, the python library received data at 100 Hz. My inspections give that the m_lstLoggingPackets from CCrazyRadio.cpp filled with new data only at 60 Hz (10 Hz for one sensor e.g. accelerometer). Is it possible that this deals with the use of synchronous functions of libusb? Or does someone have a solution to accelerate the receive of sensor data?
Thank you very much!