Samuel Wan : News, Information and Resources

Teleo AS2.0 library and simulation support

Teleo has released AS2.0 library, and it's pretty sweet. The original AS1.0 library was limited, but the new library takes full advantage of AS2.0's object-oriented features. Looks much cleaner, and easier to use. You can download the library and other materials here:
http://www.makingthings.com/products/downloads/flash_class_library.htm

Most thorough documentation of an Actionscript-based API I've seen:
http://makingthings.com/products/documentation/flash_classes/

What is Teleo?
http://www.makingthings.com/teleo.htm

Addendum: I saw that a base class, TeleoProxy, defines getProxySimulate() and setProxySimulate(). Wow, the new library supports a simulation mode! So, you can demo or test their API without having to buy a lot of hardware up front. The UI for controlling the simulation looks ok too. More info on simulation mode here: http://www.makingthings.com/products/documentation/teleo_flash_user_guide/teleo_flash_user_guide.html

Addendum: Chafic tells me Teleo used BLDoc to generate those docs. I will have to agree with him that the charting component docs are the best documented Flash api I've seen so far :-)

Resources for designing a LEJOS remote-control protocol

Tutorial on java data types
Using the Internet Protocol as a learning model
Java Streams (Sun Tutorial)
Java Object Serialization Protocol (too big for lejos JVM, but a good example nonetheless)
Lejos API Documentation (Lejos is the mini Java Virtual Machine implemented for the Mindstorms RCX Brick)

Not so bad after all

Turns out writing your own simple protocol with Java.io isn't so hard after all. It's actually not so bad when using the lejos JVM's java.io implementation. I can send basic data now, so next thing to do is figure out a tight, simple protocol for specifying method calls and method parameters. In other words, a basic web service model, but skinny ;-)

Now I've got a whole new level of appreciation for real engineers who actually design communication protocols for a living. Phew...

Single element UI for robot control

Version 2: A lightweight and simple mobile robot. I came up with this design by myself to improve IR reception and boost speed. The rear caster wheel is lighter adapation of an idea from the Core Mindstorms programming book. The next version will have better support structures to hold a wireless mini video camera.

Now that I can control the robot via flash, the next step is to design a user interface to control the robot motors. The design problem has the added twist of operating with a slight delay after each command, due to the infra-red send/confirm cycle. So, the user interface has to accomodate the delay by presenting the delay as an aspect of the human-computer interaction. Also, I'd like the UI to incorporate a visualization of the two motors' direction and power, so that the user intuitively understands that he/she is steering simply by controlling two motors, rather than a third steering wheel column. I've got some ideas, will publish the Flash interface once it's done.

It's ALIVE!!! MUAHAHAHAHA!

It's official! You can talk to lego robots with Cold Fusion!!! Many many thanks to Jeremy Allaire and Jody Zhang for tips, many thanks to the LeJOS team for writing the Mindstorms JVM. Most of all, thanks to the guy who wrote the RCXDirect package, Tim Rinkens! You can read more about Tim Rinkens' wonderful java package here: http://rcxtools.sourceforge.net/rcxdirect/e_index.html

I think the high point of the day was when I sent my browser to http://localhost:8500/webrover/test.cfm , and my robot suddenly smacked into the wall on other side of the room. It scared the heck out of my cat! *sniff* The little webrover is all grown up and running around :)

For anyone interested in how I finally hacked the code to send a command from a Cold Fusion webpage to a Java object to my Lego robot, keep reading...

There are two ways to communicate with the lego via I-R. The first way is to write your own protocol and use the java.io package in the lejos operating system. The second way is to use a pre-written toolkit called "RCXDirect". I'm going with rcxdirect because it's perfect for remote control. However, RCXDirect requires a binary executable written in C, called "rcxsend.exe", as well as cygwin.dll. Under ordinary circumstances, you just put a copy of the rcxsend.exe into any java application that requires rcxdirect. When I rebooted everything and ran my code in a .cfm page, the code would try to contact the IR tower but nothing happened. It wasn't until I got into DOS, ran the cfstart.bat to force all system messages onto the screen, that I saw the following message:

Program "C:\CFUSIO~1\runtime\servers\default\rcxsend.exe" not found!
RCXDirectConnect: motor packet: failed
05/17 12:55:10 user FileServlet: init

So, I put a copy of rcxsend.exe and cygwin.dll into that directory. The motors start revving up now, but I wondered about the purpose of this default folder. I downloaded from sourceforge the source code which creates the infra-red connection, and figured out how the original programmer found the path to rcxsend.exe:

private static String sendPATH = System.getProperty("user.dir") +
((new File("rcxdirect")).isDirectory() ?
(File.separator + "rcxdirect"):"");

