Here is where to find TrackBot Common V2. Not the best name for a
project but here it is:

https://trackbotcode.dev.java.net/

Thanks

Bruce

------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
+1-801-534-1017  Salt Lake City, USA

Thanks Bruce,

I thought that might be a good place to go.
 I've pulled down a copy of the code earlier today ,
 but haven't tried it0 build & deploy it yet.

George

On Jul 10, 6:07 pm, Bruce Boyes <bbo...@systronix.com> wrote:

As I previously mentioned, I pulled down a copy of the trackbot code.
I should mention that I am running Trackbots with SunSPOT  brains.
Looking at the build scripts for TrackBot Common V2 raised a few
questions
about building the demo code:
1. It looks like I need the aJile 4.X libraries/tools in order to
build the demo code.
    Is this correct?
    [I have older 3.16.9 versions of the libraries and tools for
JStamp and JStik (from
    my JCX days) but I never upgraded to 4.X.]
    So I need to purchase updated libraries and tools?
2. It looks like the code has two parts:  code that goes on the SPOT,
and
    code that goes on the Trackbot.
   Does this mean that in order to create a running application, I
would:
   1. Create SPOT code
   2. Create Trackbot code
   3. Download code to the SPOT
   4. Download code to the Trackbot? (using the AVR programmer?)

I expect I'm confused about a couple of things....

George

On Jul 10, 6:07 pm, Bruce Boyes <bbo...@systronix.com> wrote:

At 13:37 07/15/2008, you wrote:

Hi George!

Here are some answers:

aJile runtime is *not* needed unless you want to build that option --
which for SPOT you don't.

There is only code on the SPOT which you build, deploy, and execute.
TrackBot code per se consists only of the TrackBot node runtimes
which is is written in C and loaded with the AVR programmer, and is
not at all any part of the application code Java build for SPOT.

These are reasonable questions. So apparently we need some better use
instructions. Actually there is a file in the project root:
SPOTDemoInstructions.txt which I am now updating. Please look at it
and also there will be new app notes here:
http://trackbot.systronix.com/AppNotes/allappnotes.html

best regards

Bruce

------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
+1-801-534-1017  Salt Lake City, USA

Bruce,

Last week I upgraded my SPOTs to the latest blue release,
but backed down to 080609 after reading your AppNotes.
Nicely done.

After reading the updated demo instructions, I had no problems
deploying the demo code to the SPOT.

When I ran the demos, the sensors seemed to be working as expected.
However, the behavior of the robot in Avoid and Wander modes was not
what I expected.
The robot moves in starts, and stops, and sometimes reverses direction
for no reason
I can see.  I do know that the signal between a SPOT basestation in my
office and
a roving SPOT in the hallway only lasts for about 15 feet, nowhere
near the expected 100 meters;
so I wouldn't be surprised if the Trackbot is being confused by weird
readings either.
But I'd like to be sure.

Any thoughts?
Tomorrow I'll spend some time digging into the demo code.

On Jul 15, 7:40 pm, Bruce Boyes <bbo...@systronix.com> wrote:

At 19:31 07/16/2008, you wrote:

This is TrackBot Common V2?

You can see the sensor state on the SPOT RGB LEDs - that should tell
you why the bot is avoiding something. I'm working on a better app
note of this code...

The Common V2 doesn't need a base station... how does this work together?

The radio transmit power is programmable, and I think the default is
low output to 1) save battery and 2) not interfere unduly with other
SPOTs nearby such as in a typical lab. You can crank it up and should
get 100 meters line of sight if there is not a lot of other 2.4 GHz
signal in the area.

best regards

Bruce

------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
+1-801-534-1017  Salt Lake City, USA

Yes, it is Trackbot Common V2.
I do see the sensor LEDs, and it looks like the signals bounce around
wildly.

Sorry to confuse you on this one.  Here I was talking about an earlier
range test I had done with SPOTs,
completely independent of Trackbots.  I'm getting anywhere near the
range I expected on the radios.
I thought I had the power cranked up, but I can check that to be sure.

eventually I am going to need to write some code which will allow the
Trackbot to be controlled
from a PC through a SPOT basestation.  I'll be happy to post it on
java.net when it's done.

A couple of days ago I ran the WarmBodyHunter code on the Trackbot,
just to find something with simpler decision logic than the Wanderer
code for movement.
This was after I attempted to simplify Wanderer and Avoider and other
robot code.

The good news is that the WarmBodyHunter code ran as expected.
Looking at the Wanderer code, the method that determines which
direction to go next
is way too long and complex to maintain.  This suggests to me that the
problem lies in that
decision logic wrt the environment my Trackbot is running in.
It's obvious that a lot of work went into the framework that is part
of the demo code,
however, it is not at all obvious how to extend that framework to
create a robot with
a different state machine.  At least, not without additional
information.

Clearly, it can get complex, since the robot's decision as to
direction and speed (9 possible directions, 3 speeds) is based on
input from 12 sensors (8 on the board plus the front and back cliff
sensors).

I am sorely tempted to rewrite the decision logic in the Wanderer.
Would that be useful?