Inqling Junior - Robot Mapping, Vision, Autonomy

@inq Wow, what one is that?

Posted by: @inq

Posted by: @will

2) Cetus is now charging $60

Damn... Did you even get kissed for that?

No, and they didn't even pull my hair 🙂

Cetus printers require a custom nozzle, so you can't use the cheap ones. My other printers use the same kind as you do !

Posted by: @zander

@inq Wow, what one is that?

Mine actually uses the squat ones (V6 style), although, I'm reading these MK8 might have better flow characteristics.  They're commodity, so a simple search at anyplace.  That set of hardened and brass in different size was only $14.  I don't expect to go through my set in my lifetime.

Posted by: @will

Cetus printers require a custom nozzle, so you can't use the cheap ones. My other printers use the same kind as you do !

What is their claim to fame?  Is that titanium for the throat?

@inq I meant what 3D printer are you using?

@inq 

I don't believe that they contain any expensive or hard to machine parts, I expect that it's just a money grabbing technique. That's why I'm abandoning their printers.

I think I just got really lucky with the first one; all of its parts were machined for each other and it ran great. So I bought a couple more soon afterwards and neither of them has lived up to my expectations as based on the first.

So, they're the last from that manufacturer, I DO hold grudges 🙂

Posted by: @zander

@inq I meant what 3D printer are you using?

I'm kind of like @will.  My work-horse is a Prusa i3 Mk3. 

But I wouldn't spring for it again.  They use their printers for the production line to build the printers.  Which is a good sign for longevity.  On this model they switched from ABS to PETG for all the components.  BAD MOVE!  As soon as I put mine in a custom heat box so I could do ABS well, the PETG parts near the head/extruder motor started weakening and finally deformed to the point it couldn't extrude. 

Fortunately, it is open source and the part STL files are available on-line.  I was able to heat gun the deformed PETG parts back long enough to print ABS versions.  Those have worked flawlessly in my heated box.

They're over a $1000 these days.  I bought my adult son an Ender 3 for Christmas @ $200 years ago and it'll easily do as nice a job as mine and everything is metal.  He's hacked it with 32bit motherboard and silent drivers.  It too is a workhorse.  I could put it in a serious heat box.  Several in my Makers Group also have Ender 3's.  They're cheap, sturdy, open-source, easy to work on and easy to upgrade.  There are thousands of STL hacks for them on Thingiverse and electronic kits to upgrade.  

If I get another one, I'll get a Creality Ender 5 Plus... uses CoreXY design, frame perfect for building a heat box around and has 350x350x400 build area.  

VBR,

Inq

Hi @inq,

RE: 3D Printers are the best toy ever... including sliced bread. 

Thanks for the 'hint' ... I may get one sometime ... I am not too fussed about some occasional fiddling with screwdrivers etc., or even replacing a few parts providing it doesn't get too much of an expensive habit ... it is more that I have no experience, no background, and probably even less talent, in 3D design.

I note the Ender 3 range seems to be getting some favourable comments, as a starting point at least.

I know there are lots of downloadable designs on the net, but I am not sure I have the patience to trawl through them.

In the meantime, I have lots of other things to play with ...

Thanks and best wishes, Dave

BTW I much prefer a fresh loaf to sliced bread ... preferably just out of the oven. 😀

I've pulled @robotbuilder post from the VL53L5CX thread.  I see that thread to be about raw data understanding of the sensor where people might want to use the sensor for all kinds of other things.  This thread is more about building a robot and strategies of all aspects, drive, construction, powering and... including vision/mapping.  Here is where this came from: https://forum.dronebotworkshop.com/sensors-modules/time-of-flight-tof-vl53l5cx-8x8-pixel-sensor/paged/14/#post-33953    -Inq

Posted by: @robotbuilder

You wouldn't need to program the robot to specifically go through a door or turn in any particular direction during the map making phase. You start with an empty global map which you can think of as being a grid of points or squares or cells. Each cell in the grid can be empty, full or unknown. When a distance value is received all the cells along the path are filled in with the empty symbol and the cell at the returned distance is filled in with full value. So the robot can be search algorithm can be guided by the current global map's empty cell locations.

