Hi,
Thanks for merging the pull request
Moving along, I have the following patch ready:
https://github.com/bitcraze/crazyflie-f ... :proximity
Includes:
* MaxBotix driver (using the analog interface of the MaxBotix sensor through deck_analog.[hc])
* New proximity.[hc] API, in the hal/ folder (please let me know if you would prefer another location)
The idea is that proximity drivers (such as the MaxBotix driver) should be simple and relatively stupid, while the more complex handling of proximity should be handled by a hardware abstraction layer. The proximity layer could add functionalities such as sensor fusion, weighting, more sophisticated estimations on accuracies, better filters, perhaps roll / pitch compensation (for ground-facing proximity sensors) etc.
From the commit log:
Initial commit for the proximity measurement subsystem. The intention is for this subsystem to provide a common API for
proximity sensors. The proximity subsystem runs in a separate task, currently running at 10Hz but this is configurable.
Initially the MaxBotix Sonar Range Finder is supported, and the driver is included in mb.[hc].
The proximity subsystem reports distance measurements as well as accuracies of measurements (as reported by drivers).
The current limitation is that only a single proximity sensor is supported at any given time. Currently, that is the
MaxBotix driver.
The proximity system includes a simple function for calculating the average of samples in a sliding window. The sliding
window is configurable for number of samples in window.
Distance measurements are made available to cfclient by both the MaxBotix driver as well as by the proximity subsystem.
The latter also makes the average distance measurement available to the cfclient.
This commit disables the proximity system by default (at compile time). Enable by uncommenting the following defines
in config.h: PROXIMITY_ENABLE and MB_ENABLE
Please let me know your feedback. When you are comfortable with the patch, I'll set up a pull request.
Question 1:
* Do you have some standardized approach to how drivers and subsystems should be configured? I know you have the OW ID system for decks which identify themselves, and this kind of sets the standard that each known deck should be configured / known (in compile time) somewhere, and the runtime detected deck enables the subsystems / drivers needed (on runtime). However many developers who only wire up a sensor or two don't implement the OW ID system (including myself). In such cases, the drivers and subsystems needed must be either be always enabled, or configured on compile time (for instance in config.h). Typically, drivers require GPIO pins to be configured according to the deck attached.
Since I don't use OW ID (yet), the fallback I have used in this patch is just to add a few #defines to config.h. This ensures the subsystems added are not started unless necessary (this is valid for the proximity measurement subsystem), as well as provides GPIO pin configurations for the drivers.
- Is this the approach you prefer, or do we just enable subsystems / drivers we implement as default, without any defines introduced in config.h? - If so, where do we specify the GPIO usage (if not in config.h)?
Question 2:
* Which branch do you prefer we create pull requests towards moving forward? master, crazyflie2 or bigmerge?