RoboRealm & SSC-32

[sn96]

I have been playing around with RoboRealm’s software and I am able to get a servo to move in response to an object, but then I just realized that you need the SSC-32 for other servos as well, such as for walking.

If the SSC-32 is hooked up to the PC with RoboRealm sending commands, I won’t be able to send commands from the bot board to the SSC-32 since it is connected via the serial port. The only solution I can think of is to use another SSC-32 for just walking, but then how would you communicate between the first and second SSC-32 to respond to the video? You would want the bot to move to track a moving object.

For a rover it would be ok since you can use a speed controller to move the bot left or right, but for a legged bot, a camera servo is needed as well as the other servos for walking controlled from the same board.

Anyone have any ideas?

In the mean time, here is a VBScript that I modified to work with a pan and tilt servo. Min and Max servo movements sould be adjusted per the users configuration:

NOTE: The VBScript Pipeline should be placed above the SSC-32 pipeline.

' first check that something moving is in view
if GetVariable("COG_BOX_SIZE") > 10 then

  ' get the current screen width so we can calibrate movement 
  width = GetVariable("IMAGE_WIDTH")
  height = GetVariable("IMAGE_HEIGHT")

  ' get the current center of movement
  x = GetVariable("COG_X")
  y = GetVariable("COG_Y")

  ' scale the image space into the servo space
  x = CInt(((x/width)*2000))+500
  y = CInt(((y/height)*2000))+500

  ' set the variable for use in the servo controller
  SetVariable "servo_position_x", x
  SetVariable "servo_position_y", y

end if

[linuxguy]

@SN96

If the SSC-32 is hooked up to the PC with RoboRealm sending commands, I won’t be able to send commands from the bot board to the SSC-32 since it is connected via the serial port. The only solution I can think of is to use another SSC-32 for just walking, but then how would you communicate between the first and second SSC-32 to respond to the video? You would want the bot to move to track a moving object.

This is exactly the kind of problem a microcontroller can solve. I would have RoboRealm send commands to the MCU (on a mini-ABB or other board) via serial connection (including wireless) and let the MCU pass those commands directly to the SSC-32. Then the MCU can make decisions based on sensor inputs as well as handle sending other servo commands for walking, controlling motors, etc to the SSC-32 directly. I can visualize the program structure for this sort of setup. The MCU could be anything a person is comfortable working with.

All of this is using a single SSC-32.

8-Dale

[sn96]

So the bot board can recieve RS232 signals and still work like normal? Dale, could you provide a quick few lines of Mbasic code that would handle signals recieved from the RS232 interface?

This opens many doors if this will work.

[linuxguy]

@SN96

So the bot board can recieve RS232 signals and still work like normal?

I don’t know about the Basic Atom, but certainly the Atom PRO could handle this using its hardware serial port.

@SN96

Dale, could you provide a quick few lines of Mbasic code that would handle signals recieved from the RS232 interface?

I wish I could, but I have not yet actually used the additional serial ports or serial I/O of the Atoms other than for serout to S_OUT for debugging.

@SN96

This opens many doors if this will work.

I don’t see any reason why this sort of setup would not work though, especially with the Atom PRO. I merely present what I think is a good idea and way to implement what you want to do. It should be a matter of using HSERIN (for the Atom PRO) or plain SERIN (either Basic Atom or Atom PRO) to grab data from the serial port pin(s).

As soon as I get W.A.L.T.E.R. running around again, and get some experience with PICs, I am going to add a wireless connection between him and my main PC. Then I can start testing out some of these ideas of mine. It just takes me longer to get where I want to be due to very limited funds for leisure activities. This are improving though, since I believe I now have my Alibre Design Expert paid for in full, which will leave more money for toys and such.

8-Dale

[kurte]

@SN96

So the bot board can recieve RS232 signals and still work like normal? Dale, could you provide a quick few lines of Mbasic code that would handle signals recieved from the RS232 interface?

This opens many doors if this will work.

