Using TTL Level Signals/Communication on wCK Bus & BT So

[PedroR]

Hi all

As you may know we have been working on porting the Linuxified solution we've built for the Wild Thumper to the Robobuilder. (see here http://robosavvy.com/forum/viewtopic.php?t=7597 )

To do this we've been experimenting with a number of different solutions and came to interesting findings:

1) Communicating directly with the servos:

The wCk servo bus uses TTL level communication (Full Duplex at 115kbps by default but in practice can go up to 480 kbps).

We confirmed the signal level on the TTL bus is 5V (not 3.3V) but we found some interesting behaviour:

- Usually 5V devices can accept and read 3.3V data
That's the principle behind universal TTL adapters such as this all-time classic http://robosavvy.com/store/product_info ... cts_id/545. They drop the RX line to 3.3V and output on TX is at 3.3V as well which is usually enough to be detected by 5V devices

- On Robobuilder though, if you send a 3.3V signal on the bus it will be completely ignored. We're not really sure if there is attenuation on the line or if it's just picky but we waisted about an hour with our Sparkfun adapter until an Oscilloscope shed some light.


2) Communicating with the RBC controller via the Bluetooth Socket

All Robobuilder controllers come equipped with a Bluetooth socket prepared to receive a Parani ESD200. We sell the adapter pre programmed for the correct Baud, Discovery mode, etc and ready to use with Robobuilder.

This solution uses the "Bluetooth Serial port profile" and is designed to create a transparent (virtual) serial comm port between the PC or Phone and the Robot.
In terms of schematics the RX and TX lines on the BT socket are connected in parallel with RX and TX comming from the PC.

The only difference here is that RC and TX from the PC are level shifted to RS232 where the BT socket has all the pins at 3.3V.

Our experiment aimed to test if we could use the pins on the Bluetooth socket to send commands to the RBC controller using our Sparkfun USb to TTL adapter once again.
What we wanted to test was which pins needed to be connected: if just RX and TX or if any others:

The pinout for the parani ESD200 includes a number of important pins such as the BTDET pin but our findings show that you only need to connect RX and TX pins.

Also with regards to the signal level, this one is definitely at 3.3V (on the BT socket) so we're happy to say it worked at first attempt!


We're continuing our work on this solution and I am personally very interested to see the outcome. For fairly cheap you can have console Linux, WiFi and USB on Robobuilder with access to Querying all the Robot's Sensors and controlling all the servos.

The idea is to adapt Linuxified: this is a simple combination of an inexpensive Embedded linux Board that is capable of streaming images back tot he PC for processing and receiving commands via a Virtual (WiFi) COMM port that are relayed from the PC to the Robot OTA.

This is designed to create a closed loop system using the very user Friendly Roborealm which can be used to create Vision-Enabled behaviours (following a ball, looking for a mark, navigating the environment).

I am also personally keen to try out scripting languages onboard such as LUA or Python that can be used to create more elaborate autonomous programming directly on the robot (without using the PC)

Linuxified is designed with a specific commercial approach but with some imagination the potential of this framework goes well beyond that.

Regards
Pedro.

[ParanoidAndroid]

Hello,

That's very interesting, thank you for the information, could come in handy very soon for me.

I have a couple of questions:

1) Presumably, in time, you could do the image processing on-board using OpenCV instead of relaying to a Windows PC to use RoboRealm?

2) How exactly are you physically connecting to the wCK bus? Are you hacking/soldering one of the wCK twisted module cables or do you have access to some female connecors? If so, where can I get hold of them?

I was myself thinking of possibly porting the .NET comms libraries over to Python but I've only just begun with the electronics side of things so it might be a while till I get to it...

[PedroR]

1) Presumably, in time, you could do the image processing on-board using OpenCV instead of relaying to a Windows PC to use RoboRealm?

Yes it is definitelly possible to do the image processing onboard. What happens with this particular project is that the board we're using is based on a RALINK RT3050F chip which does not have enough horsepower to do OpenCV.

If you use other boards such as an eBox or a BeagleBoard (or BeagleBone) you can definitely do the image processing onboard.

2) How exactly are you physically connecting to the wCK bus? Are you hacking/soldering one of the wCK twisted module cables or do you have access to some female connecors? If so, where can I get hold of them?

