I have started a project for my last year in university that is going to work with two NXT's , Lejos , bluetooth, JCSP RE

I am going to be building software that implements parallelism in its design and build.

I intend to have one robot use its light sensors to read some pattern and in parallel via bluetooth have the second robot use the movement data sent to it from the first robot to move and draw what the first robot is seeing with the light sensors.

I am excited an looking forward to completing this and hope that some question i might have can be answered

Last edited by PatrickLismore on Mon Mar 03, 2008 11:57 am, edited 1 time in total.

I am using JCSP and building components and then running them all in parallel. Its very slick,

I have one set of componets for the left side and an equal set of components on the right side.

The components i have are "light sensor" , "motor" , "filter" and "Control" , "copy"

I am now testing what is gonna give me the best movement, because the final goal of the project is to have two robots one following a pattern and another drawing the pattern which the first robot is seeing.

I know with one sensor theres going to be alot of wiggling about with two sensors there is still wiggling, this wiggling is gonna show on the second robots pattern that it draws.

I am trying to eliminate the wiggles showing on the pattern that is drawed by the second robot.

Im gonna send the data via bluetooth from one robot to the other, I am guessing that using three sensors will help reduce the amount of wiggles that will show up on the pattern drawen by the second robot.

I would like to know has any of the community any suggestions to reduce the wiggles from their own experience.

Any recommedations or helpful information to guide me in the right direction when it comes to bluetooth, I have the book "Building Robots with Java Brains" which is really interesting and im hoping its enough to allow me to connect up the the two Robots and pass the data.

Has anyone developed any robot with Bluetooth would be really interested to chat about whats involved.

three sensors will minimize the wiggling of the robot following the line.

i loaded up one of the processes and passed over more than 15 parameters and found that lejos has a limit on the number of parameters you can pass across.

this had me stumped because for the three sensors to work along with the three binary filters i needed to pass over at least 17-18 parameters.

This caused even more trouble because i had not even started on the Bluetooth Process which would involved even more parameters feeding into the control process.

So with some sound advice from my professor i set about redesigning the program. I am going to limit the parameters and inside the control process i am going to initialize the 3rd and middle lightSensor Process.

Its quite challenging to design a program for the NXT using

JCSP RE

CSProcess

Channels

Im currently working with the bluetooth aspect of it and i was able to control the NXT from the PC without executing any program on the Brick.

I have also been testing a Bluetooth Transmitt and Receive Process.

hopefully soon i will make a breakthourgh and be content and happy with what i have got, thanks to all those on the forum because I have learned alot by reading other peoples work.

If theres anyone out there knows about concurrent programming , parallelism , JCSP i'd like to throw a few questions your way.

So i have now built the second robot , built all the processes for the second robot.

I have run a test to see how it works

What i have found is the first robot will follow the line then it will connect to the second robot via bluetooth , the data from the first robots movement are sent across correctly to the second robot and i have a correspoding string displayed which all looks good.

I thought the second robot was not moving but upon closer inspection i found that the robot was moving extremely slow like 1mm every 2 seconds.

So looks like i need to set the speed equal to the first robot and im in business

im quite happy that i at least managed to get both moving, so im just trying to weed out the issue

then in another test both start moving and the second starts to turn in response to the first and again i shout with excitement but again after the fist little turn of the second robot it continues on straight insteaed of continuing to respond to the first robot

I am almost at the end now all i have to do really is refine-ing. Currently the robots dont look like much but I have been more interested in functionality before appearance now that the robots can,

connect via bluetooththe first robot follows a lineit sends the movement data across to the second robotthe second robot interprets the movement data passed over via bluetooththe second robot responds to the first robot when it moves

All thats left for me to do is

make them look really nice, add a pen to the second robot and create some challenging lines to follow. Also modify the second robots rear im using the tribot design but i need something more sturdy so that it minimizes the tendency to turn to the left or right on start up that one little wheel at the back i think needs another one.

I am currently involved in writing the project up, designing some posters and bringing all my work together.

I will also make available the source code , diagrams and report in a little while.

Some people may want to see how i applied the Process Oriented Architecture in designing and building the software for the nxt's others may be interested in the JCSP RE others may want to build the program and improve the performance or extend it in other ways.

