[SOLVED] Selecting an ultrasonic sensor and interface

Firmware/software/electronics/mechanics
Post Reply
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

[SOLVED] Selecting an ultrasonic sensor and interface

Post by alex »

Hello dear CF addicts,

I would like to improve the altitude-hold mode by implementing an ultrasonic sensor from MaxBotix. Those sensors are mentioned in several tutorials on the CF, for example:
This guy is using the analog version LV-MaxSonar-EZ0 with rather wide beam characteristics. In the guides mentioned above he uses the ADC of the CF to read an analog voltage directly correlating with object distance.

MaxBotix offers an article about sensor usage in multi-copters. They instead recommend sensors with rather narrow beam characteristics (EZ4) for improved robustness against acoustic and mechanic irritations, also depending on the desired communication interface.

What sensors do you recommend? What are the pros and cons of narrow or wide beam characteristics if I use the sensor to measure the CF's distance to the ground?

In addition I prefer communicating over I²C, but the I2CXL-MaxSonar-EZ4 operates from 3.0-5.5 V which is over the voltage of 2.8 V the CF can supply, correct?
Can I bypass that by using an step-up voltage regulator like this one? Are there any disadvantages from that?

I would be glad if my questions start a discussion about the pros and cons of the above points and thus give me some hints for implementing a more stable hover mode using an ultrasonic sensor supported by the barometric sensor, eventually. :D :idea:


Thanks for reading!

-alex
Last edited by alex on Fri Jan 23, 2015 10:15 pm, edited 2 times in total.
tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by tobias »

Hi Alex!

We have not experimented much with ultrasonic range sensors but it will be very interesting following your progress! We will do our best to answer any questions you have.

I would try first to run the I2CXL-MaxSonar-EZ4 from 2.8V. If that doesn't work there is a trick you can do to get it to 3.1V described a bit in this post. A step up will be a good filter of the noise though and depending on how sensitive the sensor is, it might be better to use one but I would try without at first.
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

Hey tobias,

thanks for your input, that's the kind of input I was hoping for.

Greets
alex
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

Yesterday I managed to calculate the copter's vertical speed and vertical position by deriving the vertical acceleration (without gravity) once or twice.

The problem ist the heavy drift of the accelerometer measurements leading to a continously rising error in velocity and position. The hover code tries to compensate that by merging the vertical speed with an estimated speed based on barometer readings. Since the barometer readings are pretty unreliable (as stated above), I wonder if there is a better way of overcoming the accelerometer drift to get usable vertical speed and position values.

How does the copter's stabilization algorithm deal with that?
I noticed some bias calibration functions running at start up - isn't that the point to start from or has this already been incorporated when I use the acceleration readings for further calculations?

Would be glad for some information about that. Thanks.


Note: I know I could merge the signal of the ultrasonic sensor with the above acceleration based readings to get rid of the drift. But I'm more interested in on-board solutions at first.
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

No suggestions so far? Did I express myself unclearly?
tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by tobias »

Missed your post alex.

The accelerometer is not calibrated at all and that might be a first step of improvement but I'm not sure it will help that much actuality. The barometer fusion kind of takes care of that but pressure isn't that reliable either. It is a tricky thing to solve and an easy solution is to add a range device as you have.
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

tobias wrote:Missed your post alex.

The accelerometer is not calibrated at all and that might be a first step of improvement but I'm not sure it will help that much actuality. The barometer fusion kind of takes care of that but pressure isn't that reliable either. It is a tricky thing to solve and an easy solution is to add a range device as you have.
No problem, tobias.

So what is the bias calibration at startup for? The stabilization algorithm obviously does some kind of drift compensation (without the barometer, just by using the other IMU sensors), otherwise it would run into problems, wouldn't it? Sorry, maybe I haven't got the point yet... :? Where is it taking place?
tobias
Bitcraze
Posts: 2339
Joined: Mon Jan 28, 2013 7:17 pm
Location: Sweden

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by tobias »

