RoboSavvy Forum

For Propeller + Biloid interest group

2008-06-23T16:06:26+01:00

Any more updates to this effort? I've recently been very interested in the propeller microcontrollers ever since I read the article on the propeller-based BOE bot in the Spring issue of Robot Mag...

I would love to see some examples of software as well as the hardware - mechanical and electrical implementations with the Bioloid system...

Did you guys piggy-back this awesome processor with the CM-5 unit, or did you guys replace the CM-5 unit with this venerable microcontroller?

Statistics: Posted by tom_chang79 — Mon Jun 23, 2008 4:06 pm

For Propeller + Biloid interest group

2008-04-17T00:38:06+01:00

Yes, so many ideas and so little time.

With the IOC, you can use it in two ways. One way is called basic mode. This mode has 16 GPIO and 2 dedicated prop pins plus the 2 prop pins used for programming (not to forget the I2C bus as well). Another mode is called extended and requires slight soldering modifications to the IOC and uOLED-PROP-96, but it will open up the ability to have 16 GPIO, 4 dedicated prop pins plus the 2 prop pins used for programming and the two pins used on the I2C bus. So, the IOC really expands the I/O for the Prop.

You guys have certainly been thinking about and realize what you want and need in a carrier board. I need to do more research and studying before I jump into designing a ssytem, but it is very doable to make a carrier with a regulator, AX-12 interface (or two) and a some other buttons and switches with a little I/O left over for experimentation.

As far as audio goes, what are you looking for? If you just want pops and clicks, then, yes, I think the GPIO should be able to handle it with an ASM driver (current driver is in SPIN). I don't have much experience in coding or hardware design for audio, so I better research that or I might eat my words.

Hmmm....I better pick up an AX-12 servo or two soon.

Statistics: Posted by Brilldea — Thu Apr 17, 2008 12:38 am

For Propeller + Biloid interest group

2008-04-16T14:01:34+01:00

i-Bot: You are right, the serial bus will always have to run on a dedicated Propeller pin and not through the IOC. I don't know how fast the IOC is, can it only read switches and stuff or can I do audio through it?

Brilldea: I see a couple of ways to go. I like I_Bot's idea of a super AX-S1, it should be register compatible with the S1 but be able to play WAV files and animated GIFs. It would be great to add an accelerometer like this one.

As a controller, I think it would be nice to support both TTL and RS-485 busses preferably as a single bus combined via open-collector so you could add a RX servo if you need more power in a joint. You could have a few buttons around the screen as a soft screen and bluetooth to talk to a gamepad controller

So many great ideas, so little time...

Statistics: Posted by lnielsen — Wed Apr 16, 2008 2:01 pm

For Propeller + Biloid interest group

2008-04-16T09:37:06+01:00

The uOLED-96-PROP is certainly challenged on I/O with only really 4 pins available. I only use 1 pin for the AX12 interface, since it is half duplex. However it is possible to have multiple serial buses on the same uOLED.

My carrier board has a 5Volt regulator to drop the 9.6V AX12 supply. It also has an NMOS FET as the voltage translator to/from 3.3V for the serial data.

The AX code is in assembler and would not run off an expander port at 1M bps

If you are looking to a carrier board, it should be small, and have the voltage regulator and the logic translator.

I2C does seem the way to go for other expansion. This would allow available I2C devices like accelerometers, compass, sonar to be used.

For my code, I have been concentrating more on the CM-uOLED code, which is the controller. I diverged from the work at Crustcrawler, though gained some good ideas there. The Crustcrawler code would not work on the uOLED due to the 64MHz clock. I made new code which does work OK at 64M. I also integrated the serial protocol and the checksum into the assembler part. The object just exposes spin methods for the bus commands. I am now looking to read MTN motion files from the SD card and interpet them into bus commands using a COG dedicated to a motion engine.

I have not made much more progress on the AX-uOLED code, which is the peripheral. This has a different interface since it exposes methods to manage an area of Hub RAM similar to the memory map of the AX devices. A seperate COG runs the assembler program which continually monitors the serial bus looking for our ID or the broadcast ID, perfoms commands, and reads/write to the hub RAM. I completed the memory interface, though I had to add I2C and EEPROM assembler routines to use the program EEPROM to save the lower memory segment. The new TX and RX routines in the CM version could also be used in the AX. I am not sure when I will return to this version. I still see no simple way to send data from BCP, except byte by byte, hence my focus on the CM. I already made routines to display 16bit bitmaps on the uOLED from SD card which I use on the RoboNova, but again see no easy way to send filenames from BCP.

