Wednesday 30 December 2009

LeJos Robotics Repository...

...has been created using google code and can be viewed here . If anyone would like to be added to the project, please let me know.

Tuesday 29 December 2009

The Beginning of a Tweetbot

Although in terms of setting up LeJos on mac osx 10.4 has been very pain staking today, we did manage to get the tweet bot up and running in it's basic form (although no interaction with twitter as of yet).

We have created a lego tweetbot code repository using google code and created twitter account for Tweetbot (if you wish to follow). We also wrote some basic code for communication. A good start to the project (if you discount silly problems hardware and LeJos related).

Here are the two bots that will be part of the tweetbot project


Friday 18 December 2009

Daily Update Meeting - remotely

As Wadz is ill I facilitated the GIMS daily progress meeting. This was a good experience as it is crucial to ensure that order is maintained and everyone sticks to the 3 questions and answers as concisely as possible, otherwise chaos will ensue.

Also, due to being close to Christmas a lot of the guys are off, so the rightshore guys who were on site moved the tasks along and calculated burn down and burn up. This is also very good exposure and experience for them as they will have to take these skills back home with them and ensure that we work in this manner when the project moves into the next phase.

So all in all it was pretty good. It would be so much better if we had a web cam though.

Thursday 17 December 2009

Tweetbot 2nd stage

As chris pointed out the 2nd stage of the tweetbot would be to perform actions indicated by a request from the followers. This however is something that is quite tricky and will require a lot of thought to implement as understanding of language and semantics is required.

Retrospective

So we had our retrospective today, which was pretty good (I even got to facilitate). Four actions were determined and although we didn't meet our target the general consensus was that this way of working was definitely very good. People felt that they gelled better with the team and had a better understanding of where everyone fits in.

Tomorrow is our last virtual progress meeting then the new iteration begins in the new year. Bring on the new year :D

Wednesday 16 December 2009

Tweetbot

Another idea I have had which I would like to incorporate in my robot is for it to state it's actions via twitter. I could set up a twitter account for the bot, then when it is running get it to tweet what it is doing and looking for in natural language over twitter. So, for example, take my final year intelligent robotics project where we created a robotic dog which would wag it's tail when stroked but stop wagging if stroked too hard, these are posts the bot could make over twitter.
Also the bot had a planning system in place and would scan for objects in order to find a ball and then use manhattan distance to bring it back to the 'master' again things we can tweet would be it's location, the object it is scanning (whether it's a ball or not), 'got it' when it has retrieved it and then how it is getting back to it's master.

So for my new bot, once it has been programmed up, I think it would be cool to try and implement something like this. Any thoughts?

Friday 11 December 2009

Virtual Progress Meeting Over GIMS

So since a lot of us work from our home/base location on the Friday and every day we have a 15 minute progress meeting to highlight what we have been doing and any issues we decided to use GIMS (Group Instant Messaging Service, essentially a work MSN).

So this includes a 9 people conversation, obviously this can pose issues and can get very 'messy' so we had a chair who posed 3 questions:

1) What work did you do yesterday?
2) What are you working on today?
3) Any blockers.

Each person was asked in turn, type the answer, move onto the next person.

We had intended to broadcast the board via webcam (the locals in the office would have done this) but unfortunately  our work's network has blocked the webcam functionality which is a shame.

The meeting worked pretty well albeit a techy glitch at the beginning and if we can use VOIP and webcams it will be even better. I think using this approach today and hence forth on Friday's will be a good way of demonstrating that we can do this over a distributed environment (especially if we are to send work offshore).

The only disadvantages are if there are technical problems, the fact that we cannot at the moment use webcams and the meeting takes longer than 15 minutes as people are typing. Other than that it has worked pretty well as a pilot.

Since the webcam option is blocked, I have requested that the local guys take a pic of the board and the burn down chart and send it across to us so we can see the progress based on today's meeting.

It's been a lot better than I had anticipated.

Thursday 10 December 2009

STS Continues to Pain Me...

...this time when re-naming your project. Turns out tc Server doesn't pick up the re-name and issues arise. With the help of Wadud, we worked out that you need to find the Server.xml for your tc server and change any references to the old naming convention of your project. Also link the file with the editor (a backward and forward arrow button in STS). This change needs to be made for your pom.xml file as well as  your org.eclipse.wst.common.component file.

Clean  *everything* (much safer this way) and try again.


Such a pain, you'd think that tools like STS would sort this out for you instead of having to go through this.

Daily Progress Meeting

So we have just had our daily progress meeting and (as it's the first week) we seem to be burning up. It turns out that we hadn't identified all the tasks on Monday so they have accumulated over the course of the week. This isn't necessarily a bad thing and it is the first week using an Agile approach on a RUP project for plumbing tasks.



 

Although we burnt up and at this stage that isn't necessarily a bad thing, we are much more focussed and the people new to the process are both getting into and enjoying it.

Tomorrow (as us non-locals are travelling home tonight) we will be attempting a progress meeting via GIMS. This will be a good test to see whether this approach is sustainable over a distributed project environment.

Wednesday 9 December 2009

Another STS PITA

So here's another problem that took ages to sort out. If the XSD you are using in your project is referencing other XSDs on a server and in your network connection settings you have not bypassed the proxy for that server thn instead of STS informing you of this it does this instead (for ages):



There is no useful warning message or error or time out message. Although the issue itself was not with STS it is still a big usability fail! 

Tuesday 8 December 2009

New Project - Agile Approach

We have started introducing Agile working practices on our project as of yesterday. A step in the right direction :D This is the Agile task 'board' (brown paper) in our 'War Room' :D First stand up meeting today, those not familiar with the concept seem to be ok with it so far :) Let's just hope we can make this as successful as possible :-)


