This is a test with the Intel RealSense T265 tracking camera for localization with the EZ-Robot AdventureBot. I use 3 ultrasonic sensors as well to demonstrate the navigation messaging system, but that's not the full point of the video. Ultrasonic sensors are terrible for mapping
A 360 degree lidar will do a much better job. I'll get to that in the future... but for now, we're playing with localization and way points.
So, the fact that this robot can get back to exactly where it started and the realsense maps that position... wow, i have to say wow! My USB 3.0 active extension cable is only 16 feet long, so that's as far as i can go without putting the realsense in the robot. For the time being, this is how we test. It's also a good test because the wheels slip like crazy, so it demonstrates why wheel encoders are bad news bears.
Preparation for Part #4 Removing false positives and filtering the data from the Lidar, then adding a SLAM algorithm to allow detected objects to only be static for a certain period of time. This allows things in the way to move, like humans, and not be part of the map. I wanted to make a robot that can navigate around my bedroom to each night stand, closet and doorway. So I used a combination of the 360 Lidar and 3 ultrasonic distance sensors to scan my bedroom. I threw a bunch of clothes on the floor to simulate obstacles, which you can see around the closet.
Closer inspection, you can see the way-points and the navigation paths i took to create them. I'm implementing a path finding algorithm right now for the next update - which splits the map into quadrants based on your defined robot size. It then finds a path by using your robot's width.
Here's with filtering to remove false positives. This gives the path finding system less false positives to worry about
Part #3 We give way-points names
Part #2 In this video, i demonstrate multiple way-points and controlling them through control commands
Part #1 Just testing this Intel RealSense T265 out and seeing how it works with the ARC NMS (Navigation messaging system)
Other robots from Synthiam community
Smarty's Combot - The Ez-Robot Computer System
Jim's Armadeus Mk. 12
You are of course right about the compass accuracy and all that and the need for some filter. I'd also agree the T265 has to be the very dominant partner in the calc. I think the issue I am having is that the axes on the T265 (specifically the direction of the yaw axis at 0, its "north") is arbitrary...its whatever the bot was pointed to when it last reset its map (which is when the device powers up by default). I keep feeling like I need to correlate the two. So far, I have been taking a bunch of compass readings on startup (with the face front and level), averaging them, so I can use this to translate from T265 to world. Perhaps there is a better way.
It may just be a human problem of me not wanted to abandon compass headings and use the arbitrary T265 yaw axis. I am used to thinking and calculating so many things using compass headings. I am used to being able to tell my bots to look, rotate, or drive on a particular heading. If a bot looks to one side and sees something in a cam, I am also used to thinking in terms of calculating the bearings and distances to those things and remembering that, and creating a situational awareness of things around a bot in memory. Maybe I need to abandon caring about headings and just use T265 0 yaw, but it is hard to, I want to know which way the bot is going in something I can relate to! I also have the desire to build and store a map that uses a non-arbitrary coordinate system with a "north".
If you imagine your ideal bot, what do you think you would do?
Digital compasses do not work very well in doors as they use a combination of a magnetometer, accelerometer and gyroscope to calculate direction and this is heavily influenced by external factors. The indoor atlas guys who invented indoor location tracking using a compass use this flaw to their advantage. The magnetic fields generated by electrical wiring, metal frames, drink machines, DJ's pinball machines etc will interfere with the compass on the robot. Indoor atlas use this discrepancy to approximate the position of a phone or robot using other positioning technology with the unique magnetic fingerprint created of where you are in the building at the time in order to increase the accuracy of their location tracking. https://www.indooratlas.com/positioning-technology/
You’re both right. However, the discussion about the compass is void unless the application specifically requires one for some reason. Because the intel t265 does a much better job at keeping heading degrees.
Having the compass might be a human problem, like you said. But even us humans have a very vague idea of north, and it doesn’t play a vital role in our lives.
If the goal of the robotics navigation is to visit different way points using the t265, there’s no need for a compass.
actually, other than basic obstacle avoidance, there’s not much else needed. The t265 takes care of pretty much everything. It’s quite wonderful!
I am so tempted to buy one now instead of waiting boxing day for that t265!
I should be getting some sort of commission on those purchases
Excellent part 2 demonstration
I need to try the Navigation Messaging System (NMS) that is built into ARC soon , need to purchase a T265.
I have been using the ultrasonic sensor and the Arduino with ARC serial monitor, measuring the speed of sound and using the ultrasonic sensor for echolocation
thanks again,
waiting for part 3
EzAng
Part #3 is posted in the top of this
Oh yes part 3 fantastic waiting for 4!