RoboSavvy Forum

dmtalk

2007-01-29T21:53:11+01:00

This is good news that you can TX/RX at the same time.

As for buffering.. I don't think this will be a problem. I was thinking potentially having some sort of dumb compression on the CM-5 <-> PC traffic. So I'd have to be inspecting the packets anyway, buffering the decompressed result wouldn't add anymore complexity.

I might end up buffering anyway as I have no idea if the Atmega128 has enough power to do it just in time before sending.

Statistics: Posted by billyzelsnack — Mon Jan 29, 2007 9:53 pm

dmtalk

2007-01-29T18:34:05+01:00

So I'm thinking about this a little more, and I realized there is one caveat - you need to make sure you have enough RAM for a receive buffer in the CM-5 (from the PC) to handle a full packet, which could reasonably be around 110 bytes. The Bioloid bus is a one-wire bus, so if the CM-5 started polling the servos just before it started to get a SYNC_WRITE from the PC, you would have to buffer a certain amount (if not all) of the SYNC_WRITE message.

Either that or you would have to be able to cancel the read mid-stream, but that seems like it could make things more complicated on the CM-5 side of things, and you'd still need at least a partial buffer.

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 6:34 pm

dmtalk

2007-01-29T18:28:31+01:00

So it seems I was wrong on this one - you can do simultaneous transmit and receive between a PC and an ATmega128.

I guess that makes your concept of pushing sensor data to the PC from the CM-5 a pretty good one.

Just goes to show, it doesn't matter how long you've been doing embedded programming, you still learn new stuff every day...

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 6:28 pm

dmtalk

2007-01-29T17:45:58+01:00

I see. I'd be astonished if an ATMega128 couldn't handle it (with the proper software support to keep both data paths busy), since this is exactly what "full duplex" means, but I have never tried it on an Atmel chip so I can't say for sure.

Statistics: Posted by DerekZahn — Mon Jan 29, 2007 5:45 pm

dmtalk

2007-01-29T17:39:19+01:00

No, there isn't anything funny about the CM-5, its just an ATmega128.

I guess I may stand corrected, but I'll be interested in hearing from an ATmega128 expert on whether the hardware UART can handle that.

You're using LPC2138's for the nodes on Bing, which is a far more powerful processor than the ATmega128.

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 5:39 pm

dmtalk

2007-01-29T17:31:03+01:00

Sorry to jump in here as I do not have a Bioloid, but I'm not quite understanding the limitation you're talking about Jon. Is it a hardware or software limitation on the CM-5? I use an RS-232 bus on Bing and every node (including the PC) is simultaneously sending and receiving data at 115k baud. That way my packets only incur one byte of latency through each node. The RX and TX paths are completely distinct (different pins, different hardware on the processor UARTs, etc) so there is no reason for it not to work, and I don't see any problems. There is no "master" as such, each connection of RX-TX or TX-RX is completely distinct and requires no synchronization with the other path.

Is the CM-5 hardware unusually badly designed so that it can only do half duplex?

Statistics: Posted by DerekZahn — Mon Jan 29, 2007 5:31 pm

dmtalk

2007-01-29T17:03:36+01:00

The reason they each have their own wires is to make it electrically simpler to handle. It also allows a certain amount of multi-master, although there are no guarantees that it will work.

The reason it makes more sense for the PC to be the master is then there are no timing/conflict issues.

If you really wanted to do it that way, you could have the CM-5 send a special "notification packet" to the PC that would signal the PC that it was time for it to send position/speed values. The CM-5 would then have to wait until it got the data from the PC before sending anything else.

If you're running a 115K link between the PC and the CM-5, you're going to be limited with how often you can send sensor data back. Using my previous estimate of 166 bytes per poll, that is 1660 bits per cycle. Your absolute theoretical maximum in that case would be around 69 cycles per second, and that's assuming you never send anything to the servos, only getting data from them.

Basically, in real terms, you've got about 50 transactions per second, and you need to divide that up into sends and receives. You can increase that number by getting less data from each servo. My estimates are based on getting 8 bytes per servo, which includes position, speed, load, voltage, and temperature. You could skip the last two, and reduce the total transfer by 40 bytes, but you're still in the same general ballpark.

Sending and receiving the "minimum" reasonable amount of data, you're looking at about 40 cycles per second, if you want load information from the servos. That's going to completely saturate your serial connection.

These timing limitations are the main reason I am building a 1.0 Mbps wireless connection between the PC and the bus.

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 5:03 pm

dmtalk

2007-01-29T16:39:00+01:00

That's a good thing to know. I just assumed that you could because they each had their own wire. What's the point of them having their own wires?

Statistics: Posted by billyzelsnack — Mon Jan 29, 2007 4:39 pm

dmtalk

2007-01-29T13:34:50+01:00

You have contention because you can't both read & write at the same time. The only serial protocol I've ever heard of that allows that is SPI.

If both the PC and the ATmega128 decide to start transmitting at the same time, you're going to have problems...