Lessons Learnt from the STS & RTC Installation

Today I embarked upon the STS & RTC installation specified in Andrew's post.

What can i say other than it has been fairly painful. Firstly I was using an older version of STS, so I upgraded STS. Once I did this, I referenced back to my original workspace - bad idea! Eclipse totally got itself in a twist. The best thing to do is create a brand new workspace and import your project from the existing to the new workspace.

The second issue I have been having issues with is the installing new software. I added the urls (specified in Andrew's post) but in order to connect to the repository I had to change the network connection settings. This caused the urls to time out. I tweaked the settings again to ensure they are correct, still no luck. I had to delete and re-add all the urls in order to get the software to update.

Both these issues have caused me a tremendous amount of pain today and I thought it would be worth documenting, in order to make life easier for others.

Thursday 3 December 2009

Getting Started With Spring Web Services

Being a newbie in the world of web services I was asked to set one up on my current project. As we are using Spring MVC & STS it made sense to continue down the Spring route.

Also Spring-WS supports contract first whereby one starts with the WSDL first and then implements the endpoint using Java as opposed to contract last where you start with the code first and generate the WSDL from that. There are many advantages outlined in the Spring Tutorial extensively, but one of the biggest selling points for me was that in a contract first the contract would remain constant over time whereas in a contract last the contract might be subject to change as the Java code changes.

The Spring Tutorial above will take you through a detailed outline of how to set up a Spring Web Service, in my post (from my now newly acquired Spring Web Service wisdom) I will take you through the basic set up for a web service with the generation of a WSDL. This simplification is aimed at the newbie for whom it may be a daunting task to set up a Spring web service with very little prior experience. Before I get going, I'd like to thanks Russel Hart (@rus_hart on twitter)  for all his help and guidance with my task.

  • Step 1: Download and Install STS from SpringSource
  • Step 2:  Create a new Maven Project ensuring that the archetype is a webapp.
  • Step 3: Add all the Maven dependencies to your pom.xml.
  • Step 4: Create/Import the XSD that you will be using for the project (this is the data contract).
  • Step 5: Modify the web.xml file (this defines a Spring-WS MessageDispatcherServlet and maps all incoming requests to this servlet).
  • Step 6: Create a ws-servlet.xml file (this file will contain your EndPoints bean and WSDL (service contract) Definitions to autogenerate the WSDL).
  • Step 7: In src--> main create a folder called 'java' and ensure that it is part of the Java buildpath (right click on the project properties --> Java Build Path --> Add Folder and add the java folder to the buildpath).
  • Step 8: In the Java folder create the EndPoint java class.
  • Step 9: Extend the AbstractJDomPayLoadEndPoint class and implement the invokeInternal method. NB: It is possible to extend other classes also most suited to your particular project.
  • Step 10: Ensure that your project builds
  • Step 11: Ensure that you have added the web project to your Tomcat server.
  • Step 12: Run the project on your Tomcat server.
  • Step 13: Check your localhost to ensure your WSDL has been generated (in my instance the URL would be: http://localhost:8080/wsTest/Sample.wsdl).

That is pretty much the it in terms of the steps needed to setup Spring WS and create the service contract. You will then need to write the Java code to implement you Endpoint for your project accordingly.

My Sample project and the WS Tutorial project (from SpringSource) can be found here.

Tuesday 1 December 2009

Robotics Brainstorming

I've had a lot of robotics thoughts on my mind so I thought I would share them here.

Firstly I have been thinking about self healing robots. The technology seems to exist for robots that are able to repair themselves, so that would be pretty cool. Another area I've been thinking about is self replicating robots, or robots that build themselves based on a bunch of components. A robot that is able to change it's shape, transformer style would be pretty cool too.

Ok so now back to my current robot. Well in terms of behaviour, I will be attempting to take my Final Year Project (Mars Rover Planning System implemented in Java as a piece of software) and attemtping to program it into a physical robot.

There are going to be some problems with this, in particular relating to distance calculations and determining it's own location. When building it purely from a software perspective, my Mars terrain was a fixed value. This meant that it was always going to be that fixed space and the rocks and rover could be added anywhere within that space. Using java code the robot could determine it's own location and then using pytahgoras' theorem determine how far each rock was.

Now, I guess in a real environment this could be overcome by creating a fixed grid like environment but that to me sort of defeats the point. Also, if it was a fixed grid, how does the robot determine it's own location? (Unless it always starts from the same position). As well as that, what about determining the distance of the objects I mean the sensors would have to really perform on this front. I haven't as of yet played with the sensors or quite deduced how I will do this but it's definitely something worth thinking about.

Search This Blog