Show Posts
Pages: [1] 2 3 ... 187
1  Topics / Robotics / Re: Laser Range Finder for Arduino Robot or similar on: November 29, 2013, 12:19:17 am
Yeah, the whole thing looks very nice. With such as that geometry, the weight of the sensor is supported by the mechanical components of the servo, not held by the motor torque. The motor rotation torque required is quite low. Panning is easy, you get into lots more trouble with tilt, and off-center weight distribution.

SICK laser scanners do rapid "3D" [or whatever they call them] scans , but they're also made for vehicles moving 50-60 Km/hr. Little robots hardly need that - most people just use Ping and Max sonars, and have to wait a long 20-40 msec for the echos to return. I'm sure the SF02 would be fine for 95% of robots in existence. For room-mapping, the robot doesn't need to move very quickly, so there's plenty of time for a wide-angle scan. For collision-detection while on the move, you mainly need a narrow-angle scan to detect objects in front. This should appeal to people doing robots for inside use who are otherwise considering SICK scanners or possibly a Kinect.
2  Topics / Robotics / Re: Video processed in the laptop. on: November 27, 2013, 04:59:27 pm
Quote
I have a project that I want to do for uni. I want to make like an avoider of collision for several cars. Users control cars and once those gets close to one another, then, the system take the priority over the user in order to avoid accident.

There are a limited number of things you can do along these lines, but your professer probably didn't mention that people have been working on computer vision for 50 years, and the problem is just beginning to be solved. Not quite as good as what animals do. IOW, it's a non-trivial matter, but still worth a go. Can lead to a long career working on same.

Some of the initial DARPA Challenge vehicles a couple of years ago tried using binocular vision for main guidance, but it proved too difficult to be reliable. Since then, EVERYONE uses laser scanners, and they've had 1000% better success. Computer vision is probably best combined with other types of sensors - eg, sonars.

You might research the Darpa Urban Challenge,
http://www.google.com/custom?q=darpa+urban+challenge&btnG=Search
3  Topics / Robotics / Re: Towerpro servos from ebay on: November 26, 2013, 04:41:39 pm
I've bought servos and other items from HobbyKing, and am satisfied. May be a good choice, and less to worry about in regards the vendor.

http://hobbyking.com/hobbyking/store/RC_PRODUCT_SEARCH.asp?searchType=10&strSearch=servo+metal+gear&location=AL&idCategory=&sortBy=Relevant&NumPerPage=100&currentPage=

http://hobbyking.com/hobbyking/store/RC_PRODUCT_SEARCH.asp?searchType=10&strSearch=servo+tower+pro&location=AL&idCategory=&sortBy=Relevant&NumPerPage=100&currentPage=

Personally, I think there may be 2 pricing tiers with a lot of these items. The lower level is what most companies charge, in order to be competitive. The higher price is what some people charge, since they figure they can get away with it, if the customers don't shop around too much. Just a guess.
4  Topics / Robotics / Re: Laser Range Finder for Arduino Robot or similar on: November 26, 2013, 01:59:31 am
For just panning, I don't think you would need a fancy bracket. Most std servos have a circular horn and/or an X-shaped horn, so you just need a convenient way to catch 4 screws in a square-formation about 15-20 mm on a side, and you'd have a stable mount. Eg, 4 such holes for #4 screws placed at the central balance point of the LRF would probably suffice.

I'm not sure how standardized the hole patterns in servo horns are, but one possibility would be to include a plastic spacer board, drilled to match the LRF holes, and which could be drilled by the users to attach to their particular servo horns.

I also think if you try mounting your LRF on a std (44 oz-in) servo, you'll find it pans OK.
5  Topics / Robotics / Re: Laser Range Finder for Arduino Robot or similar on: November 26, 2013, 01:09:12 am
That looks like a nice unit. Personally, for someone who really wanted an LRF, I don't think $250 is out of the question. The robot carrying it would likely cost in the same ball park price, or more, so I think the LRF is in the general price range for "that" market, although as imagined, I doubt that "that" market is very big either. However, 40m is a very nice range, and I doubt the Neato vac device comes anywhere close to that.

