Is this what you mean?

 

from jarray import array
from java.lang import String
from java.lang import Class
from org.myrobotlab.service import Logging
from org.myrobotlab.service import Runtime
from org.myrobotlab.framework import Message
from org.myrobotlab.service import Roomba

roomba = Runtime.createAndStart("roomba","Roomba")
logging = Runtime.createAndStart("logger","Logging")

roomba.send("myApp","receive_method", "goForward", 10)

 

We are stillhaving issues with the number of commands that can be sent. Currently, only 18 commands are being executed, even though there are many more in the code... Hoping you might have some ideas for debugging, etc.

The concept is to Make a Simulated Roomba move in a asterisk shape. The roomba is getting commands from the Jython code. The roomba will drive down 1 arm of the askerisk, stop,  then spin 180 degrees, stop, then drive back to the origin, stop, and spin in place to do the next arm of the asterisk. A link to a youtube video is on the way.

The origin is set at (24.77, 46.8) ie, (x, y) in meters. The simulated roomba is getting these measurments from the simulated GPS (which is pinpoint accurate).

Jeff is going to add to the problem description (and we'll have a video showing the problem soon).

So far we;'ve been using 14.6 and 14.8. But 14.9 looks cool, can't wait to test it out.

 

--Adam

Jython is below:

from org.myrobotlab.service import Logging
from org.myrobotlab.service import RemoteAdapter
from org.myrobotlab.service import Roomba
from org.myrobotlab.service import Runtime
from org.myrobotlab.framework import Message
from org.myrobotlab.framework import Service
from java.lang import Math
from time import sleep
from array import *

#setting up the services
remote01 = Runtime.createAndStart("remote01","RemoteAdapter")
log01 = Runtime.createAndStart("log01","Logging")
jython = Runtime.createAndStart("jython","Jython")
roomba = Runtime.createAndStart("roomba","Roomba")

#sleep for 7 seconds, enough for the jME to load and start running
sleep(7)

#arrays of (x,y) locations.  Starting location is approx. (24.77, 46.8),
#the robot will travel from the starting location to the (x,y) pairs below.
#'f' means float format, [...] is the list of points
xLocs = array('f', [26.77, 24.77, 26.18, 24.77, 24.77, 24.77, 23.36, 24.77, 22.77, 24.77, 23.36, 24.77, 24.77, 24.77, 26.18, 24.77])
yLocs = array('f', [46.8, 46.8, 48.214, 46.8, 48.8, 46.8, 48.214, 46.8, 46.8, 46.8, 45.386, 46.8, 44.8, 46.8, 43.386, 46.8])

#empty arrays of length corresponding to the number of points.
#[None] means the values are initially empty and len(xLocs)
#means the length of the xLocs array.
#turnAng is the angle the robot will need to turn.
#ang is the current robot angle 
turnAng = [None]*len(xLocs)
ang = [None]*len(xLocs)

#converting radians to degrees
CONV_TO_DEG = 180/Math.PI

#beginning of jython program.  roomba.send sends a message
#to the "myApp" object of MRLClient invoking the "getInfo"
#string conditional in MRLClient's implemented "receive" method.
#"getInfo" invokes the jython function "input" defined below,
#passing the Roomba App's current latitude, longitude,
#compass direction, and odometer reading
roomba.send("myApp","receive", "getInfo")

#input function invoked by MRLClient upon receiving "getInfo"
def input():
    #the process below must be repeated for each (x,y) location
    for t in range(0,len(xLocs)):     
        if (t == 0):
            # data coming into the Jython service can be accessed
            #using msg_<serviceName>_<sendingMethod>.data[]
            # where data[] is the parameters for the method

            #(x,y) are the initial locations of the Roomba.  They
            #are converted from lat/lon to Cartesian coordinates
            x = (msg_myApp_send.data[0] - 40.652817)/.00000892 
            y = (-73.96545 - msg_myApp_send.data[1])/.000011       
        if (t > 0):
            #if (x,y) is not the inital conditions, they will be
            #the previous (x,y) pair
            x = xLocs[t - 1]
            y = yLocs[t - 1]

        #calculating distance the roomba must travel using standard distance formula.
        #(xLocs, yLocs) is the future position and (x,y) is the current position   
        dist = Math.sqrt((xLocs[t] - x)*(xLocs[t] - x) + (yLocs[t] - y)*(yLocs[t] - y))

    #calculating dx and dy based on the above coordinates.  Atan2 is not
    #supported by this package, so it must be implemented
        dx = (xLocs[t] - x)
        dy = (yLocs[t] - y)

        #Atan2 function.  Please consult an outside source for details if desired
        if (dx == 0):
            if (dy > 0):
                ang[t] = 90
            if (dy < 0):
                ang[t] = -90
        elif (dy == 0):
            if (dx > 0):
                ang[t] = 0
            if (dx < 0):
                ang[t] = 180           
        else:
            ang[t] = Math.atan(Math.abs(yLocs[t] - y)/Math.abs(xLocs[t] - x))*CONV_TO_DEG

        if ((dx < 0) & (dy > 0)):
            ang[t] = 180 - ang[t]
        elif ((dx < 0) & (dy < 0)):
            ang[t] = (180 - ang[t])*(-1)
        elif ((dx > 0) & (dy < 0)):
            ang[t] = (ang[t])*(-1)
        #end of Atan2 function      

        #initially, the turn angle is equal to the future angle (ang) minus the current
        #angle (msg_myApp_send.data[2])
        if (t == 0):
            turnAng[t] = ang[t] - msg_myApp_send.data[2]  
        #else, the turn angle is equal to the future angle (ang[t]) minues the current
        #angle (ang[t - 1])       
        if (t != 0):
            turnAng[t] = ang[t] - ang[t - 1]

        #keeping angles positive
        if (turnAng[t] < 0):
            turnAng[t] = turnAng[t] + 360   

        #the turn angle is calculated by measuring the counterclockwise
        #angle (spinLeft).  If the angle is less than 180, spinLeft is
        #called.  If the angle is greater than 180, spinRight is called
        #to spin (360 - turnAng[t]) degrees.  It is desired to spin
        #whichever way will be quickest
        if (turnAng[t] <= 180):
            roomba.send("myApp","receive", "spinLeft", turnAng[t])
        else:   
            roomba.send("myApp","receive", "spinRight", (360 - turnAng[t]))
        #after the roomba spins, it stops, goes forward dist meters, and
        #stops agin.  The loop repeats after the final "stop" command             
        roomba.send("myApp","receive", "stop", 0)
        roomba.send("myApp","receive", "goForward", dist)
        roomba.send("myApp","receive", "stop", 0)

 

So here is the graphical layout of what Jeff's code has been doing:

The reason the sensor data isn't being sent to the Jython is that we are trying to smulate the real hardware, and the real roomba doesn't send its odometer data to the jython when it has bee sent a "goForward(distance)" command.

It seems that the commands *might* be sending all at once (or rather in rapid succession like you said), and therefore might be getting queued all weird on the Client side. All of the commands are sent inside the Jython's input method. Basically, the Jython sends one message "roomba.send("myApp","receive", "getInfo")"  and when the simulator repies, the jython catches the reply in the input method. This synchs up the starting of the Simulator and the Jython code. From this point, the rest of the commands are sent from within the input method. The waypoints the robot will go to are already calculated and are inside the Jython code, so all of the messages are likely sending very quickly.

Since we can't seem to get the TCP working, and for some reason, Jeff's having issues with getting MRL 14.8 to work sometimes, We're switching back to using the 14.7 MRLClient,jar and MRL14.6. I've instructed him to attempt a call and response for each command between the Jython and the MRLClient. (I'm not sure if he will do it or not, he's trying to think of other ways to debug too).

In the call and response set-up, the waypoints would be treated as different states of a state machine. Each state will send the command required for that waypoint, then await a response from the client before sending the next command. That would mean completely refactoring his code, which is why I don't know if he will do it or not, but I honestly cannnot think of another way of doing it. It would look kind of like this:

 

How does the real roomba work? How do you know that a command has been finished before the next one executes?

 

Also, on a side note, we have a Roomba 500 series which doesn't seem to communicate with the MRL roomba serivice (wven when I create the service manually) Any tips?

--Adam

Your right about the TCP, there are some issue regarding maintaining and/or recreating a connection.  UDP being connectionless does not have to deal with those issues.  I'll look into it.

I started working with 14.8 to attempt to model your system, but I think the most expedient way to resolve issues would be for me to work in 14.9.  I'll begin to try to model your system with the Jython you've supplied so far.

In regards to debugging, the ./myrobotlab/myrobotlab.log is the target for all log4j - details can be adjusted through the gui or command line.  In 14.9 the log4j info is redirected to a Java console in the Jython view.  Feel free to attach a log if you have questions or want me to look at something specific.

A quick suggestion after looking at the script it appears the initial sequence could be split up.

You have the option to create another Jython Service which can run a different script.

 

First Jython service starts initializes everything and puts it in a listening state

# the start & listen program
from org.myrobotlab.service import Logging
from org.myrobotlab.service import RemoteAdapter
from org.myrobotlab.service import Runtime
from org.myrobotlab.framework import Message
from time import sleep

# start the system in a listening state
controller = Runtime.createAndStart("controller","Jython")
remote01 = Runtime.createAndStart("remote01","RemoteAdapter")
log01 = Runtime.createAndStart("log01","Logging")

Second Jython Service is the "controller" / state machine

# run the controll program
from org.myrobotlab.service import Runtime

controller = Runtime.createAndStart("controller","Jython")
controller.send("myApp","receive", "getInfo")

#input function invoked by MRLClient upon receiving "getInfo"
def input():
	x = msg_myApp_send.data[0] 
	print x

	#the turn angle is calculated by measuring the counterclockwise
	#angle (spinLeft).  If the angle is less than 180, spinLeft is
	#called.  If the angle is greater than 180, spinRight is called
	#to spin (360 - turnAng[t]) degrees.  It is desired to spin
	#whichever way will be quickest
	controller.send("myApp","receive", "spinLeft", x)
	controller.send("myApp","receive", "spinRight", x)
	#after the roomba spins, it stops, goes forward dist meters, and
	#stops agin.  The loop repeats after the final "stop" command             
	controller.send("myApp","receive", "stop", 0)
	controller.send("myApp","receive", "goForward", x)
	controller.send("myApp","receive", "stop", 0)

BTW - what Operating Systems are involved ?

Currently we are only using Windows 7. That's where KegFloater's work is being done. I haven't even attempted in mac or linux because I remember having serial port issues in mac.

As for the other code, KegFloater's refactoring the code now to be a FSM using switch/case that sends a command and waits for a "done" response before sending the next command. That should help us figure out at which point commands are being dropped.

 

I believe I have replicated the issue :

if UDP messages are sent in a tight loop then my Windows box will drop them..

I did the following loop in Java driving the MRL client - with a call back from MRL Jython running

 

Running TCP works currently (14.9) when going from MRLClient ---to----> MRL

I can send messages and they are received and processed, however, MRL --- replying ---> MRLClient is sending the messages UDP which is "default" behavior... 

Initially I made default MRL communication TCP, then switched to UDP when I did alot more video processing.  I think it makes sense really to "default" it to TCP then have some intelligent switching to switch based on datatype.

Hmm default TCP would be ok, but it really should be "talk back on whatever protocol was initially used from the contacting service".. which means adding a key .. yattah yattah

WooHoo, more stuff  !

Hello Kegfloater,

I'm in the middel of refactoring all of the networking in MRL.  It shouldn't take long.  Did you experiment with slowing the messages down from the simulator?

We are trying to interface with a real roomba now with no success. We have both 400 and 500-series robots. We've attempted to start from scratch manually creating a roomba service, then trying the "test" and "Control with Keyboard" buttons with no success. We can select the port correctly, but again, nothing happens afterward. Any tips on this?

 

 

Uploaded now - http://code.google.com/p/myrobotlab/downloads/list

Grrr......

Didn't get the Jython.jar in the first 14.9 upload ... is there now.

Hmm, obviously I need more unit & integration tests :P

I started the roomba service through the GUI, selected the correct com port and clicked "Test" and nothing happened. I clicked "click here for keyboard control" and nothing happened when I pressed any of the keys. The roombas (tried with both 400 and 500 series) do nothing, in fact, the serial cable never shoes anything download from the computer to the roomba any time I try to send commands. Am I missing a step somewhere?

Nothing I can think of - I hooked up the arrows buttons to (goForward, leftTurn, rightTurn, & stop)
Is your recieving com port on the Roomba the default - 57600 8 data 1 stop no parity ?
Can you attach or send me myrobotlab.og, it would help me considerably....

You have a light on the cable which shows activity?

 On the 400 series (Looks like this)

 

baud and parity are 8N1. There is no communication other than when the Roomba first starts up:

 

processor-sleep

key-wakeup 0000000000000001

slept for 9

9 minutes 283

 t2cks

004-09-21-1525-L   

battery-current-quiescent-raw 536  battery-current-zero 522

The 500 series has a different baud rate:  9N1 and I get the following when plugging it in:

bl-start

STR730

bootloader id: #x470A4D58 AD0BEFFF

bootloader info rev: #xF000

bootloader rev: #x0001

2007-05-14-1715-L   

Roomba by iRobot!

str730

2007-08-27-1705-L   

battery-current-zero 258

 

2007-08-27-1705-L   

AD0B EFFF

assembly: 3.3

revision: 0

flash version: 2

flash info crc passed: 1

 

battery-current-zero 258

saving bbox vars

 

bbox vars saved!

 

processor-sleep

charger-wakeup

slept for 0 minutes 1 seconds

 

2007-08-27-1705-L   

AD0B EFFF

assembly: 3.3

revision: 0

flash version: 2

flash info crc passed: 1

 

do-charging-checking-fets @ minutes 0

bat:   min 0  sec 31  mV 7291  mA 16  tenths-deg-C 229  mAH 0  

Charging FET test passed.

do-charging-wait-initial @ minutes 0

do-charging-recovery @ minutes 0

bat:   min 0  sec 32  mV 14055  mA 8  tenths-deg-C 228  mAH 0  

bat:   min 0  sec 33  mV 18619  mA 8  tenths-deg-C 228  mAH 0  

bat:   min 0  sec 34  mV 20317  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 35  mV 20929  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 36  mV 21152  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 37  mV 21235  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 38  mV 21263  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 39  mV 21291  mA 8  tenths-deg-C 227  mAH 0  

bat:   min 0  sec 40  mV 21291  mA 8  tenths-deg-C 227  mAH 0  

 

On the 500 series, the battery is bad, so I have to keep it plugged in. When doing so, I get the "do-charging-checking-fets" message and "bat:" messages.

The log file below is a bit large, but it is the result of  connecting the 400 series roomba, opening MRL, starting a roomba service, selecting the correct com port, clicking "test", then clicking "Click here for keyboard controls" then pressing the arrow keys. The robot doesn't move, but I can see that the TX line from the computer is sending the message down the cable. We can delete it for future use in this forum since it is so large:

---

 

Thanks for the log file, that is helpful..  a couple additional questions..

• You say now you can see data go from Computer ---> Roomba on the TX line of the serial cable ?  How are you doing this?  Is there a led somewhere?  And is this a change of behavior from what was previously happening (or not happening)?
• Have you tested this with RoombaComm directly and its moves/behaves correctly?
• Of all the silly things I didn't log out the details of the connection when it connects (fixing that now), but it looks like the code is 57600.  I'm pretty sure you can set it at different rates.  Is this correct for your Roomba?
• How did you get the initial logging at the top "from the Roomba", did you Hyperterm to the port?

It looks like we are getting closer if you can see data on the TX line... now it just a matter of talking at the correct speed and sending the right data ..