I2C has a really nice way of dealing with that (multi-master), with a simple bus arbitration scheme built into the hardware that chooses the winner when there is a conflict.

RS-232 has no such niceness...

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 1:34 pm

dmtalk

2007-01-29T07:16:26+01:00

Why would there be contention? You've got separate TX/RX wires between the PC and uC.

I also am not so sure about a 1 to 1 send/receive of data. I think I'd prefer doing more reads than writes if I can sustain a any reasonable frames per second. Meaning.. I'd rather have 30 reads and 20 writes than 25 reads and 25 writes per second. I think that I might even not care so much about writes above say 50hz, but I'd sure take the ability to have reads at 100hz and beyond.

Statistics: Posted by billyzelsnack — Mon Jan 29, 2007 7:16 am

dmtalk

2007-01-29T04:51:07+01:00

I have thought about what you are talking about, with the auto-sync read. The only downside I see to it is the PC then has to be very careful about how it communicates with the bus, because you really want to send data down on the bus at least as often as you get data back again.

Since the PC is not typically a hard real-time device, getting the timing correct (to avoid contention between the PC and the ATmega128) could prove problematic.

- Jon

Statistics: Posted by JonHylands — Mon Jan 29, 2007 4:51 am

dmtalk

2007-01-29T03:21:01+01:00

I'm thinking of coding up something a little different than a sync read. It could be thought of more as an auto sync read I guess.

The idea is that you send a command from the PC with everything that you want and an update interval. The cm5 will then grab all that data from the servos and send it to the PC with no more read requests from the PC.

This gets rid of some latency and bandwidth. For my application I would be sending the same packets over and over again, so why even bother. The rest of the api will still be there for one off requests, but this would be used most of the time.

Statistics: Posted by billyzelsnack — Mon Jan 29, 2007 3:21 am

dmtalk

2007-01-28T14:00:33+01:00

One of the things I'm working on in the next week is my 5-axis IMU. This will be a tiny board, that stacks under the Sparkfun 5-axis IMU board, with an ATmega168 on it. The 168 will get input from the IMU board via 6 A/D converters, and it will talk on the Bioloid bus at 1.0 Mbps as a slave device, just like anything else.

The IMU will be powered off the bus, so it will literally be a bus device.

My brother is puttng together a slave framework for parsing bus commands that will run on the 168. I'm going to finish that, and add in the IMU-specific code. I'm going to publish the whole thing once I'm done.

Doing a bus device to run a standard hobby servo would be pretty straight forward, I think...

- Jon

Statistics: Posted by JonHylands — Sun Jan 28, 2007 2:00 pm

dmtalk

2007-01-28T05:30:54+01:00

pepperm.

Sure. I'll help out. Looks like your plans are very much in line with mine. I basically want to hang sensors off the normal Dynamixel bus. Specifically I want to make an interface that'll accept a standard RC gyro.

My background is PC based software, but I am starting to get the hang of this uC stuff. As for circuit design. hahah. Let's just not talk about my progress with that!

JonHylands.

Yeah. I think sync read is going to be happening very soon in my code.

128*1024/8 = 16384 bytes per second / 18 servos = 910 bytes per second per servo / 50hz = 18 bytes @ 50hz

Maybe it's half that for bidirectional? Maybe it's div 9 for the 8n1? I dunno.

So the bandwidth is there or can easily get there for the PC<->CM5 (or whatever's in the middle) with a little dumb compression.

There must be something else going on besides bandwidth. Maybe my serial read code is broke (still looking into that) or something else in code land. OR.. Maybe there it just a large constant expense to tx/rx any packet. If that's the case, then that is where a sync read could really shine.

Statistics: Posted by billyzelsnack — Sun Jan 28, 2007 5:30 am

dmtalk

2007-01-27T13:58:19+01:00

What I'm planning on doing eventually is implement a new command: SYNC_READ.

The premise behind this command is the connection between the ATmega128 and the AX-12s is very fast and low latency, and the connection between your PC program and the ATmega128 might not be.

So basically, it will work like this:

PC issues SYNC_READ, with start address (same for all servos), length (same for all servos), and the IDs you want to poll.

ATmega128 gets the command, starts firing READ_DATA commands for each servo in the set, with the given start address and length. It stores the results in a RAM table it has set aside for this.

When the last servo is done, it sends the response back to the PC, all in one shot.

The numbers usually tell a lot of the story:

Reading 8 bytes per servo, 20 servos (READ_DATA): 14 bytes per servo response, for a total of 280 bytes

Using SYNC_READ for the same thing: 166 bytes

It really depends on how you have your PC connection set up. If your PC is using a USB interface to directly talk to the bus, then SYNC_READ won't help you at all. But if you've got a wireless link in there, and you have any kind of measurable latency in your link, SYNC_READ would be a big boost.

- Jon

Statistics: Posted by JonHylands — Sat Jan 27, 2007 1:58 pm