According to the java API docs, "user.dir" is a System property which returns a string path to user's current working directory. But why is "runtime/servers/default" the current working directory? I opened up the cfstart.bat file, and saw these commands:

setlocal
cd ..\runtime\servers\default
..\..\bin\jrun -start default
endlocal

I can think of three easy ways to run executable files from cold fusion: 1) Put all executables in a common directory and add the directory to your PATH environment variable (in Windows). 2) Modify the batch file to start from a custom directory, such as "runtime\servers\samuel_stuff" 3) If you're using java, just modify the path instead of relying on System static properties. I think option #2 is probably safer, since you won't have to make any changes to the environment variables or the actual code.

Conclusion: The debugging feature works really well in CFMX, but if you want to see more descriptive system messages about your Java code, you should run the batch file from command line rather than double-clicking on the batch file. Anyways, I hope I can claim dibs on being the first person to hook up a mobile robot to Cold Fusion :)

I will upload code and instructions soon. For now, must finish working on the book.

***Sam does a funky victory dance with his robot***

Obstacle in CFMX

I've learned how to instantiate Java objects in CF, but for some reason, I can't instantiate the RoverController class. I suspect it has to do with bad classpaths, or the fact that a dependent package relies on an executable file and local drivers to communicate with the I-R tower. I can call the same object in a test application to start the motors, so I know the RoverController class works. I can also call methods on non-Lejos classes from CFObject, so I know that the CFMX->Java bridge works.

An easy way out would be to write a socket server Java application that accepts commands on a local port, so that the Java object in CF could send commands to that port. However, it's not a clean solution and I'd rather get the CF object to work, for long term benefits with other pieces of code.

Higher speed

My theory turned out to be correct. Used a bigger wheel and removed the two-gear drive. The higher torque on the big wheel gives the robot a serious speed boost! When I activated the motors from my laptop, it flew across the room before I could even turn around. I saw someone's article on building a something like a transmission gear system, but it would be too heavy and large for my purposes (need to save some room for the wireless camera).

The new robot chassis supports the brick at a slightly off vertical angle for maximum IR reception.

Bigger wheels also led to the problem of a wider axis. Lack of steering mechanisms prevented my robot from relying on the motor direction alone to change directions. I found the solution in a description of a caster wheel mechanism, which you'll find in most shopping carts and rollers.

-Sam

Redesign robot

Finished chapter on textfields. It's the most comprehensive and longest chapter in the book. Whew.

Robot's not fast enough, I'm redesigning the chassis to position the brick vertically for better I-R reception, and adding bigger wheels to take advantage of the motor's relatively under-used torque.

Solving the problem from opposite direction

I'm continuing to document my progress in linking the lego robot to some macromedia technologies.

At this point, I'm quite comfortable with the leJOS API and laptop->IR->robot communication through custom java applications. Now I'm going to tackle the project from the opposite direction, starting with CFMX and JRun.

So far, I've got CFMX and JRun installed as a standalone server. I'm currently learning how to create Java class instances via the cold fusion CFObject tag, and call methods on the Java class.

Today's documentation: "Using Java and J2EE elements in Cold Fusion MX application"

http://www.macromedia.com/desdev/mx/coldfusion/articles/java.html

Phase 3: Hello World...?

I bought Brian Bagnall's book, "Core Lego Mindstorms Programming" at the Borders bookstore a few blocks down the street. Following the instructions in the book, I over-wrote the RCX firmware on the MindStorms brick with the latest leJos Java operating system. I compiled and uploaded a simple java program through the IR port (command-line, sigh).

Started tapping the bumper sensor of my rover, and lo and behold, the LCD panel starts displaying an incrementing integer for each tap on the sensor. Wow. On to phase 4...

Note: References to buttons, motors, and sensors must go through global static class variables in leJos. The device is straightforward and simple, so static references save memory, according to the book.

-Sam

First phase complete

Finished outlining the chapter on textfields, now I'm taking a break and going back to the mxrover project.

I've built a Mindstorms robot with touch sensor and two servo motors for mobile steering. I've figured out the Logo programming interface (they force you to go through the tutorials, I had to manually authorize myself to skip them, arrgh), but the programming tools are quite limited. I'm now going to over-write the firmware with the leJOS JVM to gain more control and faster authoring tools with Java, hopefully will have Phase 2 finished in 30 minutes.

-Sam

New direction for projects

As an interface technology for the web, Flash is superior to all other technologies in terms of developer speed, flexibility, distribution, and media compatibility. However, I'm interested in interfaces that extend beyond the web browser and web server. I am busy writing an Actionscript book, but for a few hours each day, I plan to investigate how to integrate Macromedia technologies and electronic devices. Hopefully, the project will start showing results in a couple of weeks. Stay tuned to the new telerobotics category for more details... in the meantime, I'll continue to post entries into the other categories as well.