Despite the claims, I also can't imagine it really weighs only 75g. A ckt board that size already weighs in at about 50g, and those optical tubes don't look all that lightweight, so ??? However, if really that light in weight, almost any standard-sized servo panning device could handle it, so I don't think that's much of an issue.

6  Topics / Robotics / Re: RC Car / Motor Control Problem (current??) on: November 22, 2013, 04:29:49 pm
What is the gear ratio on the motors. How fast do they turn when unloaded? How heavy is the car?
7  Topics / Robotics / Re: 4WD vs 6WD when Turning on: November 20, 2013, 02:16:38 am
Thanks for the reply. So the best solution is more powerful motor. I thought it'll be easier to turn when there are wheels on the middle, I thought it's the reason why they make 6WD.  I'm going to move my wheels closer, see if it'll help. Thanks!
Also, you can get 2 different sets of motors with the same gear ratios, but with different torque values - and much different currents. Ah, I see the 285, 34:1 is already the high-current motor,
http://www.pololu.com/category/115/25d-mm-gearmotors

I am a little surprised, as I'd have thought it would turn better out of doors, as the wheels will be able to slip better than on hard floors or carpet, like mine.

The bipolar transistor h-bridges might not be the best. Pololu uses heavy-duty contorllers,
http://www.pololu.com/product/1564
8  Topics / Robotics / Re: 4WD vs 6WD when Turning on: November 19, 2013, 08:46:59 pm
I assume if you go to 6WD, the wheelbase will be even longer, and then it will be even "more" difficult to get it to turn. With wheels, the longer the wheelbase is compared to the width, the harder it is to turn. Recently, I had a similar problem with a similar 4WD base, not the Thumper. I ended up going to motors with higher torque - unfortunately also lower speed. I've only been using mine inside the house so far. With the 280 RPM motors, it would turn on hardwood floor, but not on carpet. With 76 RPM motors, it turns on carpet now.

I think what you have to do with these sort of platforms is greatly jack up the motor duty cycles when turning - unfortunately. They don't tell you that in the marketing brochures.
9  Topics / Robotics / Re: Quadripo gait sequence on: November 15, 2013, 03:26:37 pm
Splayed legs like that don't make for a very good QUAD-ruped. They work better for a hexapod. You will notice in the video, he never lifts the legs to any extent, so the 4 feet are always sliding along the floor. Won't work well on a carpet that has greater than zero sliding friction.

Basically, the video is using what's called a "trot" gait, ie, opposite corner legs move simultaneously. There is also a "creep' gait, where only 1 leg at a time moves .
http://www.google.com/custom?q=trot+creep+gait&btnG=Search

You might check what you can find out about the Lynxmotion quadrapod gaits,
http://www.lynxmotion.com/c-26-quadrapods.aspx

Also, best first,


10  Using Arduino / Programming Questions / Re: RS232 UART frame/data overrun error handling on: November 11, 2013, 11:42:50 pm
Wired-AND diode ckt:
http://en.wikipedia.org/wiki/Wired_logic_connection
DTL NAND gate - wired-AND with inverter:
http://en.wikipedia.org/wiki/Diode%E2%80%93transistor_logic
TTL NAND gate, upgrade on DTL NAND:
http://www.allaboutcircuits.com/vol_4/chpt_3/5.html

Quote
To protect them from a short-circuit?
The reason for using  wired-AND is because, for RS232 UARTs, the idle state is high, and the active state is low, and only 1 signal goes low at a time, and the diodes isolate the inputs from each other. This is negative-logic, a wired-OR would be used for positive-logic.

I'm using diodes initially, but also bought a few 74HC logic gates last week, just in case.
11  Using Arduino / Programming Questions / Re: RS232 UART frame/data overrun error handling on: November 11, 2013, 03:29:02 pm
Actually, I was more curious as to whether the Rx UART might hang/whatever in case there were various frame/overrun errors. I should have realized then that it doesn't happen in the case the sender is using the wrong baudrate, so unlikely to happen for such cases. However, I do like to try and understand the basic underlying code too. After all, it could have read something like,
Code:
ISR(USART0_RX_vect)
{
    if ( !any-error() ) {
      unsigned char c = UDR0;
      store_char(c, &rx_buffer);
    } else {
      unsigned char c = UDR0;
    };
}

