The main question of the project: how to be sure that all the surface I want will be visited by the robot?
When I start the project I didn't know how to solve this so, looking for something that could integrate the motor driver, a laser scanner for mapping purpose and a navigation tool, I found ROS.
Bingo! I said, everithing is done! Not yet really, some time is needed to setup my robot with ROS but following the tutorials and asking on the dedicated answers site the robot is right now at a good point.
Now is the moment to look on how my robot will move inside the field. One way to do this job is give to the robot random goals, that could be given from an input by the kinect or bumper sensor or sending it from a software. This is how the monstly robotmower work, but in my opinion this could not work for large area like mine, or it will take to much time to statistically complete it. What I prefer is somenthing that could create a path that cover all the area I want to mow, possibly visit at least one time each tile of the field.
ROS have enough code to be able to add a little piece that could do this.
In this way my idea on how to improve this on ROS is create a package the could:
- read the map;
- divide it in tiles larger like the robot tool;
- create a list of this tiles, sorted by the travelling salesman problem (TSP);
- send this list of goals to the ROS navigation stack;
This is the idea, and will be improved with other task, but for the moment I'm yet on the first step.
venerdì 9 agosto 2013
How to add cheap encoder to a garage door motor
One of the more important things on a robot like the one I'm trying to build, is that it needs to know where it is. To improve this task on the robot what I need is something that count (forward and backward) the distance the robot has traveled.
There are a lot of way to get this information, but one of the more simple, is to use an encoder.
On the motors I mounted on my robot (a garage door 24V 18A peak, gear worm reduced), there was an encoder, but was mono directional, in the meaning that it counts only in one way and you cannot know if it is going forward or backward, unless you merge it with the input signal of the motor to know in which way the encoder is going to. Do this job could be quite hard, and unnecessary.
In this way I decide to add to my motors 2 incremental encoder that provide the correct ticks count.
There are a lot of kind of encoders, with the formula more ticks you want per round more you will pay.
After a lot of surfing on the internet , I found a middle way on ebay, that consist in a
OAK GRIGSBY 9 series
that provide me 400 ticks per round with a max of 3000 rpm for less then 10$ each.
The problem now is how to add the encoder to the motor. The first solution I found is remove the gear from the encoder and fix it axially in one of the two motor shaft. The encoder could run up to 3000 rpm and none of the both shaft could go over that threshold.
Thinking on this solution, at least 2 problem remain:
-work on the fast shaft could be quite hard, the material could be heat treatment, and cause the "high" velocity we need to hit the centre of the axle, and in a post tooling could be very stressful and will compromise the correct working of the motor.
-the slow axle is directly fixed on the gear, that provide a little nipple that is used like a axial bearing so make an hole in that point will remove it, and make the motor useless.
Looking better on the slow shaft I see that the "nipple" give enough space to fit in a gear and preserve the part that touch the case.
Mounted the gear on the motor shaft I drilled the little one and fix it on the encoder, after this I cut 3 holes on the metal frame a little larger to fit the encoder.
The gears provide 2 good things that are a little slack between the gear to avoid tooling imprecision, and a ticks multiplier.
This is how the work finally appear.
I'm trying it now and it work perfectly, but I don't know how long could survive.
Thanks to anyone who want to share is opinion or ask something about it.
There are a lot of way to get this information, but one of the more simple, is to use an encoder.
On the motors I mounted on my robot (a garage door 24V 18A peak, gear worm reduced), there was an encoder, but was mono directional, in the meaning that it counts only in one way and you cannot know if it is going forward or backward, unless you merge it with the input signal of the motor to know in which way the encoder is going to. Do this job could be quite hard, and unnecessary.
In this way I decide to add to my motors 2 incremental encoder that provide the correct ticks count.
There are a lot of kind of encoders, with the formula more ticks you want per round more you will pay.
After a lot of surfing on the internet , I found a middle way on ebay, that consist in a
OAK GRIGSBY 9 series
that provide me 400 ticks per round with a max of 3000 rpm for less then 10$ each.
The problem now is how to add the encoder to the motor. The first solution I found is remove the gear from the encoder and fix it axially in one of the two motor shaft. The encoder could run up to 3000 rpm and none of the both shaft could go over that threshold.
Thinking on this solution, at least 2 problem remain:
-work on the fast shaft could be quite hard, the material could be heat treatment, and cause the "high" velocity we need to hit the centre of the axle, and in a post tooling could be very stressful and will compromise the correct working of the motor.
-the slow axle is directly fixed on the gear, that provide a little nipple that is used like a axial bearing so make an hole in that point will remove it, and make the motor useless.
Looking better on the slow shaft I see that the "nipple" give enough space to fit in a gear and preserve the part that touch the case.
|
|
| 
|
Mounted the gear on the motor shaft I drilled the little one and fix it on the encoder, after this I cut 3 holes on the metal frame a little larger to fit the encoder.
The gears provide 2 good things that are a little slack between the gear to avoid tooling imprecision, and a ticks multiplier.
This is how the work finally appear.
I'm trying it now and it work perfectly, but I don't know how long could survive.
Thanks to anyone who want to share is opinion or ask something about it.
Iscriviti a:
Post (Atom)