The approach we chose to use was to retain the RBC controller and connect the Serial pins to RX and TX on the Bluetooth connector.
In the end we chose not to connect directly to the wCK bus.

There are a number of reasons to retain the RBC controller as it takes care of a number of useful functionalities:
- It serves as a Bus a hub to connect different chains of servos

- It manages power and battery (and automatically selects which poer source to use)

- It has sensors attached to it (Acceleration, Distance, Sound) that we want to be able to reuse and can be queried via the RBC Serial protocol

- The RBC protocol also offers additional features such as the ability to run pre recorded motions and standard motions.

- Finally our board has a COMM at TTL level (3.3V) which is a direct match to the Bluetooth COMM port on the RBC board 8so no need for level shifters or additional hardware).

- We also use one Servo cable (that we stripped down to expose only the Vdd and GND pins) to power our Voltage regulator that in turn powers the board. This is optional (ideally you would power your controller with a dedicated battery but for the sake of simplicity this the approach we chose and saves us a lot of hassle and hardware)


There is a large room for debate whether or not to retain the RBC controller board. In our case it made a lot of sense as it saved us a great deal of work.
In the end the RX and TX pins on our RALINK board connected directly to RX and TX of the BT socket on the RBC controller. Minimal soldering was only required to get the Power to the board.



Now for the advanced topic part:

If you really want to go Pro on this approach and retain the RBC controller I would recommend using an alternative firmware by l3v3rz.
His (excellent) DCMP firmware loads into the RBC controller and offers a direct bridge from the Serial port and BT socket to the wCK bus.
The firmware can be downloaded here http://code.google.com/p/robobuilderlib/wiki/DCMP (the wiki page is very well written and you grasp the the idea of how it works very quickly and thoroughly)

All packets follow the protocol/format of packets to the wCK bus and additional, great features, are included:

- emulates a special servo ID (30 I believe) where you can query all the sensors.

- includes extended ids to implement different I2C devices on the I2C port.
This means that if you want to remove the simple Acc Sensor and replace it with a more sophisticated IMU (such as this one http://robosavvy.com/store/product_info ... ts_id/1247) you can do it.
Just solder on the I2C port in place of the Accelerometer and the special firmware includes the necessary commands to "speak" to any I2C device.


For our application we haven't yet decided which firmware we'll use but as of right now, but it looks like we'll be sticking with the default one from Robobuilder.
The reasons for this are mostly of a commercial nature: ie our target audience are customers who aren't necessarily too technical and thus we're trying to stay within the default set up as much as possible.

It doesn't mean we won't be playing with this firmware internally for other possible applications though.


As a final note, in case you wish to port the application 8including OpenCV) to an onboard processor using eBox or beaglebone (or any other), the way to connect the board to the RBC controller is to use a USB to TTL converter (3.3V) (such as this one http://robosavvy.com/store/product_info ... ts_id/1297) and connect the USB to the "brain" and a couple of jumper wires to RX and TX on the BT socket.
The USB to Serial converter will create a Virtual COMM port on the PC so your code should run without the need for any modification.


If you have any additional questions or would like to brainstorm some more ideas, let me know as I'd be happy to help!

[ParanoidAndroid]

Hi, thanks for your feedback.

You make a good case for using the RBC Controller instead of going with another solution in many cases.

To clarify, in the future, if I want to connect an embedded Linux board to the RBC controller, you suggest the USB->TTL->RX/TX on Bluetooth socket solution.

However, can you explain why it is not feasible to use the RoboBuilder-supplied serial cable that plugs straight into the RBC controller? i.e. by putting a serial port on the Linux board to connect the cable to.

RE: DCMP firmware

This is definitely something I had studied and was planning to make use of - perhaps with some additional enhancements. Still, I'm a long way from looking at that too but thanks for the reminder.

Back to your initial post, on 1) Is it possible that the firmware on the wCK servo modules simply ignores <5V signals? If it is firmware then this could potentially be rectified right?

I would still like to see if I can connect wCK servos directly to a PC using a USB to FTDI cable for situations where using the RBC controller is really not needed/wanted in the setup e.g. a simple 2 servo tilt/pan arrangement.

But, according to your first post, I can't use the USB to TTL converter because the 3.3V signals will be ignored....so what's the solution?

PS.

I think i-Bot located suitable headers for the wCK cables here:
http://robosavvy.com/forum/viewtopic.php?t=2705

