Show Posts
Pages: 1 2 [3] 4 5 ... 374
31  Topics / Robotics / Re: Using invisible dog fence as boundary for lawn mower robot on: June 07, 2014, 12:50:42 pm
Have you tried using the receiver portion of a cheap "wire-tracer" tool - example:

http://www.harborfreight.com/cable-tracker-94181.html

Such a device might be able to pick up the signal that your virtual fence transmitter is outputting, and you could then use the presence of that signal (and/or the strength) to determine where your robot is in relation to the boundary wire.

Might be worth purchasing and trying it out - worst case is that you are left with a wireless signal tracing tool (which are pretty useful on their own for tracking problems with wiring you can't see easily).
32  Using Arduino / Motors, Mechanics, and Power / Re: L298N driver problem on: June 07, 2014, 12:44:44 pm
I already tested the driver without arduino and voltages on both branches are approximately equal.
If proximity sensors are disconnected (or even connected, but do not write anything about them in code) on each branch have the same voltage (measured with measuring device). If I connect them (or write something in code related to them) appears the difference in voltage between branches

I wrote up a longer reply about the batteries, voltages, hookup, etc - but I think I see your problem now (maybe):

STOP USING PIN 1 as an output!

If you plan on using pins 0 and/or 1 on the Arduino, these serve the serial I/O for the USB serial interface. You can use them, as long as you don't plan on using the USB. Otherwise, you can't use them.

I think what is happening to you is that in your code, you have pin 1 (transmit) set as an output for the motor driver (for one of the motors). Everything else is hooked up to higher number pins, so they are ok. But that particular pin is being used to set (partially) the direction of the motor control for one of the motors (or something like that).

Now - at the same time, you have the sensors hooked up and sensing. In your code, when they do that, you also do some serial printing, which outputs (aka - transmits) from the Arduino to the PC - and guess which pin that toggles?

Yep - Pin 1 is then toggled - which is likely causing that motor to run strangely as the sensors work. I would bet that if you removed the serial printing from that code (or better - move the function of pin 1 to another higher pin) - everything would start to work better.

That's just my best guess, though. Good luck - hope it works!

smiley-grin
33  Using Arduino / Project Guidance / Re: Is there an easy way to create a better waveform then always on or always off? on: June 07, 2014, 12:18:06 pm
Crude PWM+filter won't make that waveform tho.

What about an R2R ladder DAC? Just throwing it out there; I'm not knowledgeable enough in this are to really know...

smiley-grin
34  General Category / General Discussion / Re: Arduino's box textures on: June 01, 2014, 05:33:35 pm
I don't know if it would be legal to use it - but it seems simple enough that you could just create your own. Seriously, I could probably spin out this pattern (well, something similar) given a few hours in inkscape...and I am anything -but- a graphics artist. Give it a try; you might be surprised by what you create...
35  Using Arduino / Motors, Mechanics, and Power / Re: How to control high power motor schield which has a servo plug but no receiver? on: May 26, 2014, 05:01:48 pm
Before I buy it, how would I determine how to control that thing without having a receiver / remote control ? What are possible options? Where do I look for such documentation if it isn't on the manufacturer site?

All the documentation for the controller is what you linked to.

The short answer to your question on how to control it, is to use the Servo library on the Arduino:

http://arduino.cc/en/reference/servo

Now, within the documentation that you linked (and I only skimmed it lightly), there should be enough information in there telling you how to program and use it from a receiver point of view (that is, if you were using it for standard R/C control). That should be enough to go on in order to use the Servo library (if you have experience controlling regular servos using the library and Arduino).

If not, though, it might be helpful for you to buy a receiver and transmitter to play around with the controller, and gain a "feel" and understanding how it works in the normal "manual" operational mode with an R/C system. Then, you can translate that into what is needed by the Servo library.

The greatest issue on these controllers - besides programming them (which appears to be possible without needing anything very special) - is "arming" them to take the commands from the controller. There should be instructions within that document you linked (again, I only skimmed it) on how to do this, but it is important and necessary for it to work properly (indeed, for it to work at all). Basically, "arming" the controller initiates it so that it can take commands from the controlling system (whether receiver, or an Arduino with the Servo library); there is generally a particular sequence of commands that have to be sent after it is turned on in order to "arm" it - after which, it will beep or do something else (again, read the manual you linked) to show you that it is armed and ready to receive regular commands.

With the a regular R/C transmitter, you typically do this by moving the controls on the transmitter in a certain fashion, after which a beep is heard and/or an LED is lit - then you can continue the use of the controls as normal. For using an Arduino and the Servo library, you must send a similar sequence of commands; ie - Servo.write() and/or Servo.writeMicroseconds() - again, after which it indicates that it is "armed", you can send normal command sequences to control it properly.

This arming sequence is a safety feature, and most controllers have it - but it must be initiated properly after power-up, or the controller will not function. Again, having an actual transmitter/receiver handy to play with this can be super-helpful in troubleshooting and development of the Arduino Servo library code implementation.

Finally - one thing you can also do (which may or may not be useful in your project) by having an actual transmitter and receiver - you can interface the receiver to the Arduino! By using PulseIn:

http://arduino.cc/en/Reference/pulseIn

...after connecting the receiver's servo output to the Arduino - and reading the pin - you can determine what your transmitter is sending. From there, you can simply "pass it thru" to the servo via the Servo library (just as if it were connected directly), or you can do more interesting things...

For instance - you could record your commands to memory (EEPROM or SDCard, likely) - then play them back! Or - maybe you have an R/C car - add a front mounted ultra-sonic sensor to the car, pass the accelerator and/or steering thru the Arduino - and if the ultra-sonic sensor "sees" an potential collision with something, it could stop the car automatically, or steer it away from it (or both).

These are just a couple of potentially interesting options in playing with R/C receivers, transmitters, controllers, and mixing the Arduino in with them all...

Hope this helps. Good luck! smiley-grin
36  Topics / Robotics / Re: uArmⅠ:An open source robot arm on: May 19, 2014, 08:33:24 pm
Per the below the arm project seems ton be moving along. Still no arm parts scale drawings, but the bottom arm assembly guide provided good detail of the arm.

It's strange; this assembly guide looks better than the first iteration they supplied me - which I then added some better descriptions and such and sent back - but it still seems strange in one area (and very similar to the original one I was supplied):

They first describe how to build the base (steps 1-5), then jump to building the controller and vacuum holder (steps 6-21), then jump to building the shoulder (steps 22 and 23), then the arm (step 24-36); at step 37 - they start to attach the controller/pump to the shoulder/arm portion, then at steps 38-39 attach the arm to the base, then finish up the suction piece.

Now, this is better than the instructions I got - but it still seems slightly "wrong" (but not having an arm to play with, I can't really tell). What I don't understand, is why it doesn't go base (1-5), shoulder/arm (22-36), then controller/vacuum holder (6-21), then attachment (37-39). It would seem to me that this would be a more logical progression...?

Unless some part gets in the way of the other - not sure. Again, I don't have the parts or such for one of these arms, so maybe it does. Also again, this assembly manual is better than the version I had, where the diagrams weren't as clear, nor the descriptions, and the assembly sequence was more seemingly haphazard.

Overall, I'd say they did a fairly good job of updating it.

smiley
37  Community / Bar Sport / Re: Your latest purchase on: May 18, 2014, 12:15:25 am
My most recent purchase (literally just hours ago) was a bunch of components for a new PC workstation (case, psu, mobo, cpu, ram, hdd, ssd - I already have the video card); my current machine is showing its age (a core2duo w/ 4 gig; running Ubuntu 10.04 LTS) - it was an upgrade in 2009, so I think I got my money out of it. The new machine should be much nicer (and I am moving to crunchbang - lean and mean).

Prior to that was my last "real" purchase:

A guy posted on the r/robotics forum (reddit) that he got a deal on a bunch of old robot arms; among them was an old Rhino Robotics XR arm that needs some TLC:

http://www.embeddedrelated.com/showarticle/591.php  (pictures of the arm near the bottom of the post)

I got the arm and controller on Friday; waiting to receive the teach pendent (he forgot to send it along, should be here by Wednesday).

It's missing the lower base timing cog wheel and belt; I've got an email in to Rhino to see if they can give me anything to go on in order to replace it. If not, I'll have to fabricate something I guess.

The arm is quite heavy and robust (so is the controller/power-supply). It needs some cleaning and such as well, but overall is in great shape. One of the quadrature encoder brackets was bent during shipping (easy enough to repair). The controller may or may not work properly - the guy who sold it to me said that the pendent didn't seem to power up when he connected it, but that the controller seemed to be controlling the motors in some fashion when he applied power.

Some of what he said didn't make sense, though, as the motors are brushed DC gear motors (Pittman - very high quality there) with quad encoders - and he said he couldn't turn them when the power was on (not sure how they could "hold station" with only quad-encoders).

Anyhow, worst case is that I'll have to build my own controller in some fashion (I might do that anyhow, but I want to try to get the original controller running first). My plan is restoration of the robot as part of my "vintage computer and robotics" collection.

If anyone has any good information on the robot (looking for actual manuals if possible), I'm all eyes. I've found the common internet stuff - not much out there, unfortunately...
38  Topics / Robotics / Re: uArmⅠ:An open source robot arm on: May 11, 2014, 10:02:21 pm
I wanted to let everybody know that one of my friends, who participated in the Kickstarter at a level to get a uArm kit - told me that he was contacted a couple of weeks ago by the developers of the uArm to get his information for shipping. This seems like good news; hopefully it means things are progressing with development, and that their lack of responses to inquiries (and here on this forum) means that they are just kicking butt to get orders fulfilled.
39  Using Arduino / Motors, Mechanics, and Power / Re: Control 48v Go Kart motor on: May 11, 2014, 08:18:29 pm
You might also look into brushed-DC motor controllers from Vantec and Roboteq:

https://www.vantec.com/

http://www.roboteq.com/

NOTE: It won't be cheap.
40  Using Arduino / Programming Questions / Re: Robot with behaviours/strategies. on: May 11, 2014, 08:14:53 pm
I am at the early planning stage of designing a robot which I want to be able to exhibit different "behaviours".

You might be interested in a series of books written between 1976 and 1987 by David L. Heiserman:

  • Build Your Own Working Robot - #841 (ISBN 0-8306-6841-1), HB, © 1976
  • How to Build Your Own Self-Programming Robot - #1241, (ISBN 0-8306-9760-8), HB, © 1979
  • Robot Intelligence...with experiments - #1191, (ISBN 0-8306-9685-7), HB, © 1981
  • How to Design & Build Your Own Custom Robot - #1341, (ISBN 0-8306-9629-6), HB, © 1981
  • Projects in Machine Intelligence For Your Home Computer - #1391, (ISBN 0-8306-0057-4), HB, © 1982
  • Build Your Own Working Robot - The Second Generation - #2781, (ISBN 0-8306-1181-9), HB, © 1987

All were published by the now-defunct publisher "TAB Books" - but can still be found on the used market. While the systems they depict are closer to a form of artificial intelligence rather than pre-programmed behaviors, supposedly the behaviors of the machines (and simulations) that were depicted were supposedly rather organic and somewhat purpose-driven; that is, the systems seems to exhibit true intelligence, and not pre-programmed behavior.

It should also be noted that these books describe systems involving machine and assembly language, along with BASIC programming; in other words, if you decide to investigate them, realize that you are looking at some old stuff, and take away the ideas, rather than then implementations (unless you like a challenge of converting BASIC and Assembler code to C/C++).

One of Heiserman's creations (that of "Rodney", described in the second book) actually became a commercial product - the RB5X:

http://www.rbrobotics.com/Products/RB5X.htm

Sadly, it too is no longer manufactured - but it wouldn't be difficult to recreate it...






41  Topics / Robotics / Re: The speed of two continuous servos is not syncing on: May 10, 2014, 07:14:20 pm
...one servo goes slightly faster than the other. This is not good, because I am trying to make a 2WD robot and I need it to drive in a straight line...

As it has already been noted, even if you did modify the settings for the servos via the hardware or the software, it is unlikely to remain synced over the entire speed range, or on varying terrain (especially carpeting for an indoor floor roverbot).

In order to correct for this, you need to be able to monitor how fast the wheels are turning. Typically, this is done via an optical encoder of some sort - for instance:

http://www.societyofrobots.com/sensors_encoder.shtml

As the wheels (and encoder) are turned by the servos, you monitor the transition periods of the sensors; if one sensor (wheel) is taking longer than the other (that is, if the transition periods differ), then you need to either speed up the slow wheel, or slow down the fast wheel - until they match again.

Even then, you will still have "noise" on the output - things won't be 100% perfect (this is the real world, unfortunately). You might be able to augment things with a compass sensor.

Or - you could take a different approach. Unless you have an absolute requirement for "perfect" precision and accuracy, you might instead just "go with the flow", let your robot meander a bit, but recognize that noise in your path planning, mapping, and localization algorithms.

Once of the core fundamentals that I learned about when I took the Udacity CS373 course, was that in the real world, all sensors and all systems in robotics have "noise"; you can't completely filter it out, so instead your algorithms need to take it into account - which is why there is so much emphasis on statistics, probabilities, etc - in SLAM (simultaneous localization and mapping) algorithms.
42  Topics / Robotics / Re: Introducing the 360 Degree Laser Scanner Development Kit (RPLIDAR) on: May 09, 2014, 09:04:54 pm
While the price for that sensor is certainly lower than many other similar options, it still is way over the top of where it needs to be: As a hobbyist, for $400.00 USD, I could easily purchase a Neato Robotics vacuum, tear it down, gain the sensor (which this sensor seems to be an almost direct copy of), plus a host of other useful parts. It seems like the more sensible option.
43  Community / Bar Sport / Re: WM Robots is threatening a Lawsuit! on: May 09, 2014, 08:59:52 pm
They sent me a legal document accusing me of publicly posting their company secrets and proprietary technology, which is untrue.  We were designing a small Flying Toy Robot made out of plastic.  It is

Untrue or not, this may not be the best way to air your grievances - especially if they do have a legitimate case; it could come back to haunt you...

scheduled to be in Production and in stores by June, next month.  Millions of dollars have been spent on this design so far.  PM me if you're curious about the exact figure.  You'll get a big laugh out of it!  Unfortunately they have failed to achieve stable flight.  The project is a complete failure, I heard from my source last month.  Even if/when they achieve basic flight, the more advanced features will not be complete until December.  By then many other Flying Toys will be released that are far more advanced, and functional, for

Again, you may want to re-think your plan of action, unless your lawyer has cleared you to do so (you have spoke with a lawyer about this, right?)...

1/3 the price.  Including my own Quadcopter design in July.  Total design cost?  About 200 hours of my time.

I will be using a Patent Attorney to protect my ideas.  My cost?  Free since we're married!

Note that a patent attorney may or may not be fully qualified in regards to all issues surrounding corporate IP issues, etc; also note that there is a conflict of interest as well here. You would do well to speak with an outside attorney regarding this issue.

They are planning to use Open Source code, due to their failure to debug 20,000 lines+, and make it fly.  It would take 5 employees at least 9 months to write something this size.  And another few months to debug it, in theory.  Not that I'm keeping track or giving away any proprietary information here.  Because they are using Open Source code, specifically GPLv3, doesn't this mean they have to release and make public all their proprietary code in this project when it is sold?

Are you sure they aren't using LGPL'd code? Big difference, of course. If they are using GPL'd code in the final product, then yes, they would have to release that code, and any code that was linked to it (that is, any code that relies upon it for compilation or similar needs). I am not well versed in this whole area, though; again, consulting with an independent attorney would be best on this matter.

My guess is their retail price will be about $1500, based on their development costs, not that I've heard anything about retail price while I was an employee. 

When was this? When did you last work for WM Robots? Did you have to sign any confidentiality agreements, NDA's or non-competes? I know I have worked for plenty of companies (as a software developer) that have made me sign similar documents regarding any and all work I do for them (sometimes even including "off-the-clock" work) as being their intellectual property; how enforceable that is could only be decided in the court system, of course - but that process could easily bankrupt an individual if the company bringing the lawsuit has moderately deep pockets...

It's simple math.  Total development cost / number of units in production.  I assume they want to make a profit?  Anyone can add up the costs for parts and materials.

WM Robots seems to be a military (or para-military) robotics supplier - and not in the "retail market". Also, isn't there more to pricing than a simple "development cost / units" calc? I'm pretty certain there is - or should be...

http://www.wmrobots.com/WMROBOTSSITE2/products/knight-robot/

They haven't had any new products, defense contracts, or sales since 2010, 4 years ago.  Without any insider knowledge at all, I'm guessing they will soon be Bankrupt.  Their overhead is tremendous, you can see from looking at their facilities.

http://www.bizjournals.com/philadelphia/blog/peter-key/2010/12/history-behind-wm-robots-which-won.html

Again - from that link - they don't seem to be in the retail sector; that doesn't mean they won't be bankrupt - who knows...

This forum will give WM Robots a chance to publicly state why they are harassing me.  Their false accusations are ridiculous.  Their failure to respond here would only prove their bad behavior.

Not necessarily - their failure to respond could simply mean they are using legitimate channels (ie - the court system), as well as the fact that they might not even read these or other forums you have posted this issue on.

I will post some short code snippits to show how idiotic the kiddie programmers at WM Robots are.  Just an example of the bugs I found in the 20,000 lines of "production" code.  Any respectable software developer would be embarrassed to have written this garbage!  It's high school level programming.  They are slowly learning to write software, having just graduated from school.  It makes me wonder what they're teaching in Universities these days.  Let me clear it with my lawyer first, before I continue to post.  I will also post this on all the hobbyist Quadcopter forums.  Along with the legal documents they have sent me.  It's entertaining reading at least.

The Software development team (Will this show up when they Google their own names?)
Bilal Malik
Serge Tsayuk
Christian Van Horn
Brian Fahey
Jeff Smith

You are potentially bordering on slander here, perhaps...?

How is this relevant to you dear reader and software developer?  You can learn from my experience, and how to protect yourself from the abuses of Corporate culture, and our profit driven society.

Good luck with your quest.

44  Topics / Robotics / Re: Why Skid turn is more popular? on: April 14, 2014, 11:03:14 pm
Hi! I just wanna know why Skid turn Car is more popular in Robotics than the one that can turn it's front wheels?(don't know what to call it).

What you have termed "skid turn" is more properly called "differential steering", though you also see the more colloquial "skid steer" used as well (typically in relation to heavy equipment - ie, "skid steer loader"):

http://en.wikipedia.org/wiki/Differential_wheeled_robot

The other method is known as "Ackermann steering geometry":

http://en.wikipedia.org/wiki/Ackermann_steering_geometry

I thought the one that can turn front wheels is cheaper, can use only one motor, no need for H-Bridge,less programming??

I wouldn't say it is cheaper or easier, just different; you still need some kind of actuator to turn the front wheels to make the robot go in the desired direction. Invariably, this actuator is some kind of electric motor (although either pneumatics or hydraulics, among other methods, can be used). If using some kind of electric motor, you still need an h-bridge (even if using an RC servo - there is an h-bridge inside it). You also need some kind of feedback mechanism to know where the wheels are pointing (built into an RC servo, but other methods will need something custom if the actuator doesn't already have such a positional feedback mechanism). This may translate into more programming as well...