Also, I am currently in the process of building an RS232 master/slave network, where the master Tx pin goes to all the slave Rx pins, and the slave Tx pins are all wired-ANDed together. Normally, the slaves only "respond" to master transmissions [each slave has a unique node_address for filtering incoming msgs], but I also wanted to give the slaves ability to "request service", eg by sending a short "!!" msg, so there's a possibility that more than 1 slave might signal at the same time, and the msgs would clash.  Then there would be Rx errors in the master UART.

The network should be working in the next day or two. Maybe I'll post how it goes. [probably should have posted this thread to the Networking section].
12  Using Arduino / Programming Questions / Re: RS232 UART frame/data overrun error handling on: November 11, 2013, 12:03:41 pm
I'm thinking the character that invoked the error flag will likely be wrong, let's say due to a noise spike that caused a framing error, but the UART will keep plugging along, so the next chars will be received OK. It appears to be only the parity error that causes no data to be stored.

Also, it occurred to me, the more likely case is the incoming data baudrate is different from the UART setting, so the UART just keeps putting out bad data, but doesn't hang in the process.
13  Using Arduino / Programming Questions / RS232 UART frame/data overrun error handling on: November 10, 2013, 10:15:35 pm
I did some searches but did not find info on this. I am trying to understand what sort of error handling the Arduino HardwareSerial routines perform. Apparently little to none, from what I can tell.

First, I tried to boil down the Rx ISR code in the HardwareSerial.cpp file (for the ATmega328) to the bare minimum, and came up with the following. It appears to do a parity error check, but no others.
Code:
ISR(USART0_RX_vect)
{
    if (bit_is_clear(UCSR0A, UPE0)) {
      unsigned char c = UDR0;
      store_char(c, &rx_buffer);
    } else {
      unsigned char c = UDR0;
    };
}

Secondly, the ATmega328 d/s says the following:
Quote
20.11.2 UCSRnA – USART Control and Status Register n A

• Bit 4 – FEn: Frame Error
This bit is set if the next character in the receive buffer had a Frame Error when received. I.e., when the first stop
bit of the next character in the receive buffer is zero. This bit is valid until the receive buffer (UDRn) is read. The
FEn bit is zero when the stop bit of received data is one. Always set this bit to zero when writing to UCSRnA.

• Bit 3 – DORn: Data OverRun
This bit is set if a Data OverRun condition is detected. A Data OverRun occurs when the receive buffer is full (two
characters), it is a new character waiting in the Receive Shift Register, and a new start bit is detected. This bit is
valid until the receive buffer (UDRn) is read. Always set this bit to zero when writing to UCSRnA.

• Bit 2 – UPEn: USART Parity Error
This bit is set if the next character in the receive buffer had a Parity Error when received and the Parity Checking
was enabled at that point (UPMn1 = 1). This bit is valid until the receive buffer (UDRn) is read. Always set this bit to
zero when writing to UCSRnA.
All 3 items say "This bit is valid until the receive buffer (UDRn) is read".

So, putting 1 and 2 together, it appears that any Rx character that invokes an FE, DOR, or UPE error will likely be incorrect in the  c = UDR0; assignment, but UART reception will NOT be disrupted in any way, and it will go on to receive any follow-on characters ok. IOW, such errors will just trigger flags, but they'll have no effect if ignored. The data will just be wrong.

Yes, no, maybe?
14  Topics / Robotics / Re: Direction algorithm needed. on: November 09, 2013, 01:05:21 pm
Yeah, speed alone does not give direction. Think about it. If one motor were turning some amount faster than the other, the robot trajectory would be a spiral or circle, with direction constantly changing. To go in a specific direction, you turn at some speed for a certain amount of time, then you straighten the steering wheel, and go straight after that. Etc.
15  Topics / Robotics / Re: Machine Learning with LCS on: November 08, 2013, 02:56:23 pm
Resource requirements sound fairly moderate. But 100 strings of 100 chars each is 10KB, and still a little more than any std Arduino can handle, assuming you need to change them. Looks like you're the favored man to do the project, :-). If you can find "any" source code written in C, then should be translatable to Arduino.
Pages: [1] 2 3 ... 187