Statistics: Posted by i-Bot — Wed Apr 16, 2008 9:37 am

For Propeller + Biloid interest group

2008-04-16T07:23:22+01:00

lnielsen -

Thank you for the mention of the uOLED-IOC! The IOC is a great companion for the uOLED-PROP-96 by expanding the I/O capability. How many pins is the software dedicating to the AX-12? If you used the uOLED-IOC you have options of connecting the I/O to the GPIO chip or directly to the Prop. Of course, the Prop would have a faster I/O access, but an ASM routine for talking to the GPIO is in the works (whenever I get more time) and that would allow for fast access to the GPIO.

A while ago I thought about desinging some hardware for using the AX-12 and the uOLED product together. Maybe I will have to stir up that idea if there is enough interest. Would a breakout board, sort of like the uOLED-IOC, be desired by the community? The board would have the connectors to hook up the AX-12 and a place to plug in the uOLED-PROP-96. Maybe a button or two or how about a capacitive slider like your IPOD? Your thoughts?

Statistics: Posted by Brilldea — Wed Apr 16, 2008 7:23 am

For Propeller + Biloid interest group

2008-03-28T19:49:01+01:00

i-Bot wrote:
The work of Inaki looks to have been developed into a fairly complete and reusable Bioloid object here:
http://forum.crustcrawler.com/phpBB3/vi ... =12&t=1050

I took this object and successfully transferred it to the uOLED. It need some internal changes, but the structure is the same. We saved a pin and a cog in the process

I used some of the Inaki code with the crustcrawler, so we now have a CM-uOLED. We saved a pin and a cog in the process

Now I still have to look to the implementation details of the AX-uOLED, the current object is controller only.

If i understand correctly, Mike's code for the Propeller sets it as an intermediary between a BASIC-Stamp and the AX12 bus.
Hence the Propeller is acting as a AX12 bus-master (replacing the CM5). you call this : CM-uOLED . did you upload this code somewhere?

How is the AX-uOLED code progressing (uOLED serving as a bus-slave) ?

Statistics: Posted by limor — Fri Mar 28, 2008 7:49 pm

For Propeller + Biloid interest group

2008-03-27T20:35:08+01:00

Congrats to i-Bot and Mike Gebhard on fixing and improving Inaki's code. This is a real shot in the arm for the Propeller/Bioloid community.

Can you provide some more details on your plans for the AX-uOLED? It sounds like you will be able to display messages, what about storing and playing images and animated images from the SD card? Monitoring the status of one servo? What about using something like the uOLED-IOC to add some switches for user input? You could also provide far superior audio in/out compared to the Bioloid AX-S1

I may just have to buy a uOLED now...

Statistics: Posted by lnielsen — Thu Mar 27, 2008 8:35 pm

For Propeller + Biloid interest group

2008-03-24T16:11:56+01:00

If I was doing this, I would set up a decently large space (say, 64 bytes) at the end of the control table as the "buffer", with a one-byte prefix for size. Then, you could do something like a WRITE_DATA, with the start address as the location of the size byte, and the length being the number of bytes in the string + 1.

I don't know anything about the BCP, but if you're building a Bioloid device, you should concern yourself with the direct binary bus interface, not whatever front-end the BCP provides.

The format of the WRITE_DATA command is well documented in the AX-12 manual. WRITE_DATA allows you to write bytes to the control table, either one at a time, or in a whole group.

- Jon

Statistics: Posted by JonHylands — Mon Mar 24, 2008 4:11 pm

For Propeller + Biloid interest group

2008-03-24T14:29:24+01:00

The suggestion from Limor to send text to the display from BCP seems more difficult than I thought.. Maybe I do not understand enough about BCP.

To make the AX-uOLED as a device with a memory map similar to existing AX devices is OK. I can present the display input buffer as a single location, or a block within the AX memory range.

What I don't really understand (as a RoboNovaNerd !) is how to integrate to the BCP. How could we send a text string to a device from BCP, and how would that be presented in the AX device memory ?

I do not see how BCP knows if the device destination is a byte or a word, never mind a string !

Also we have access to a FAT file system on the uOLED SD card. Any value to BCP programs ?

Does any one know how to put a string into an AX device from BCP ? I can map the AX memory in any way to accomodate this. A single byte at a time would be tedious!

Statistics: Posted by i-Bot — Mon Mar 24, 2008 2:29 pm

