Test MIDlet for Sun SDK on RS Media

17 posts / 0 new
Last post
DrSoong
DrSoong's picture
Test MIDlet for Sun SDK on RS Media

Hi there,

for those who're interested, I have combined some of my test programs for the new Java SDK into a single application. It tests:

(1) Sensors (doesn't work at all, in my opinion due to problems with SDK).

(2) Tracking (works, but is rather unreliable)

(3) Servos (works, but Servos seem to have problems keeping track of current position)

(4) Macros (works fine)

It's menu-driven. Use the left direction pad for navigation inside a screen, and the a, z, and select keys for menus.

You can download the application from here:

http://www.trantor.de/soong/robotest.zip (source and binary included).

I admit the source code is a bit messy, but I didn't have the time to write comments. Might do that later. Yeah, the usual excuse, I know. Smile

Looking forward to your feedback (in particular how things work on your machine).

Cheers,

Dr. Soong

Nocturnal
Nocturnal's picture

Interesting, just looking through your test app. So do you know if Humanoid.getSensors() returns the hand sensors as well? According to the guide they are only accessable throught the Arm class.

Your code is definately more efficient than mine.

I'm not surprised it has trouble keeping track of servo positions, I've spent time studying the communications between the two cpu's, and I haven't seen anything that suggests that the cpu that runs the body ever reports servo positions back to the cpu running the JVM (it could just be the existing software never requests servo position data though). I wouldn't be surprised if it just stored the last position the servo was ordered to move to.

DrSoong
DrSoong's picture

Wondered about that, too. I think what they mean is that the *fields* for the hand sensors are only accessible through the Arm class. Yet, the getSensors() method seems to return all of the robot's sensors. I had it print a list of all sensors at one point to test that. It's easy to add. Just do a

    sensorView.append(allSensors[i].getName());

in the loop that builds the sensors view.

Not knowing the servos' real positions is a problem, isn't it? I think it will be rather difficult to do controlled movement beyond the build-in macros then.

 

Nocturnal
Nocturnal's picture

I don't think his IR sensors would work even if the midlet was receiving sensor events, IR tracking is switched off in Media Mode, a check with a digital camera shows the IR LED's aren't firing. Oddly enough all the sensors report themselves as enabled. What there should be is a way to turn hearing and IR sensors on and off. Unless I am missing something.

It could pose some problems, but for most applications your aren't attempting to determine a servo's position, you just want it to move to a position.  

DrSoong
DrSoong's picture

The problem is that this doesn't seem to work in all cases. If you give my test application a try, the servo test allows you to select a servo. You can then move that to its max position, to its min (= 0) position, and to some kind of center position (max / 2 was my assumption). I didn't have the impression this works reliably for all servos, though it is possible I did something wrong here.

 

Nocturnal
Nocturnal's picture

The servo's I tested all worked, but I only tested a couple. You did notice that some joints only have 4 positions?

DrSoong
DrSoong's picture

I was not aware of that. Maybe I will put some more info into the test application. I had the problem with head and arms, I think. They would move completely into one direction, but when I wanted to go back, there was only a short wobble, but no movement. Will try it again, though.

 

Nocturnal
Nocturnal's picture

Some of the joints positional feedback are 2bit encoders (waist tilt left/right, wrists and head up/down), there is one 3bit encoder in the neck (left and righ) and four pot sensors (left/right shoulders, torso tilt forward/backward and waist rotate left / right).

If you look at the humanoid class documentation under field details it lists the ranges for the different servo's. 

DrSoong
DrSoong's picture

Thanks. That was a good hint.

Yet, servos are still a bit strange. For example, I sometime have to select MIN or MAX several times for a servo to actually perform the full movement. But maybe my batteries are already getting low. I will see that I get an AC adapterand then try it again.

Btw: What is the positionalProgram() supposed to do? It doesn't trigger any kind of behavior...

 

Nocturnal
Nocturnal's picture

I haven't had a chance to try all the servos yet, but I am running off a AC adapter. Some of the initial problems I had with using the UI (it seemed to lock a lot and be unresponsive) turned out to be almost flat batteries in my remote.

The positionProgram() call will probably trigger the program store in his positional program slot. I think this is sort of a carry over from the fact the RS Media is based on the Robosapien V2 hardware. I think that they are stored in the CPU that controls his body, but I haven't checked that. Positional programs are created by moving his body they way you want it to move. I think pressing "a" when in control mode enters the main positional programming mode (see puppet mode, page 36 of the manual). If the program is empty, calling it will do nothing.

There's also a left and right positional program that can be programmed by double tapping his left foot sensor or right foot sensor, but there doesn't seem to be a way to access them in the JVM.

Nocturnal
Nocturnal's picture

Interesting, I did some testing of the servo's. I found four servos that didn't work

WAIST_UP_DN_SERVO
LEFT_LEG_SERVO
RIGHT_LEG_SERVO
HEAD_UPPER_BODY

The first three will be because I was running of the ac adapter (which disables the legs and hips). I have no idea what the last one is supposed to move, but it did nothing that I could see. Something interesting I noticed was that SHOULDER_RIGHT_SERVO -> Max, move the wrong arm.

I also had problems with the midlet stopping unexpectedly after a while. I noticed that on the root linux console the following message popped up at the same time the midlet stopped.

License is no longer valid, system stopped. 

DrSoong
DrSoong's picture

Yep, SHOULDER_RIGHT_SERVO -> Max does indeed move the wrong arm. Wonder how that is supposed to happen. Since I handle all servos in a uniform way, using only the info that the JVM gives me, it must be a wrong mapping in Sun's code. 

I also have a problem with the MIDlet stopping after a while (hanging inside a menu, actually). I wonder if this is the same thing you see. Didn't hack the robot so far, so I can't say anything about console outputs.

DrSoong
DrSoong's picture

Btw: Don't you have the problem that some servos don't react properly on the first selection of Min or Max? Occasionally, I need to select the action more than a single time. Oh, and I'm running from AC in the meantime, too.

milw
milw's picture

DrSoong, when I look at your test file 'main.java' in the Netbeans, it says 'package javax.microedition.lcdui does not exist' and 'package javax.microedition.midlet does not exist'

I have the CLDC installed, is there an additional module that needs to be added to the Netbeans? (i'm in the process of downloading the Wireless TOolkit 2.5 for CLDC since that was the only Update Center module mentioning Java ME... you can probably tell, i'm a noob!)

edit- never mind, I added your main.java to a project and the errors cleared up.

milw
milw's picture

Ok, I've been able to run the servo tests too, though I put the wait time to 2s and took out the servo speed divide by 2:

    servo.moveToPosition(0, servo.maxSpeed());
    humanoid.waitUntilStop(2000);

Running on batteries, so the only one that had no effect was HEAD_UPPER_BODY. I'm also seeing the need to repeat the command more than once, and getting the left shoulder moving on a right shoulder command. Sometimes I only get a little glitch of movement for a Min or Max command, then repeating causes the full motion to occur. 

KiwiRobotics
KiwiRobotics's picture

Hey guys, im trying to run my first midlet on RS Media but when i boot him up i get the error "One of the application classes appears to be missing.  This could be due to a misnamed class  (carriage return)  Main"  Im guessing im either naming the midlet wrong or putting it in the wrong place on the sd card.  Any help would be greatly appreciated.  Also my rsmedia appears to stall for awhile after transfering the midlet via usb.  It has trouble getting back out of usb mode.  Im wondering if this would be something to do with the previous problem?

dougnets
dougnets's picture

Hey. Can someone tell me how to download and run the java files on the robosapien? I know I need to figure out how to run the midlet file, but I'm not sure exactly how that's done.

 

Edit:  

Nevermind. I found that simply placing the SD Card in the SD slot on the robot while using the USB attached to the computer works best. I also found that the midlet.jar file needs to be on the home directory of the SD card. The midlet file and the program are both working now.