In the example below the robot has been wandering about using its lidar to map the cells as filled (black), empty (red) or unknown (white). It will seek out white cells to fill in. Now in the example below it would not simply turn left toward a white area as it is blocked by filled in cells. There is however a clear way through the door. So what might happen is a white cell is chosen and a path planning algorithm is called which plots a path through the empty (red) cells to some unknown valued (white) goal cell. It is the path planning algorithm that will direct it through the door. Also while the robot moves along the computed path the lidar would still be happily filling in any empty cells through which the laser light travels with the "empty" value (red) and any hit cells with "full" value (black).

This is VERY thought provoking.  I have been pigeon holing my thinking under the, "I'm a hammer, where is that damn nail?" syndrome.  I can see the spinning Lidar has an advantage in this scenario since it gets all around without robot intervention.  Since I couldn't get a solid 360° solution for my robot head, I felt keeping the head stationary and taking advantage of its FoV for both obstacle avoidance and mapping at the same time was a good first start strategy.  I might need to consider stopping every so often and doing a 360° pirouette.  I not so sure which would be more fluid and/or faster.  Thinking - would the pirouette introduce more error to the solution at closure - bringing the ends back to meeting, per the SLAM video.  Since my rotational precision has the most error, I'm thinking it would.  But its worth a try both ways and maybe a hybrid solution will present itself in our journey of discovery.

