Hello everyone, I am a newbie in the robot sector. I have to make a mobile robot(differential drive robot) that can climb the hull ship in manual mode(automated not autonomous). The problem is I don't know how to make the robot drive straight. The robot in the ground can drive straight if you have v left and v right at the same speed but always has errors. So how about on the hull ship? I want the robot to run straight 15 cm and stop then continuously run 15cm and stop. It is a loop. Should I use odometry(encoder) and IMU to determine a position? (It still has errors?) or just use PID to control the speed of v left and v straight in the manual mode?. Please help me. Thanks, everyone.
How to make a robot drive straight?
-
Darknight2 -
April 9, 2024 at 5:30 AM -
Thread is Unresolved
-
MOM
April 9, 2024 at 10:46 AM Approved the thread. -
This is probably not the best forum to ask this question in, but I will make an attempt.
This probably requires a multi-layered solution. Odometry on the drive wheels will be useful, but cannot detect slippage between wheel and hull. So some sort of additional sensing is required, independent of the wheel motion.
A flow camera, or a sensor similar to that of an optical computer mouse, would be a good addition, located to see the surface of the hull orthogonal to the robot's motion path. This is not free from error, but combined with the wheel odometry should reduce errors.
However, a flow camera may not detect rotation of the robot -- for example, if one wheel slips but the other does not. An IMU or multi-axis gyro, as used in most modern smartphones, would detect this. IMUs are very useful, but can only detect acceleration, which means that using IMU along for location relies on double integration of the detected accelerations over time. This leads to an accumulation of errors. So most IMUs in real-world use rely on being "reset" periodically using some sort of external navigational reference to reliably update the robot's real position.
The best positional data would be to use GPS, or a "local" equivalent -- DGPS, Indoor GPS, or some other beacon-based system. DSLAM might be an alternative.
Most modern mobile robots use a hierarchical combination of all these navigation methods, in a sort of "sensor fusion". The details of which sensor's data is treated as most or least reliable is situational, and usually must be tuned for each robot application.
-
what is the scale/size of the boat? what is environment?
probably do not need to stop at 15cm mark if this is a container ship crossing the ocean.
where boat is where exactly? indoor/outdoor? swimming pool or open water? stagnant or flowing?
15cm relative to what? i am guessing this is some sort of model being tested in a pool, possibly indoors. in this case indoor positioning system (local GPS or cameras) could be used.
-
Display More
This is probably not the best forum to ask this question in, but I will make an attempt.
This probably requires a multi-layered solution. Odometry on the drive wheels will be useful, but cannot detect slippage between wheel and hull. So some sort of additional sensing is required, independent of the wheel motion.
A flow camera, or a sensor similar to that of an optical computer mouse, would be a good addition, located to see the surface of the hull orthogonal to the robot's motion path. This is not free from error, but combined with the wheel odometry should reduce errors.
However, a flow camera may not detect rotation of the robot -- for example, if one wheel slips but the other does not. An IMU or multi-axis gyro, as used in most modern smartphones, would detect this. IMUs are very useful, but can only detect acceleration, which means that using IMU along for location relies on double integration of the detected accelerations over time. This leads to an accumulation of errors. So most IMUs in real-world use rely on being "reset" periodically using some sort of external navigational reference to reliably update the robot's real position.
The best positional data would be to use GPS, or a "local" equivalent -- DGPS, Indoor GPS, or some other beacon-based system. DSLAM might be an alternative.
Most modern mobile robots use a hierarchical combination of all these navigation methods, in a sort of "sensor fusion". The details of which sensor's data is treated as most or least reliable is situational, and usually must be tuned for each robot application.
thank you very much.I will think about that. And if I have the same question about robot like that what forum I should post ? thanks
-
what is the scale/size of the boat? what is environment?
probably do not need to stop at 15cm mark if this is a container ship crossing the ocean.
where boat is where exactly? indoor/outdoor? swimming pool or open water? stagnant or flowing?
15cm relative to what? i am guessing this is some sort of model being tested in a pool, possibly indoors. in this case indoor positioning system (local GPS or cameras) could be used.
thank you very much
-
And if I have the same question about robot like that what forum I should post ? thanks
I'm not sure. It's just that this forum is mostly about industrial robots -- most of us are integrators of robots we've purchased from major manufacturers like ABB, KUKA, Fanuc, etc, rather than create new robots from scratch. Your question is more related to mobile robotics/AMRs. This is a much more nebulous field, especially in the open-source area.
GitHub - mjyc/awesome-robotics-projects: A list of open-source, affordable, less-known, or visionary robotics projects.A list of open-source, affordable, less-known, or visionary robotics projects. - mjyc/awesome-robotics-projectsgithub.com -
I'm not sure. It's just that this forum is mostly about industrial robots -- most of us are integrators of robots we've purchased from major manufacturers like ABB, KUKA, Fanuc, etc, rather than create new robots from scratch. Your question is more related to mobile robotics/AMRs. This is a much more nebulous field, especially in the open-source area.
I'm not sure. It's just that this forum is mostly about industrial robots -- most of us are integrators of robots we've purchased from major manufacturers like ABB, KUKA, Fanuc, etc, rather than create new robots from scratch. Your question is more related to mobile robotics/AMRs. This is a much more nebulous field, especially in the open-source area.
Again, thank you very much
Advertising from our partners