All in all - Ackermann steering can be more difficult to implement, both mechanically, as well as in software - for instance, to be able to get such a platform from one point to another, you have to know when and where along the path to angle the wheels, how much, and when to angle them back to keep advancing toward the goal location (and how to adjust if bumps, friction, or other problems cause the robot to deviate from the course). That's just one example of the extra software complexity involved.

Differential steering, on the other hand, is much easier to implement, and easier to program for; movement from point to point becomes a matter of vectors, which are fairly easy to visualize and code for. Of course, it makes for a more "jerky" movement - real differential steering is done so that the speed of the wheels is varied smoothly; this is especially important with real-world tracked vehicles (such as tanks and bulldozers, for instance) - because on certain terrain attempting high-speed central pivoting can actually cause the tracks to come off the wheels ("throwing a track"), because the rear and front of the track is being dragged sideways, pulling it off the idlers and such - which is why when such a maneuver is done, it is done fairly slowly, and only in soft ground to minimize this issue.

In the case of a multi-wheeled robot using differential steering, you don't have the issue of a track being thrown, but you do have the issue of the tire contact areas being "scrubbed" - literally the tread is ground off (particularly, again, on hard surfaces like asphalt and concrete), which can lead to other issues, least of all being the need to constantly put on new tires. There is also the issue (same as on tracked vehicles) of extra wear-and-tear on the wheel bearings, axles, drive system, etc - caused by the side-loading (this can be mitigated somewhat by using proper bearings in those areas).