Where I'm having trouble with this strategy though... if you don't use some systematic strategy (I'm just throwing out, "Always turn right" but something else might be better) how do you know that you got everything?  For instance, it seems apparent that the bot in your example started at approximately the blue blob and traveled roughly to this its current spot.  It seems to have a X direction preference.  If it doesn't look at all sides, and confirm a black boundary, it could miss something quite significant like...

An "Always turn right" strategy would help the spinning lidar as well in confirming that all black boundaries have been identified.

Posted by: @robotbuilder

One experiment I would try with your robot is to use the TOF sensor as an obstacle avoidance sensor. Essentially doing the same thing many have done using sonar where the little bot comes across an obstacle, its little sonar servo controlled "eyes" look left and right and then the robot heads off in another direction.

I think that is a perfect next step.  I'm still debating/trying to fix @davee lead-balloon revelation about my wheels.  I'm trying to decide IF I can achieve the mechanical precision OR to push-on and assume non-linear behavior of the wheels and compensate through software... and what that would involve on the micron level.

However, it's a little easier than you suggest... since it has a significant FoV, I don't have to scan the sensor left and right.  I hope to do those calculations real-time so I don't have to pause, scan, and decide, left/right... hope to keep a fluid motion forward.  We'll see.  I've got plenty of horse-power left in the ESP8266 since it doesn't have to deal with motor/encoder logic.  My MPU gauging is saying, I'm using less than 10%.

Posted by: @robotbuilder

As the TOF sensor doesn't scan just horizontally but also up and down does it see the floor?

Technically it doesn't scan... its more of a snapshot, but yes... If the sensor is perfectly level, the lower 32 pixels hit the floor.  These should give plenty of warning of even low obstacles or drop-offs.  Maybe too much.  It would be nice to angle it up somewhat, to get upper pixels hitting the ceiling to finalize the 3D mapping, but that is a down-the-road decision.  

VBR,

Inq

@inq 

An "Always turn right" strategy would help the spinning lidar as well in confirming that all black boundaries have been identified.

Not really turning doesn't change the 360 degrees of values coming in, only moving does. If a red cell has a white neighbour (empty valued cell next to an unknown valued cell) then there is no boundary there thus telling the robot not all boundaries have been identified. The robot has to move to the no boundary found position to shine the laser into the unknown area to see if it leads to the football field 🙂

The main differences I see between the lidar and the TOF sensor in terms of data acquisition is the lidar is high resolution. It is the comparing a high res TOF camera with the low res TOF sensor. The TOF sensor is like a video camera with only 8x8 pixels or the 16x16 pixels per image. With a 16x16 pixel image you might be able to identify a face. The TOF sensor will tell you how close you are to an object and could give some shape data if the obstacle shape can fit into the 8x8 area. A high definition TOF camera on the other hand will give you a detailed representation of the shape.

In other words using the light intensity values vs distance values analogy you are trying to read a page of text one character at a time.  You have to be very close to the object (or edge of the door) to accurately say where it is.

Posted by: @robotbuilder

 

An "Always turn right" strategy would help the spinning lidar as well in confirming that all black boundaries have been identified.

Not really turning doesn't change the 360 degrees of values coming in, only moving does. If a red cell has a white neighbour

I thought we'd talked about the "Always Turning Right" (ATR) before.  I guess not.  This means... that the bot follows the wall on the right.  That any time the bot comes to an opening on the right, a right-hand corner on the right, it must turn to the right.  The point being, it will follow the entire perimeter of the entire building until it returns to its starting point.  In your example, that probably is just a dresser side that the Lidar hasn't seen, would be found had the bot been following this very simple, easy to implement rule.

Posted by: @robotbuilder

The main differences I see between the lidar and the TOF sensor in terms of data acquisition is the lidar is high resolution.

Agreed... you contend its necessary and the only way to tackle this problem.  You are content in only the 2D floor plan since your hammer only hits nails at one height. 

I disagree.  I contend that better than 95% of that high-resolution data needs to be evaluated and tossed and then you have start using lots of mechanics to expand that out into 3D.  I believe I can get close-up detail as necessary, cheaper, faster than you can toss out data and scan 3D.  I can simply slow down the bot's movements and scan the corner at ANY resolution I deem necessary.  It is simply a difference in our two goals.  I can accept, help and encourage yours if you were so inclined to put your goals into project form. 

But it seems, like this is about the third or forth time you've tried to convince me I'm wrong and that your way is the only way.  Can you not accept that I don't consider 2D good enough and that I'm not going to use a spinning Lidar?  I might in the future... but not this project.

Posted by: @robotbuilder

With a 16x16 pixel image you might be able to identify a face. The TOF sensor will tell you how close you are to an object and could give some shape data if the obstacle shape can fit into the 8x8 area. A high definition TOF camera on the other hand will give you a detailed representation of the shape.

And you keep bring up recognizing objects... fist, ball, face, etc.  I've clearly admitted that this scanner is not capable of that and that is not and has never been a goal of mine in this project.  Let me know when you have achieved scanning a face with the spinning Lidar.  I think you could do it if that is another goal of yours.  It is simply not mine at this point.

VBR,

Inq

@inq 

But it seems, like this is about the third or forth time you've tried to convince me I'm wrong and that your way is the only way.  Can you not accept that I don't consider 2D good enough and that I'm not going to use a spinning Lidar?

Not at all, you misconstrue my motives .  I am considering the limitations of the TOF sensor and thus what is possible.  Essentially I see it as trying to map a page of text one character (or part of a character) at a time. My view is based on the utube examples I have seen where the TOF sensor is moved around pointing at various things and displaying a depth colour map on a small screen.

As for the lidar stuff,  I am not going to use a lidar, I see its 2d limits I am more interested in implementing a visual system.  The issue of locking all the collected environmental data together is the same.  It is made easier if you can recognize features that appear in one frame to the next and that includes a low res scan of text one character or part of a character at a time.

Posted by: @robotbuilder

As for the lidar stuff,  I am not going to use a lidar, I see its 2d limits I am more interested in implementing a visual system.  The issue of locking all the collected environmental data together is the same.  It is made easier if you can recognize features that appear in one frame to the next and that includes a low res scan of text one character or part of a character at a time.

I would really like it if you would share this on the forum.  Yes the resolution would be phenomenal but I can't even wrap my mind around the issues of simply recognizing a distinct edge in an image then take its partner stereo image from the second camera and find the equivalent edge and then do the trigonometry on it to simply get a distance that a Lidar or ToF sensor gives you for free.  Is just mind-boggling.  I make lite of how easy mapping ToF distances to a 3D global space is.  Comparatively, you have to:

1. have to recognize "something" in the image.  Be it something large like a wall corner, or small like the 5th eyelash from the left on the right eye.  Nothing simple about this.  In fact, I have no clue.
2. Find the pixel in that image that is a reference point.  Say the corner is 500 pixels tall in one image and 1000 in the other, one's slightly skewed as perspective is everything.  Nothing simple about this problem.
3. Determine the ray going out that pixel in each image.  Not trivial, but not as hard as the first two.
4. Triangulate using Trig and get a distance.  This is falling off the log easy compared to the first 3.
5. Then there is the precision of the assembly of these two eyes is critical.
6. The robustness to take bouncing around on a robot.
7. The compute power to do even one frame a minute would be staggering.  RasPi will never do it.

Maybe you have some concepts or work-a-rounds that I've never heard of... I would really enjoy you doing a thread on this.  Even theoretical based.

VBR,

Inq

@inq 

I would really like it if you would share this on the forum.

Producing depth maps using two images has had mixed results and is very slow compared with a TOF camera. We have not matched the incredible stereo processing done by biological visual systems. Ideally you need a TOF depth camera which gives instant depth data without needing to match patterns in two images and then correlating its data with an light intensity image of the same scene.

When it comes to using video data to control a robot don't think in terms of the human visual system which is indeed more complex then I suspect most people realise because seeing for anyone with normal vision is just a given. The actual machinations are not known and only reveal their existence in visual illusions and those with damage to different parts of the brain.

Using complex mathematics and moving a camera around an object will enable the computer to construct a point cloud but that is not "seeing". 

That is why I asked what you thought you were going to do with the point cloud data?

Posted by: @robotbuilder

That is why I asked what you thought you were going to do with the point cloud data?

Please understand, for me, this is about the journey of building the robot, not the end-product of the robot.  I have no aspiration of a business.  I can't really see me making something that will be of use to even me, much less anyone else.  (Yes, the beer fetcher is not a serious goal - the day I can't get up and get my own, I'll put a fridge next to the chair 😊 )  Like building my own stepper motor driver instead of using FastAccelStepper.h or even Stepper.h.  I want to start from first principles and work-up from there.  That is why I'll never even download ROS.  It is just of no interest for me.  I want to fully understand that ToF sensor so I can say with certainty what I can get out of it. 

That's what I was talking about when discussing the statistics which is an area of math, I never really chose to explore beyond the trivial things like mean, average, and deviation.  I think it would be impossible to USE a point cloud for hit testing on even a serious PC level computer.  But I'm certain that there is a way (TBD) to use statistics to convert thousands or millions of 3D points into a single mathematical panel.  I have not really started thinking about the actual nuts and bolts, but I believe something like an STL file (bunch of triangles) representing the building could be achieved.  At which point even a low-power consumer, lower-end RaspPi (say a Zero-W) could work through a way to determine its location by what it sees around itself when turned-on and then calculate a travel plan to the commanded retrieval point... the fridge 😉 .

When you first mentioned SLAM, my initial thought was it was just another monolithic software suite (like ROS).  At some point, I realized it was a defined conceptual model that was basically what I had already worked out as my road map.  Even though I had not/have not worked out all aspects, it's nice to know that I was on the right track.  Now that I've started looking into it, I find it surprisingly at a fledgling level.  OR more likely, the ones that are really knowledgeable like Boston Dynamics, Tesla, Google, et al.  are holding it close to the chest for proprietary, and profit reasons.   Although in this video and others I've seen, it really seems more like it is a bunch of kids with LOTS of shiny toys.  

It almost seemed they were merely excited by getting a point-cloud.  There was no real discussion what to do with it once they had it.  Do you have any bookmarks for SLAM that might get a little further... like using the map data gathered?  My lousy Internet bandwidth keeps me from really surfing YouTube's but it sounds like you are well versed in the topic and might have some good recommendations.  Again, I'm not so interested in an actual (use this library) type video.  I'm more interested in the conceptual, theoretical approaches.  

VBR,

Inq