I have some recent videos,

apprecaite the videos were taken about 7 o'clock this morning so most people in my place are all still sleeping hence me speaking softly. Of course the robots dont look that visually pleasing but remember, up until this point I have only been concerned with getting them to work now that i know they can do what they were programmed to do i can make them more visually pleasing to the eye.

Once I get closer to the demonstration in University I will get a hold of a proper camera not a cell/mobile phone with better quality and sound.

so heres the videos

this video you will see the slave robot veer to the right when it begins to move i need to prevent this from happening by modifing the wheel at the back maybe to include two wheels

in this last video you will see that the slave robot actully takes of straight this time and as they approach the first turn you will see that they respond exactly but due to the sensors having moved it fails to follow the line and the two robots continue straight , well the first one continues straight and obviously the seconds one is just following the first so once i bolt everything into place make sure the sensors cannot move and the slave robot has a sturdy back on it then i feel that they will perform exactly the way i want every time. In this last video you hear me describe the project and the robots when i say components i really mean to say Processes.

as you can see its quite large and as such not suitable for the small memory on Robots. So a masters student at my university has wrote a smaller version of JCSP which is being called JCSP RE (robot edition ) which gives us what we need to be able to implement parallelism on a smaller scale on the NXT we dont need the graphics packages for example and lots of other things mostly just the fundamentals. I was given the jcsp packages wrote by the masters student based on his research into what the University of Kents has been doing with JCSP and his work give me the parallel prgramming environment I needed to build a working program for the master and slave robots using a process-oriented design. From the JCSP RE packages I have been able to make Active Components which implement the CSP Process interface.

A CSP process is a component that encapsulates data structures and algorithms for manipulating data contained inside it. Its data and algorithms are private and the external world can not see the data and cannot execute its algorithms. Each process is considered alive, it executes its own algorithms on its own data. The Processes interacts through CSP synchronising primitives, channels and events.

A process in java using JCSP RE is an instance of a class which implements the CSProcess interface. Its actions are defined in the run method.

When one of these processes runs it interacts via CSP channels.

I never thought of my program as a general API as such Mr Bagnall just a program for my NXT but im sure with a bit of thinking it could be made into an API for others to get started with certinly the JCSP RE packages will be getting published along with a joint paper at conference some time this year, my professor was telling me a little bit about it because i was asking him will the org.jcsp.*(RE) packages that im using be getting published so others can use it and he said it would be along with the paper thats being wrote now. You got me thinking now Mr Bagnall I could possibly make general ActiveComponents such as the

and so on , i will run the idea past my professor and see if its possible I dont really know because without the JCSP RE you cant make the ActiveProcess mentioned above, unless as part of the release of the JCSP RE we include all the processes like the BTtx and BTrx , AM, ALS, AUS, with relevant documentation for people to start working with instead of building their own processes from scratch we can just include the ones we have already and people could just modify them as they need to and extend them for their own needs. I put this to my professor and see what needs to be done to make it all into and API and we can get that put into place.

My contribution is based around firstly making use of the JCSP RE effectively building active processes and having my (concurrent/multithreaded/parallel) program exploite the bluetooth technology on the NXT Brick by creating an Active Bluetooth transmit process that transmitted data to the slave robot and for the slave an Active Bluetooth Receive process as well as others to effectively control it by sending movement data via bluetooth.

Of course none of my work could have been done if it wasn't for you guys writing LeJOS giving us excellent classes to work with. When i post up my source code you will see how I have taken a simple BTtx class and converted to an ActiveProcess configured it to interact with my control processes to get movement data and send it via bluetooth to the slave robot.

Ok, I see what you are up to now. I believe the guy who wrote JCSP posted something here to the forums about that package. I was looking into it a few weeks ago to see if it would be worth adding to the leJOS NXJ API but my overall view was that it was much more complicated than we would need. There's quite a steep learning curve to use it and a lot of extra classes to support other parts of the API.

BTW The mirroring program you are working on reminds me of a level in the game Tomb Raider where you walk into a room and there is a doppleganger of yourself who does everything you do. If you shoot it, it will shoot you, etc... So you have to figure out a way to defeat it. The room was also symmetrical in almost every way. It was a pretty clever puzzle from what I remember.