[PedroR]

To clarify, in the future, if I want to connect an embedded Linux board to the RBC controller, you suggest the USB->TTL->RX/TX on Bluetooth socket solution.

However, can you explain why it is not feasible to use the RoboBuilder supplied serial cable that plugs straight into the RBC controller? i.e. by putting a serial port on the Linux board to connect the cable to.

It is definitely feasible to use the supplied Serial Cable as well.

The reason to use the BT socket + TTL converter is just size: in case your app doesn't have a native DB9 port, using a USB to TTL converter is usually a smaller and lighter setup compared to using bulkier USB to DB9 adapters.

In any case both solutions are possible and produce exactly the same result.

Back to your initial post, on 1) Is it possible that the firmware on the wCK servo modules simply ignores <5V signals? If it is firmware then this could potentially be rectified right?

I would still like to see if I can connect wCK servos directly to a PC using a USB to FTDI cable for situations where using the RBC controller is really not needed/wanted in the setup e.g. a simple 2 servo tilt/pan arrangement.

But, according to your first post, I can't use the USB to TTL converter because the 3.3V signals will be ignored....so what's the solution?

The reason for not detecting <5V signals is probably hardware related.

In any case and just to clarify it is possible to communicate directly with the wCK bus/servos using a USB to TTL adapter.

You just need to pay attention when selecting the model: Make sure you purchase one that outputs TTL levels at 5V.

What I attempted to explain in the first post is:

1) The Robobuilder servos are not like most 5V TTL devices that can detect 3.3V logic.
In the case of Robobuilder servos/wck bus you REALLY need to be using 5V TTL signals for the commands to be received.

2) As a consequence of 1) you need to be careful when choosing your USb to TTL adapter because those advertised as "compatible with both 3.3V and 5V TTL logic probably won't work; it doesn't mean it's impossible to talk directly to the servos.

What you'll need is something like this http://robosavvy.com/store/product_info ... ts_id/1296 that specifically "speaks" at 5V.

With this you can definitely talk directly from the PC to the servos without needing the RBC controller.

Pedro

[ParanoidAndroid]

In any case both solutions are possible and produce exactly the same result.

OK, thanks.

You just need to pay attention when selecting the model: Make sure you purchase one that outputs TTL levels at 5V.

Thanks, I figured that out just after I posted!

What I attempted to explain in the first post is:

1) The Robobuilder servos are not like most 5V TTL devices that can detect 3.3V logic.
In the case of Robobuilder servos/wck bus you REALLY need to be using 5V TTL signals for the commands to be received.

Understood. Should be interesting playing around with these servos. Seem to have a lot of advantages over other comparable servos if you don't need higher torques.

[i-Bot]

For the wCK connectors, I have used the headers and connectors from Tyco with success. The pins are a pain to crimp and expensive, so I still prefer to cut a long ready made cable. It is easy to use the headers on a small PCB, but they are not 0.1" pitch, so will not fit on perf board.

I used 5V FTDI direct to the wCK bus without problems. FTDI chips can be linked for 3.3V or 5V I/O and some boards allow this to be changed or specified at purchase. I never got the wCK bus to work error free with any driver at 921.6K, but no problem at 460.8K. The wCK bus is 5V CMOS, not 5V TTL so Vin high minimum should be 0.6Vcc (3.0V), maybe the 3.3V high drive from the Linux board is a bit low.

I didn't use the RBC in my configuration because the gait engine (DARwin), and my interpolation of the Robobuilder moves were done on Linux board anyway and I didn't want the added latency of the RBC.

[ParanoidAndroid]

For the wCK connectors, I have used the headers and connectors from Tyco with success. The pins are a pain to crimp and expensive, so I still prefer to cut a long ready made cable. It is easy to use the headers on a small PCB, but they are not 0.1" pitch, so will not fit on perf board.

Thanks for the heads-up.

I used 5V FTDI direct to the wCK bus without problems. FTDI chips can be linked for 3.3V or 5V I/O and some boards allow this to be changed or specified at purchase. I never got the wCK bus to work error free with any driver at 921.6K, but no problem at 460.8K. The wCK bus is 5V CMOS, not 5V TTL so Vin high minimum should be 0.6Vcc (3.0V), maybe the 3.3V high drive from the Linux board is a bit low.

That would explain it. From Wikipedia:

The CMOS–TTL logic level problem
Interconnecting any two logic families often required special techniques such as additional pull-up resistors, or purpose-built interface circuits, since the logic families may use different voltage levels to represent 1 and 0 states, and may have other interface requirements only met within the logic family.
TTL logic levels are different from those of CMOS – generally a TTL output does not rise high enough to be reliably recognized as a logic 1 by a CMOS input. This problem was solved by the invention of the 74HCT family of devices that uses CMOS technology but TTL input logic levels. These devices only work with a 5V power supply. They form a replacement for TTL, although HCT is slower than original TTL (HC logic has about the same speed as original TTL).

This is also interesting: http://www.interfacebus.com/voltage_threshold.html

I didn't use the RBC in my configuration because the gait engine (DARwin), and my interpolation of the Robobuilder moves were done on Linux board anyway and I didn't want the added latency of the RBC.

Interesting. I'll have to see if the latency is going to be an issue for me or whether the benefits outweigh the disadvantages.

[PedroR]

The wCK bus is 5V CMOS, not 5V TTL so Vin high minimum should be 0.6Vcc (3.0V), maybe the 3.3V high drive from the Linux board is a bit low.

Hi i-Bot

Interesting piece of information that we were not aware of.

Thank you for the heads up and as you say it probably explains it.

Regards
Pedro

[l3v3rz]

This looks a really cool project ! I got my miniEmbwifi for Xmas. Its a real shame the RBC box isn't just a few mm deeper other wise it would have been a perfect fit. I'd be interested to try one of your white boxes. Power from the wck Bus is a great idea - does it still need voltage reg or is direct connect?

Thanks for the nice words about DCMP. One un-documented is it can run at 230Kbs rather than 115Kbs by booting and holding down PF1 (I think). This only affects comms between PC/board and RBC not RBC and servos, but will cut down latency

Just thought, I'm not an electrical engineer - but don't you need to also connect the earths together as well as RX and TX?? - the floating earths could explain your problem with detecting smaller 3.3v signal.

I have also built by linux version of Basic - which talks to DCMP - as an OpenWRT package and that runs fine on minEmb. I'd really like to get Octave (language favoured by Stanford and Andrew Ng) as I have a Otcave plugin that talks to DCMP as well.

cheers

[i-Bot]

I am interested to hear how well Ocatve works on miniEmbwifi. I think the RT3050 does not have a hardware fpu, and Octave uses fp for most calculations. I did not find Lua worked very well on the miniEMBwifi and assumed that was due to the lack of fpu.

[PedroR]

One un-documented is it can run at 230Kbs rather than 115Kbs by booting and holding down PF1 (I think). This only affects comms between PC/board and RBC not RBC and servos, but will cut down latency

Thanks for the tip
Unfortunately afaik the Omnima Serial port will only go up to 115kbps so we are unable to take advantage of that for the time being...

Its a real shame the RBC box isn't just a few mm deeper other wise it would have been a perfect fit. I'd be interested to try one of your white boxes. Power from the wck Bus is a great idea - does it still need voltage reg or is direct connect?

Now that the 3d design for the RBC + Omnima case has been finalized (we finally sorted out all the minor tweaks last week) we'd be happy to send you one for Beta Testing. I will ask Marco to print one and for you and have it shipped.
They're still being printed in white as it's the cheapest plastic we have so it's ideal for mock ups. The final version should be either Black, Translucent (PLA) or maybe Red; it's still unknown but we're open to suggestions
My personal favourite would be Translucent PLA but PLA doesn't behave as well as ABS...

With regards to Powering, we still need to use a regulator to power the Omnima.
Although the Omnima could take the 8.4V directly from the wCK bus, power to USB peripherals is unregulated so the board would survive but we'd kill any USB device we attempted to connect to the board.

What we do is: wCK cable (just with Vdd and GND from the wCK bus) -------> 5V Voltage Regulator -----> Omnima Board

The 5V voltage regulators we use are typically UBECs. These come from RC world I think, they're quite cheap, and can typically take up to 15V and output a stable 5V 2A-3A.
(an ebay search for UBEC should show you the light )

I think the RT3050 does not have a hardware fpu, and Octave uses fp for most calculations. I did not find Lua worked very well on the miniEMBwifi and assumed that was due to the lack of fpu.