For Propeller + Biloid interest group

2008-03-17T15:05:34+01:00

The work of Inaki looks to have been developed into a fairly complete and reusable Bioloid object here:
http://forum.crustcrawler.com/phpBB3/vi ... =12&t=1050

I took this object and successfully transferred it to the uOLED. It need some internal changes, but the structure is the same. We saved a pin and a cog in the process

I used some of the Inaki code with the crustcrawler, so we now have a CM-uOLED. We saved a pin and a cog in the process

Now I still have to look to the implementation details of the AX-uOLED, the current object is controller only.

Statistics: Posted by i-Bot — Mon Mar 17, 2008 3:05 pm

For Propeller + Biloid interest group

2008-03-14T17:32:50+01:00

The behavior of a bus device is specified pretty clearly for each register in the AX-12 manual.

I would strongly recommend that you read the AX-12 manual, and especially the section where they talk about each control table entry, and how the device responds.

On page 22 of the AX-12 manual, it says "Regardless of whether the Broadcasting ID is used or the Status Return Level (Address 16) is 0, a Status Packet is always returned by the PING instruction."

I didn't implement LOCK.

There might not be any delay between packets - it shouldn't matter if you're using a hardware UART. If you're bit-banging on the propeller, you want to be ready to receive data in under a millisecond after the response is sent (which you will also parse if it is a response from another device).

For the delay, I just do this:

Code:: us_spin(gControlTable [CONTROL_RETURN_DELAY_TIME] * 2);

after I've processed the command, and before I return the response. Its the minimum delay time before sending a response.

- Jon

Statistics: Posted by JonHylands — Fri Mar 14, 2008 5:32 pm

For Propeller + Biloid interest group

2008-03-14T15:58:06+01:00

Many thanks, just what I needed.

For the status return level, what about a PING ? How do you respond at different levels ?

Is there any use in implementing LOCK ?

What is the minumum interpacket delay from the typical controllers ?

For the return delay. Is this the minimum time before the device will respond ? or must the device respond within the set time.

Statistics: Posted by i-Bot — Fri Mar 14, 2008 3:58 pm

For Propeller + Biloid interest group

2008-03-14T14:12:43+01:00

If you look at my IMU code, you'll get an example. I'll repost the interesting parts here...

MODEL_NUMBER_LOW 0
MODEL_NUMBER_HIGH 1
FIRMWARE_VERSION 2
ID 3
BAUD_RATE 4
RETURN_DELAY_TIME 5
STATUS_RETURN_LEVEL 16

LED 25

The EEPROM table ends at 23, and the RAM table starts at 24. The entries in the entire control table are stored in RAM while the device is running, but the EEPROM entries are also replicated in EEPROM, so they remain after a power-out.

Anything after the LED entry is fair game for your application, and entries 6-15 and 17-23 are available for stuff that should be stored in EEPROM.

From a command standpoint, you should implement at least:

PING
READ_DATA
WRITE_DATA
RESET

The important thing you have to realize, is that every device gets and has to parse every command. If the ID doesn't match your id, then ignore it. If the ID does match and its a command you don't recognize, ignore it.

To be really useful, you should be able to correctly respond to changes in the following 3 entries:

BAUD_RATE
RETURN_DELAY_TIME
STATUS_RETURN_LEVEL

Of course, you also should handle changing the device ID.

All of my devices work this way, and the framework of code my brother I and have written to support it allows me to build new types of devices without re-writing any of this baseline code.

- Jon

Statistics: Posted by JonHylands — Fri Mar 14, 2008 2:12 pm

For Propeller + Biloid interest group

2008-03-14T09:58:26+01:00

I rewrote the receive object as I suggested, and can now read and display the 1M stream OK on the uOLED.

The Prop is a cute device to program in assembler, and the tools are not helpful for debugging. Still I learnt a lot about the Prop architecture, and have reluctantly leant to accept self modifying code.

Limor, it should now be fairly easy to make a display device driven from behavior control program. I am not very knowledgable on Bioloid. Can someone make a specification of how the tables should look for a bus device, and the minimum command set that the device should respond to to perform the display function ? Is there any existing similar device to copy ?

Statistics: Posted by i-Bot — Fri Mar 14, 2008 9:58 am

For Propeller + Biloid interest group

2008-03-14T01:54:35+01:00

i was hoping to use this as an output device. maybe even work out a way to use the behavior control software to send text messages to be displayed.

Statistics: Posted by limor — Fri Mar 14, 2008 1:54 am