First of all, I’m very new to this robotics thing.
I have a BAP 28 hooked up to an SSC-32 via pin 10/11. And I have a PS-2 controller hooked up via pin 12-15 in the typical T-HEX configuration.
But although I find it kind of cool to drive the T-HEX around with a PS-2 controller, my real goal is autonomous motion. So I have a Pico-ITX PC on its way… and here I run into some questions about how to hook a Pico-ITX to control servos (especially with the configuration I already have). So you forum purists shouldn’t say “this belongs to the multi-leg forum”–since the question is really the best method to drive the BAP 28/SSC configuration.
I had two approaches I could take:
(1) I initially thought to forgo the BAP 28 altogether and hook the Pico-ITX directly to the SSC-32. I’ve already written some Java code to control the individual servos–but when I started looking at the inverse kinematics problem, it made my head hurt. It then occurred to me that the T-HEX already came with phoenix code and IK code designed for use with the PS-2 controller so I thought:
(2) Connect the Pico-ITX to the BAP-28 and send serial commands to mimic the commands possible from the PS-2 controller. But I know very little, really, about how to do this.
So since I’m pursuing #2 initially, here’s my question: can I just hook the Pico-ITX serial port to say, Pins 6/7? I suspect that the inputs need to be TTL, so I’d need an RS-232 level converter, right? But generally, would this approach work?
Once the hardware, is communicating, then all I’d really need to do is modify the code:
Gosub ControlInput
To read:
Gosub ControlInput
Gosub ITXInput
(and then provide the code for ITXInput). And that should work, right?
There are probably lots of different approaches you could take.
For example you could for example look at the Beta of the Phoenix 2.1 code that I uploaded earlier today. In particular the T-Hex Serial configuration. This allows you to download serial commands that are in the same format as PS2 data, to control the robot. Note: So far for this version I only made the basics of it work again and have not merged in all of the updates that were put into the PS2 version.
This Control is setup to take input commands from the S_IN/S_OUT (the ones connected to the DB9 connector and are RS232 level signals). It would not be hard to convert the code to other IO pins instead, which are TTL level.
There are issues with all of these pins, in that they are doing this without hardware support. What that implies is that unless you are sitting in a serin command, the data will be lost. There are a couple of different ways to deal with this.
On S_IN - I have hacked this before, where I believe the IO pin is on the IO pin which can generate an interrupt (IRQ0 if I remember correctly). My code was set up to handle this and then quickly get into a serin. The other side had to send a special character (don’t remember if I used 00 or 0xff…), then it would pause a bit and then it would do the output… Not great but…
If you can set up the pico-itx to use a flow control pin to control when it outputs data. See the \fpin option under SERIN command. Note: Issues with this as well. For example if you try to use the flow control with XBees, when the BAP signals that it is done, the XBee may send up to 2 more characters, which would be lost…
Roll your own. If you can connect an IO pin from the BAP to Pico, then you can have the BAP raise the signal when it wants data…
use the Hardware serial port on the BAP. On the Bap28 this is IO pins 14 and 15. This will require you to use the HSERIAL commands like HSERIN instead of SERIN. The plus of this is that the input is buffered by the BAP, so you simply need to read it when you need it… This is what the DIY XBee versions of ControlInput does. However there are issues here as well. If you wish to use the PS2 as well, than it can not be on pins 12-15. There is code in the PS2 control driver to allow for a few different IO pin configurations, where it tries to enable a weak pull up resistor on the DAT pin. My T-HEX was using Pins 16-19 until this morning where I moved them back to default configuration. In some cases the weak PU is not good enough and you need to add an external PU… 2nd issue. Hardware serial port generates interrupts. These interrupts can corrupt the serial output to the SSC-32. There are calls in place that allows the main code to tell the control input that it does not wish to have any interrupt happen when the main code is outputting to the SSC-32. Again this is used by the XBee version of the code.
…