Lastly - those two options aren't the only means of wheeled propulsion, but they are the two most popular, mainly because they can both be implemented using mostly or wholly off-the-shelf components. Other methods which you may run into (or you might want to investigate) for wheeled vehicles:

http://en.wikipedia.org/wiki/Omnidirectional_wheel

http://en.wikipedia.org/wiki/Mecanum_wheel

See also: http://www.ehow.com/list_7374953_types-steering-systems-used-robots.html

Both of these (and a few other methods) tend to be much more complex to implement, and don't typically lend themselves to off-the-shelf parts solutions (which tend to drive up the cost, sometimes greatly). But they should be kept in mind as potential alternatives, depending on what you are trying to accomplish.
45  Using Arduino / Motors, Mechanics, and Power / Re: Toy car h-bridge for Arduino ? on: April 13, 2014, 12:03:23 pm
i found an h-bridge in its circuit is it okay to use it to my arduino ?

First off, how do you -know- this is an h-bridge IC? The markings in your image certainly don't seem to convey that impression to me.

Given that it came from a "toy RC car", and that it is a 16 pin DIP IC, and without seeing the rest of the PCB from which it was removed from - my first impression is that it is the RX2 half of the TX2/RX2 chipset (or one of the other TX/RX variants).

Such an IC is -not- an h-bridge. Typically in toy RC cars, the common TX2/RX2 chipset is used for control; the TX2 (in the transmitter) outputs a specific pulse train, which is then picked up via a receiver in the car that is connected to an input pin on the RX2 chip (which is a 16 pin DIP IC, just like in your picture); this signal is then decoded to turn on/off certain pins on the chip. Those pins are then in turn connected to various control functions of the RC car. The actual h-bridges on such a car are usually built from discrete mosfet or bipolar transistor drive circuitry (I have also seen hybrid relay h-bridges as well, but those are unusual).

Without being able to see the actual PCB of the vehicle, there isn't any way to accurately tell you what that chip you have actually is or what it does (or may do). Regardless, until/unless you can find a datasheet for it, all we can do here is simply guess at its operation. It's difficult to tell from your picture, but is there a sticker or label on that chip (ie, what reads "27 MHz") that can be peeled off? If so, do that then clean up the chip (of label goo), and post a new picture (with better lighting) so we can read what the IC really is. Again, I suspect it isn't anything like an h-bridge.

Further reading on these cheap RC cars and the TX2/RX2 chipset can be found via this thread - I suggest that you familiarize yourself with it:

http://forum.arduino.cc/index.php/topic,86883.0.html
Pages: 1 2 [3] 4 5 ... 374