For Propeller + Biloid interest group

[lnielsen]

quickster47,

I see you post on Parallax's Robotic and BasicStamp forums, I only monitor the Propeller (and sometimes HYDRA) forums there.
Which Propeller boards did you get?
I am waiting for the PropCAM as my vision module of choice.
There is a second Forth system called CogForth under development but nothing has been published yet. You can also look at FemtoBasic as an option but I think Forth is the way to go.

[quickster47]

I picked up a Propeller Starter Kit, a PropStick USB, and a Propeller Proto Board. I couldn't make up my mind and was not sure what I wanted to eventually do so I just bought a variety.

Now I need to retire so I can start using all this neat stuff.

Thanks for the heads up on the other two language choices.

And that PropCam is most appealing. That will be another accessory that I am going to NEED.

Carl

[limor]

I would like to try and connect a µOLED-96-PROP to the Bioloid bus.
Has anyone tested Inaki's Propeller Bioloid driver code from last year or actually connected the µOLED-96-PROP to the Bioloid bus?

[i-Bot]

I have modified and tried Inaki's code on the uOLED-96-PROP. The uOLED is powered from a 5V regulator from the bus Vdd.

The writing to the bus works fine, but the reading is not yet working. I am not sure the reading ever worked properly in the code. There is lots of good work here, and it should not take too much time to get working on the uOLED.

I can take a further look at the reading. I think also that we can save 2 pins (shortage on uOLED !), and a cog in the process, since the protocol is half duplex.

Are you wanting to use the uOLED as the controller, a slave device, or either ?

[i-Bot]

I took a further look at this software, and there is a real problem with the reading from the bioloid bus.

The prop can read its own output OK, but not responses from the servos. This seems to be because the interbyte delay is very short, and does not give enough time for the Propeller cog to write the data to hub memory. This might be resolved by keeping the packet in the cog until the end, then sending to hub.

The uOLED works at 64Mhz, rather than the 80Mhz on the demo board, but this is not enough to make the difference.

Is anyone interested to work on this ? The driver will become more specific (master/slave ), there is no easy way to make a buffered 1M UART capable of contiguous bytes.

[limor]

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.

[i-Bot]

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 ?

[JonHylands]

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

[i-Bot]

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.

[JonHylands]

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: Select all

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

[i-Bot]

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.

[i-Bot]

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!

[JonHylands]

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

[lnielsen]

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...

[limor]

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) ?