0
$\begingroup$

Good day to all.

First of all, I'd like to clarify that the intention of this question is not to solve the localization problem that is so popular in robotics. However, the purpose is to gather feedbacks on how we can actually measure the speed of the robot with external setup. The purpose is to be able to compare the speed of the robot detected by the encoder and the actual speed, detected by the external setup.

I am trying to measure the distance traveled and the speed of the robot, but the problem is it occasionally experiences slippage. Therefore encoder is not accurate for this kind of application.

I could mark the distance and measure the time for the robot to reach the specified point, but then I would have to work with a stopwatch and then transfer all these data to Excel to be analyzed.

Are there other ways to do it? It would be great if the external setup will allow data to be automatically sent directly to a software like Matlab. My concern is more on the hardware side. Any external setup or sensors or devices that can help to achieve this?

Thanks.

Improve this question
$\endgroup$
8
  • $\begingroup$ What you are talking about is one of the most common problems in robotics: localization, and specifically the shortcomings of interoceptive sensors performing dead reckoning vs. exteroceptive sensors where the environment provides information regarding the vehicle position in a global frame. This question might end up being closed because you should really be doing research elsewhere before asking here. $\endgroup$
    – Brian Lynch
    Commented Dec 2, 2015 at 4:36
  • $\begingroup$ Thanks for the feedback Brian. I know it's a hot topic in robotics. So could you please guide me so that I can edit the question before it is closed. I have a robot and I need to measure its actual performance, i.e speed. I know my robot experiences slippage, therefore I just need to document this discrepancy between what the encoder reads and its actual value in my report. Then I can discuss its performance. I'm not actually looking to solve the localization problem. It is how I can explain the performance of my robot in a report. If you were in my shoe, how would you do it in your report? $\endgroup$
    – goddar
    Commented Dec 2, 2015 at 4:52
  • $\begingroup$ I might write it out as an answer but essentially you want to talk about "dead reckoning" and where it fails -- start with Wikipedia (here). $\endgroup$
    – Brian Lynch
    Commented Dec 2, 2015 at 4:54
  • $\begingroup$ Also this could be helpful... or just start with this. $\endgroup$
    – Brian Lynch
    Commented Dec 2, 2015 at 4:57
  • $\begingroup$ My project is mainly about the tire design and I've read several journal papers and somehow, when they present the results, they manage to have 2 plots in a graph, which are the actual speed and speed obtained by encoders. Actually how did they do it? I can only imagine that they have another setup where an ultrasonic sensor is used to detect the distance and then the program can calculate the actual speed of the robot. Are there other ways? One of the papers suggested this: ndigital.com/msci/products/optotrak-certus. But I can't afford this. $\endgroup$
    – goddar
    Commented Dec 2, 2015 at 5:06

1 Answer 1

Reset to default
2
$\begingroup$

There are a couple good options depending on the scale of your project for capturing a ground truth.

For large scale outside (cars or agricultural vehicles) RTK GPS can be had for a very reasonable price.

For small scale you can probably make a poor-mans motion capture with OpenCV, ping-pong balls, and a few global shutter cameras (preferred if you can afford it) or even webcams.

If you have both no time and no money, make a grid on the floor with a builders chalk line, attach a marker (ping-pong ball on a stick) near to the floor (avoid abbe error), and take a video from above. Your pose estimates will be more precise than the stopwatch estimates you were thinking of.

Make sure to estimate and include the measurement error of your ground truth in the report.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Actually, even easier would be to just put two markers on the vehicle at a known separation distance, then set up a laptop with a webcam and process that data directly in MATLAB. Make the markers a unique colour and you can easily find them automatically by considering the hue value. Since they are a known distance apart you can infer the true distance traveled without having to do a lot of math regarding the camera scene reconstruction. Note I am not making a new answer for this since @hauptmech is saying exactly this (but in a more professional lab setup). $\endgroup$
    – Brian Lynch
    Commented Dec 2, 2015 at 6:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.