Developer

Hokuyo Laser Range Finder needs a home

3689493615?profile=original

I received a 2D laser range finder from the good people at Hokuyo more than 1 year ago.  My plan was to try to use it to improve ArduCopter's altitude hold or collision avoidance but other priorities have taken up my time and it has ended up sitting in it's box all that time occasionally making me feel guilty so I'm giving it away!

It's a fairly expensive sensor I believe (>$1200), beyond what most people are willing to spend for a diy project but universities seem to use them regularly.  Some specifications which can also be found here:

    sensing field of 240 degrees

    range of 6cm ~ 10m with 1cm accuracy

    completes a full scan in 0.1 seconds

    Serial or USB interface

    500mA power consumption

    160g

 

Ideally I'd like it to go to someone who can do the following:

  • build an arducopter library to communicate with the sensor.
  • incorporate the sensor's output for altitude hold or object avoidance.  This would likely involve:
    • adding a new throttle or roll-pitch mode to the main code
    • if used for object avoidance, adding a new PID controller to allow setting the response to objects sensed
    • adding a new parameter to enable/disable the object avoidance
  • perhaps most importantly you must have the time and desire to see the project through (something that I clearly failed at!).

By the way, this free sensor comes with free advice from me to help you overcome any code problems you face.

So if you're interested in this sensor please email or PM me and if you've got a better idea of how to use it than what I've written above that's also great!

I imagine a few people will want this sensor and I only have one so apologies in advance for those deserving people that I might not choose!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • As the none to quick recipient of this sensor, I feel I should chime in here too.

    I have gotten the sensor up and operating on a PC and made a few determinations.

    For the original intention of possibly using it as a AGL Lidar it could be made to work but is inappropriate for quite a few reasons.

    It is quite mechanically sensitive and would be very easy to irreparably damage in even a minor landing (mishap).

    A simple laser altimeter that is not scanned is actually much more appropriate (and cheaper) for altitude determination such as this one: http://diydrones.com/forum/topics/lightweight-low-cost-laser-altime...

    Range is also too short, especially outdoors in full sunlight to be useful for an altimeter (practically less than 4 meters).

    It could be conceivably useful on a multicopter for obstacle detection and avoidance, but it's real value because of it's range, mechanical fragility and other limitations is on a ground vehicle such as an ArduRover or Robot.

    In that regard;

    I am now constructing a 2 wheel hanging pendulum robot utilizing brushless bicycle wheels which will incorporate both the laser scanner and a Kinect structured light device. However, initially at least they will both be connected through an on board PC which has both the existing software and sufficient performance to permit them to provide useful data.

    Initially I will be using an APM as the control system as it has sufficient easily accessible IO which the PX4 does not, but I will be converting to the Pixhawk when practical and it is quite feasible that the Pixhawk will have sufficient performance and memory facilities to permit the direct extraction of at least sense and avoid and possibly SLAM directly from the laser scanner.

    The Hokuyo scanner and Kinect will be mounted on a roll pitch stabilized brushless gimbal.

    The x scanning Hokuyo will also be independently and dynamically y scan-able providing an adjustable scan grid.

    I am assembling the robot chassis now and will be presenting a Blog for it at each stage of it's development.

    Randy, I am sorry I had not gotten back to you sooner, but life, the wiki and getting going on the robot have taken a bit longer than expected.

    I do expect to have the chassis together within a few weeks now though and I think you will be impressed.

    It is sort of at the other end of the spectrum from Jason Short's lovely little self balancing robot, more at the Mac Truck end of things.

  • Developer

    Maverick,

       The sensor is long gone!

  • Hi there, I am currently working towards an Indoor Navigation Project with the Arduino Board. Due to a shoe string budget, my school can't offer us such technology to program it. My team and I would be keen to take up this project and work towards the goals you have listed above. Perhaps we could discuss this? Plus you mentioned that you could advise us on programming which would be a plus point to us.

  • Developer

    Zhang,

         I guess that's possible and I can see why you might choose that method - because it allows you to treat arducopter as a black-box but then you won't have a GPS anymore and it seems like a very indirect solution.  If it were me, I would create a new roll-pitch mode that allows you to pass in desired roll and pitch angles from the gumstick .. or perhaps make the arducopter talk to the gumstick using i2c or SPI and then put the object avoidance code inside the main arducopter code.

  • Hi Randy, it's me. Zhang from CHINA, Our lab is using this Laser Range Finder for indoor postion hold and navigation, we used gumstix to calculate the position and send it to dsp-based flight control board developed by ourselves, it works fine for the most of time but crashes happened without any reason, nobody knows why it jumped to the ceiling. So we are trying to use arducopter board in stead of that home made flight control board. we are planning to imitate GPS protocol in gumstix, and connect it to the gps port on the APM board, does the plan sound feasible? Do you have any suggestion on choosing the protocol? NEMA or Ulbox or MTK?

  • Developer

    Ok, it's been given away.  It took me a while and I'll blame it on the trials and tribulations of the 2.9/2.9.1 release.

    It was a very tough choice which is also why it took me so long to decide.  In the end I picked the one who gave the most detail on what he/she knew about the sensor, the issue and what they were going to do about it.

    I wish I had more than one to give away!  If you weren't the winner at least take heart that the sensor is going to someone who will put it to good use instead of sitting in my drawer for another year!

  • I would think this one ^ is worthy. We already have accurate and cheap altitude sensors, so object avoidance seems to be the only viable use for something like this. I know that it's something I would like to see happen. Once someone comes up with a workable code base It should be pretty easy to port if over newer, cheaper sensors.

  • Hi John, I Researched the Neato vacuum a bit and found out it also has a 4 meter range and similar resolution to the Hokoyu and it works for a full 360 degree circle. It has been hacked and looks like a very simple interface. I think this could be an excellent tool for Multicopters for object avoidance and for mapping. You can pick the entire vacuum up new on EBay for just over $200.00. I don't know the weight, but I am definitely looking into it. Thank You for mentioning it.

  • Small correction, from looking at Hokuyo Specs, I think it looks more like 4 meter maximum range.

  • I wrote a QNX/C library for this model a few years ago for university but no longer have the source. There is plug-and-play gpl code for USB usage around so someone should be able to port from the Carmen Toolkit, ROS, or one of the others. The sensor fusion stuff is where it gets interesting :) I look forward to seeing someones video of it on a quad.

This reply was deleted.