Closed dmiklic closed 8 years ago
Requires the implementation of:
To implement this, both the playground and the casu beaglebone driver(?) have to cyclically process these arrays in order to set the frequency and amplitude of the vibration.
Another alternative would be a thread on the client side that processes these arrays.
Client-side thread is not an acceptable solution, as the requirement is to have stable patterns with 100ms and better period resolution, so it has to be implemented on the CASU firmware itself (in real-time).
For me it's ok if this feature is not exactly implemented in the simulator (e.g. we can just take the first frequency in the array and simulate that, or even better, perfrom FFT on the pattern and simulate that). The controllers for the simulated bees can then be adjusted accordingly.
What will be the maximum size of these arrays? If the user passes a bigger array, I would throw an exception.
It can be whatever we agree on. The partners from UNIGRAZ should specify a reasonable requirement.
I think throwing an exception on oversized arrays is a bit extreme. You should just ignore elements beyond a fixed size that we agree upon. I'll make sure on the Python side that the array is properly sized (and warn the user if he tries to pass an array that's too big)
Proposed prototype:
casu.set_vibration_pattern(frequencies, amplitudes, periods, repeat=True)
The first three parameters are arrays of the same size.