Yes like linuxguy said, you could use the Atom better yet pro to receive RS232 signals. However you do have a couple of problems/approaches.

If you use the normal I/O pins and Serin/serout commands including S_IN and S_OUT. you can only receive serial data when you are actually in the serin command. So if you try to send data from the PC and your code on the ABB is not in the serin command, the data will not be received. If you can use the hardware serial port pins and support than this is taken care of for you. They keep a FIFO queue of the received characters and so unless your program is slow to query for characters you should not lose any data.

If you use S_IN and S_OUT to communicate with your PC then you can directly receive RS232 level signals from the PC. However all of the other pins (including the hardware serial ports )are TTL level signals so you will need something like a MAX232 chip between the two to do the level shifting.

One nice way to get the best of both worlds is to hook up something like a Bluesmirf up to the hardware serial port and then you don’t need the cable between your PC and m ABB board (except when you are reprogamming it).

Sorry for rambling on here.

[linuxguy]

@kurte

One nice way to get the best of both worlds is to hook up something like a Bluesmirf up to the hardware serial port and then you don’t need the cable between your PC and m ABB board (except when you are reprogamming it).

Remember that Bluetooth is designed to be a Serial Cable Replacement. A cable should not be needed even when programming if there is a Bluetooth link on the main serial port between the bot board and the PC.

8-Dale

[sn96]

I was thinking of using a blue smirf for this operation and I would not need a constant link to the PC, although it would be nice to have a constant flow of data to react to any changes, it is just easier for me to create a S_IN routine to use vision at key times. For example have the bot walk a small distance, stop, then use it’s camera to make a decision for its next move.

I appreciate everyone’s help on this. I understand the concept but writing code to make it all come together is going to be a challenge.

[sn96]

I looked in the AtomPRO manual and found no documentation for the use of S_IN. I looked at the Stamp Manual and it has a SERIN command that handles RS232 communications with tons of information and some code examples. It looks like I may be using the BS2px for the vision project.

For now I am going to use the AtomPRO until I am ready for vision control.

[kurte]

@SN96

I was thinking of using a blue smirf for this operation and I would not need a constant link to the PC, although it would be nice to have a constant flow of data to react to any changes, it is just easier for me to create a S_IN routine to use vision at key times. For example have the bot walk a small distance, stop, then use it’s camera to make a decision for its next move.

Yes the Blue smirf type is nice as it gets rid of the wire. Also using the regular blue smif is easy to hook up to the hardware serial port as it wants TTL level signals. Hooking it up to S_IN is more difficult as S_IN is RS232 level signals and so you would need to convert these back to TTL first. They do make a bluetooth RS232 dongle, which if you could make it work would allow you to connect it up to the 9 pin connection. You need a gender bender and maybe a null modem connection. Also you need to hack up a mini USB cable to get +5V and GND and connect RTS to CTS… (don’t want to hijak here). Short answer I have not gotten this to work yet…

@SN96

I appreciate everyone’s help on this. I understand the concept but writing code to make it all come together is going to be a challenge.

Your welcome. With any of these type issues, it is easier to break down the problem into smaller chunks and try to solve these into solvable issues. For example one starting point would be to try to transparently hook up RoboRelm to the SSC32 through the Atom Pro, using the bluesmirf hooked up to the hardware serial port. One direction from PC to SSC32 should be somewhat easy… You could have some code that looks something like: (Note, this is not complete, compilable, … code)

bPC var byte
SSCP_OUT con P?

    sethserial h9600, h8databits, hnoparity, h1stopbits

main
    ...
    gosub CheckForDataFromPC
    ...
    goto main
...
CheckForDataFromPC
    hserin 1, CFDTimeout, [bPC]
    serout SSCP_OUT, SSCBaud, [bPC]
    goto CheckForDataFromPC    ; continue to echo all that is queued up...
CFDTimeout
     return

