Bitcraze Forums

Hi,

I have created a pull request (hopefully in the correct way):
https://github.com/bitcraze/crazyflie-f ... l/57/files


It contains the following updates:

* Contains only the deck API parts
* NOTE: Now using ADC2 instead of ADC1. This since ADC1 has temp and vref internally wired to it, so a more optimized use of ADC1 at a later stage may be relevant. If you prefer to use ADC1 for the "arduino-style" calls instead, please let me know.
* gpioMapping struct is now placed in deck_constants.c, with a typedef and external declaration in deck_constants.h
* gpioMapping was renamed deckGPIOMapping, since it is now part of an API exposed to the rest of the code base, thus prefixing with "deck". Hope this is OK.
* adcMapping was merged into deckGPIOMapping
* the DECK_PIN_XX definitions were moved to deck_constants.h, and renamed DECK_GPIO_XX for consistency.
* Some minor cleanups.

The only comment I have is that the connection to the stabiliser loop: it is a bit intrusive. We will need at least an #ifdef to merge it. Anyway this is a problem we have had since the begining and we will need to find a way to make internal connection a bit more modular (maybe something like allowing deck driver to feed an altitude and the stabilizer to use the best available altitude source)

Yup, agree completely, that was just a dirty hack to test the deck_analog API and the sensor, it was not meant for merging it its current state. I have removed all the MaxBotix related code and dirty hacks from the pull request.

Auto take-off would be really nice!

I am working on take-off-by-throwing, basically detecting free fall and subsequently starting altHold. You can see my comment on this in another thread here:
viewtopic.php?f=6&t=1584#p8308

The plan is to get the proximity sensor integration (in this thread) in place to add a function which detects close proximity (directly underneath the crazyflie) while in altHold mode, and if detected, stop the motors. This should make it possible to pick a hovering crazyflie out of the air.

The two features are part of a bigger effort to make the crazyflie simpler and safe to fly with, especially for my kids.

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?

You are moving quick!

* 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.

We had some grand plan for this but as grand plans never tend to be realized it is better to take it one step at a time...
One possible solution is that we continue on the OW ID path with a runtime configured subsystem as the OW information contains information to discover conflicts etc. We would then create OW VID/PID to describe these setups. There is a possibility that the system will be flooded with this in the end and it will also require more flash/mem (which there is plenty of right now though). What I mean is we create/reserve e.g. a hacker VID. Under that people can create a PID for their setup which will setup their particular stuff. Then we make a compile switch that hard codes this ID to be active even though there is no OW mem for it.

Arnaud made some sample code for how a driver could be setup and that is something we are still aiming towards. It might take a while to get there though so right now I think we can go with compile switches in config.h. I Think though it might be better to have the main switch in config.h and detailed settings in the module header file. That way config.h wont grow and get unreadable in the end.

Which branch do you prefer we create pull requests towards moving forward? master, crazyflie2 or bigmerge?

As of now we will use master as the main branch. We might create a develop branch in the future but as of now we don't see the need for it. Code in branches tend to be forgotten and never get finished and merged.

Hi,

thanks for your response, I have placed a minimum of configuration options in config.h, and the rest in the drivers / modules respective .h file.

Several cleanups and improvements since last patch, see the pull request here:
https://github.com/bitcraze/crazyflie-firmware/pull/58

The proximity is a hardware abstraction layer for proximity sensors.

Provides a new "proximity" task for sampling from proximity sensors. Task/sampling frequency is configurable in proximity.h
Proximity layer provides unprocessed samples from drivers, in addition to average values and median values.
A sliding window of samples (size configurable in proximity.h) is used to calculate the average and median values.
Proximity layer also reports the accuracy of the samples as / if reported by the sensor driver.
Log group "proximity" available (disabled by default in proximity.h). See attached image showing the log group (data from the LV-MaxSonar-EZ4) in the plotter view of the cfclient, with unprocessed values (green), average values (blue) and median values (pink).
Also provided is a "maxsonar" driver for LV-MaxSensor-EZ4 (MB1040). Driver is prepared for adding more MaxSensor models.
Both the maxsensor driver and the proximity abstraction layer are disabled by default in config.h
Initial testing with the LV-MaxSonar-EZ4 sensor seems to yield good results with 20Hz sampling, a sliding window size of 9, and reading median values. See attached image.

The first screenshot (with almost flat median values) shows the sensor with a constant distance from a wall. The second screen shot (showing step changes to the median values) shows the values when first introducing and subsequently removing an obstacle between the sensor and the wall.