Again afaik there is no FPU on the RALINK but since it's a very specialized chip I'm not sure what kind of optimizations may be in there (or missing).

Our biggest challenge with scripting languages on the Omnima is the ROM size though.

RAM is 32Mb but permanent storage (ROM) is only 8Mb out of which ~3.2Mb are used by the OpenWRT installation.

We tried installing Python (and managed to do so) but little to no space was left after installing. The solution on the Omnima is to use a USB thumb drive to add usb external storage.

We also have another product in our Lab based on the same RALINK RT3050 chip called Carambola: http://www.8devices.com/product/3/wi-fi-4-things
Carambola comes as a single module that breaks out all the processor pins.

This has good things and bad things:
- We can access the 2x COMM ports: one can be kept for console and the second one is free (and clean) to communicate with other peripherals.
The Omnima only exposes 1 UART and even if you detach the console there's still garbage coming out when booting (bootloader messages and similar boot information).
After booting the UART is free though.

- We can access the SPI pins on Carambola which means - in theory - we can attach an SD card slot and mount an SD card as filesystem to extend storage capacity.
There is some support in OpenWRT to do this but on Carambola there seem to be issues still (also performance seems to be significantly impacted depending on the driver and approach used)

- A major upside is that the WiFi Antenna is a Chip Antenna. For a mobile application - and if you don't require huge coverage - this is very good. The bulky antenna on the Omnima really gets in the way, especially on a humanoid (on Robobuilder for example it reduces some of the mobility on one of the Shoulders).

- The downside though is that Carambola is only a kind of "breakout board" for the RT3050 and you can't really do anything very useful unless you develop your own custom PCB.
The unsorted issues with mounting an SD card using SPI are also a downside at the moment still.

For these reasons we're continuing development and supporting the RALINK implementation on the Omnima but we're keeping an eye out for developments around Carambola.

Pedro.

[MarcoP]

Hi l3v3rz

Just to clarify things, when we were doing the tests we had a common ground between the RBC and the converter.

Will check the levels more closely to confirm the TTL/CMOS issue.

I will be preparing the kit to send to you. Planning on modifying a wCK cable to splice off power to a 5V regulator to power the Omnima

Regards

[l3v3rz]

That's great thanks!

Got a cheap webcam working with it this weekend (Just £3.90 inc P&P!!) - connects using UVC and works with mjpg streamer with -y option

http://www.ebay.co.uk/itm/290653852233? ... 189wt_1137

Also tried to build octave but got stuck at the moment with libfortran. I'm sure its surmountable - just need to find the right sources.

One problem I have is that udhcpc always freezes and never detects my network - using ethernet at moment with static IP. I would like to go wireless and have the card connect to my local wifi homehub and use dhcp to get an IP address, any tips on what setup to use ??


cheers

[PedroR]

Hi l3v3rz

We posted a firmware image here http://robosavvy.com/RoboSavvyPages/Omn ... Firmwares/ that includes the latest Luci configuration interface.

It offers a very neat (graphical) way to set up all the interfaces including WAN connection as client to a home network. It also offers a Graphical view to opkg and HDD usage.
(Luci should be available by pointing your web browser to the board's IP address).

The latest batch we got from Omnima should have come preloaded with this but in any case users can download and flash the image themselves.

The image was built specifically for the Linuxified project so it includes the necessary kernel subcomponents to install UVC (not sure if it's pre installed already) as well as mjpeg streamer and python.

It also includes the latest Luci which offers that Graphical configuration interface (I believe you just need to connect tot he board over Ethernet and open the board's IP on your browser).
The only bit I don't recall is if you need to set your LAN to a static IP address (and which) or if it will automatically assign one. (I think you need to set your PC manually to 192.168.1.40 for example and then try http://192.168.1.1 or 192.168.1.254). -- let us know how this goes!

As a side note, we've 3D printed a box to send you and also included a wCk cable already soldered to the Voltage Regulator and witha DC barrel jack on the other so you can power the omnima directly from any connector on the wCK bus. (we should be shipping it to you in a couple of days as this is in the Lab not the WH)

We've made another set for ourselves and I'll post some pictures tomorrow about this.
It's a very neat approach for Power Supply. no hassle with batteries or anything; you can even hotplug and unplug the Wall Adapter if the battery is low and the Omnima will just keep running.

Regards
Pedro.