The calibration at startup is mainly for the gyros to zero the bias. This will lower the gyro drift, which the sensor-fusion algorithm will do in the long run as well but it is better to get a good start :-). As the accelerometer is mainly used as a reference to the gravity it is more important that it is level, however when you start using it for altitude hold the values start to be important as well.
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

Hey guys,

took me some time to get started with this project, but now I'm on track.

By now, I bought the Maxbotix I2CXL-MaxSonar-EZ4 (MB1242), which communicates via I2C. As it expects a minimum of 3.0 V, I connected it to a Polulu voltage step-up regulator NCP1402 supplying 3.3 V.

The whole circuit is placed on a breadboard which is in turn wired to the Crazyflie's expansion port using a messy self-made solution... :-)

Maybe the sensor would also work with the digital voltage of ~ 2.8 V provided by the copter. I'll try that as one of the next steps when it comes to shrinking the whole thing down to fit onto the copter's PCB.

As mentioned above, goal one is to get a direct distance measurement using the stated ultrasonic sensor. The indirect range values calculated from the on-board barometric or inertial units aren't stable enough, at least without heavy filtering. By fusing them with sonar range readings, I expect a huge improvement.

Next step will be a more reliable hovering mode thanks to the combined range measurements.

Enough of all the things you already know anyway, here are the pictures:

Alex' Crazyflie Gallery

Thanks for your comments or suggestions!


Currently, I'm heavily diving into Git. I can recommend the following guide which helped me a lot in understanding the basic concepts: Think Like (a) Git

In addition I ran into serious communication problems with my CF. The connection is highly unstable, lagging and is lost after a few seconds with the error message "Connection to radio://X/X/X lost: Dongle communication error (ackStatus==None)". Couldn't figure out what's the problem until now. Didn't have this issue some weeks ago. Both the (custom) firmware and client are up-to-date. Any suggestions on that?


EDIT:
Figured out that my custom firmware was the problem, after some changes the connection is stable again.
Still receiving only zeroes from the sensor, but I'm working on it. Have to have a look at the already implemented I2C calls for reading from the on-board sensors, though.
Last edited by alex on Wed Aug 06, 2014 3:07 pm, edited 1 time in total.
alex
Expert
Posts: 137
Joined: Mon Feb 18, 2013 11:36 am
Location: Germany

Re: [Hover] Selecting an ultrasonic sensor and interface

Post by alex »

Sorry for self-replying, but don't hesitate to post some feedback. ;)

I'm struggling with reading from the sensor after telling it to take a range measurement as stated in the datasheet.

Please, have a look at the datasheet (p. 4-6) and give me a hint what I am doing wrong:

Code: Select all

#define SONAR_UPDATE_RATE_DIVIDER	50	// 500 : 50 = 10 Hz

static uint8_t sonarBuffer[2];
static uint16_t sonarDist;
static I2C_TypeDef *I2Cx;

if (++sonarCounter >= SONAR_UPDATE_RATE_DIVIDER)
      {
    	  if (requestedSonarReading == true)
    	  {
    		  // Read high byte of range reading.
			  i2cdevReadByte(I2Cx, (uint8_t)0x225, I2CDEV_NO_MEM_ADDR, &sonarBuffer[0]);

			  // Read low byte of range reading.
			  i2cdevReadByte(I2Cx, (uint8_t)0x225, I2CDEV_NO_MEM_ADDR, &sonarBuffer[1]);

			  sonarDist = (((uint16_t)sonarBuffer[0]) << 8) | sonarBuffer[1];

			  requestedSonarReading = false;
    	  }

    	  if (requestedSonarReading == false)
    	  {
			  // Write command 0x81 to request a range reading.
			  i2cdevWriteByte(I2Cx, (uint8_t)0x224, I2CDEV_NO_MEM_ADDR, 0x81);

			  requestedSonarReading = true;
    	  }

    	  sonarCounter = 0;
      }
Of course the outer if statement is located in stabilizerTask.
Do I have to do something else with the pointer I2Cx than just declaring it - it simply gets passed over to the I2C low level functions, doesn't it? What is it for exactly?
Is there anything wrong with the I2C function calls or their sequence regarding the timing specification? Could someone please double check that?

Thanks very much in advance!
Post Reply