Assuming that after any debugging you can get this to work ok, then you might want to add some more smarts into the CheckForDataFromPC function to know what is going on. So you might start loooking for different sentances by first locating the start and end of sentences. One use for this may be if your PC program needs to query the SSC for anything. In this case you might start looking for the “Q” commands. If you detect one you could then do a serin from the second port connected between your ABB and SSC32 boards with a longer timerout and then use the HSEROUT function to relay this information back…

As I said this is just one possible starting point… Another way with out HSERIN and bluetooth and to like using standard S_IN and S_OUT is to have your PC program wait for a prompt from the ABB before it tries to download any information to the ABB. Then the code for this may look something like:

bPC var byte
SSCP_OUT con P?
SIN_TIMEOUTL con ???
SIN_TIMEOUTS con ???
main
    ...
    gosub CheckForDataFromPC
    ...
    goto main
...
CheckForDataFromPC
    serout S_OUT, "$"]        ; tell PC we are ready for data (may need cr?)
    serin S_IN, SIN_TIMEOUTL, CFDTimeout, [bPC]
CFDLoop
    serout SSCP_OUT, SSCBaud, [bPC]
    serin S_IN, SIN_TIMEOUTS, CFDTimeout, [bPC]  ;echo others shorter wait
    goto CFDLoop
    
CFDTimeout
     return

Again I am not sure if this helps and Good luck.

Kurt

[kurte]

@SN96

I looked in the AtomPRO manual and found no documentation for the use of S_IN.

There is really nothing special about the usage of S_IN and S_OUT. Other than knowing that they are connected to the 9 pin connector an the AAB board Likewise if you plug in a BS2 into the AAB board. The main difference between the S_IN/S_OUT pins versus other pins is that these signals are in RS232 levels versus TTL levels (Again same as BS2).

Earlier I did code for my TV brat that I had a VB program on the PC to allow me to do some sequencing and download this information to my brat using S_IN and S_OUT. I have not tried out this code in awhile (since Vista and 8.0.1.0) as I am still in the process of ironing out a few other kinks but I could share this code with you if you think it would help…

[sn96]

Thanks kurte,

I did find information in my printed manual for the AtomPRO S_IN command. For some reason, when I clicked on “HELP” within the IDE, and ran a word search for “S_IN” it came up with only one result?

Anyway, I need to try to write a simple S_IN program and see If I can write the results out to the Debug screen and see what the data looks like.

I look forward to seeing your code when ever you have time.

[eddieb]

my recollection is that these are bit-banged seial lines and if you are not actively listening to S_IN you will not get the data, or if you start listening asynchronously you will get part of the data. also important to note is that if you have a hardware function like hservo running it can corrupt the bit-banged output going to S_OUT as well as the data comming from S_IN. this (the S_IN) part is why I was on about adding a DTR output handshake line option to the ABB so you could set it active and let a host know whether you were sitting in the serialin routine waiting for data or not.

[kurte]

I sent you an email with the code and VB parts. I am not sure if they will all make it through.

If I were to update my sample code from a few emails ago that uses S_IN, to make it more robust, I would probably not receive one character at a time. I would probably set up some form of packet and either have some form of ack/nak response…

[kurte]

@EddieB

my recollection is that these are bit-banged seial lines and if you are not actively listening to S_IN you will not get the data, or if you start listening asynchronously you will get part of the data. also important to note is that if you have a hardware function like hservo running it can corrupt the bit-banged output going to S_OUT as well as the data comming from S_IN.

Yep on both cases. That is why in my example possible code using S_IN I recommended having the PRO post something to the PC saying I am ready and then go directly into an serin of S_IN. I would also recommend some form of fixed size packet with some form of handshake…

As for hservo, yes I have had problems with it screwing up the bit bang functions. This has gotten worse on 8.0.1, but AcidTech is working on it and hopefully he will have a fix for most of it very soon. But that is another topic…

[sn96]

I found out that all I would need is a blue smirf to communicate between roborealm and the BS2px. I would not have it communicate with the SSC-32, instead, I will have it send values to the stamp and the stamp will send the proper sequences to the SSC-32 based off those values.