Architecture Path [Archive] - Trossen Robotics Community

Matt

04-21-2008, 05:21 PM

Adrenalynn

04-21-2008, 05:29 PM

[In full acknowledgment that this is gated by #2 above, as you mention]

I'm by no means "anti-windows" - but I am "pro-small-is-beautiful" - especially when embedding.

I would like to put forward a vote for C/C++ (I really don't like C++, but it sure wouldn't be that hard to make the port from C#). C/C++ are both "universal" (if you stay away from the weird libraries) and one would be hard-pressed to find an embedded system that didn't have a compiler/cross-compiler to support it.

Matt

04-21-2008, 05:41 PM

I'm about to post 2 new threads: one for the language discussion and one for the protocol discussion. We can chat on those in there, for here I'm hoping to just get a consensus on the path. The order of our steps...

1) discuss and choose a communications protocol
2) upgrade the current C# TROM to it
3) Build the first version of the rendering tool
4) Build a GUI robot builder interface ??? Probably dump the old one Alex built since it won't work anymore.???

and so on....

LinuxGuy

04-21-2008, 05:52 PM

Currently the TROM is in C# 2005. It is event driven based upon the observer design pattern. Everyone is agreed that two evolutions need to happen:

1) Rewrite the TROM in a new language that is OS independent
2) Choose a standard communication protocol (replacing the observer design pattern. We are all circling around sockets / web services type implementation)
1) This would have to be something like C/C++ (I already know C and have some familarity with C++), Java (This does not exite me too much right now, although I could learn it), Python (I already know it, but have not used the OO features yet), or something else.

2) This can be discussed and chosen even before an implementation language has been chosen for it. Some languages might be better at implementing different protocols, but maybe not. You can do pretty much anything I C/C++ and Python for sure, but I don't have the familiarity with other languages such as JAVA to say about them.

Alex and I really think that it would be smart to tackle #2 first while staying in C# for the moment to make life easier all around. Trying to tackle both at once opens up too many variables and decisions to be debated.
I've never used C# and am not thrilled at needing to. I just don't have room in my head right now for yet another language or derivative. It's native to only Windows. I'm already learning Smalltalk (Squeak (http://www.squeak.org)) gradually and don't care to add another language on top of that.

For those who really don't want to be in windows should still be able to use mono to run the TROM. The goal is to get to a working version of the TROM using the protocol we choose ASAP so that we can bang out a rendering tool also using that protocol.
I do have Mono installed, but am not particularly motivated to mess with it other than to run programs that might require it.

Then we can have the debate over which language to convert the TROM into. (Or, already having finished the debate by then, start the conversion.)
There is no reason not to discuss choice of the implementation language concurrently, and even decide on one while other stuff is happening.

So, essentially we are asking the anti-windows crowd to stay calm through the first implementation so that we can get started faster :D
I'm not anti-Windows. I use it when it's required for something I need/want to do (Alibre Design 3D CAD, developing with PICs/dsPICs, etc). I just don't develop for Windows at present.

8-Dale

Matt

04-21-2008, 06:00 PM

>>>>There is no reason not to discuss choice of the implementation language concurrently, and even decide on one while other stuff is happening.

Agreed, I just opened that thread BTW. I was just trying to order the work steps, not really the discussion.

We aren't asking those that don't know c# to learn it. Someone who already knows it or can jump in will work with Alex on that upgrade and then everyone gets the finished version which needs only to communicate with it. Then people use it with mono if they are not in windows while working on another area, like the rendering tool which you are already diving into. We aren't asking everyone to learn C# it's not necessary.

PS: I was just teasing with the anti-windows thing everyone.

Adrenalynn

04-21-2008, 06:12 PM

I'd be on-board if you said "anti-windows-as-a-server" ;)

I think your initial ordering is good, but I do have some concern about trying to tie into the renderer from C#. You're crossing a divide there that's a little scary. OGRE, for example, won't build under the C# environment. We'd be needing to build an abstraction layer betwixt C# and OGRE - whilst that's doable, we'd be talking almost immediately about scrapping it. Why not consider squirting the port into "2.5", right as the fully defined C# stuff starts to come to life?

LinuxGuy

04-21-2008, 06:45 PM

I think your initial ordering is good, but I do have some concern about trying to tie into the renderer from C#. You're crossing a divide there that's a little scary. OGRE, for example, won't build under the C# environment.
My own feeling is we should pull away from C#, or anything that is platform specific, as fast as possible. I don't think choosing a language is going to be that big of a deal, as there are quite a few cross platform languages available. Some might be better than others for what we want to do, but most of the source code we are going to be dealing with is going to be in C/C++. Python can interface with C/C++ modules as can just about any language I can think of, including JAVA I believe.

We'd be needing to build an abstraction layer betwixt C# and OGRE - whilst that's doable, we'd be talking almost immediately about scrapping it.
I so do NOT want to get into having to do this kind of thing, especially just for a short term thing. I really don't think this is the way to go. It's just wasted effort, with a bit of wheel spinning, as I see it.

Why not consider squirting the port into "2.5", right as the fully defined C# stuff starts to come to life?
I'm not familiar with C#, but can it be that difficult to move it up to C/C++? I have real mixed feelings about the whole C# thing. I can see why Matt and/or Alex would want to stay with it for a time - it's what they know and are familiar with, and I appreciate that. However, I also see real solid reasons for speeding away from C# and any other platform specific thing as fast as possible. How difficult would it be for a C# programmer to move into C/C++, even using the MS tools?

I realize there are going to be some differences between platforms, regardless of what we do, but one can even get GNU C/C++ running under Windows. There are well documented packages just for this - Cygwin, etc. We could all be using the same compiler toolset regardless of which platform we are developing on. Doing this also greatly minimizes the effort of sharing (and maintaining) code between platforms.

8-Dale

Adrenalynn

04-21-2008, 08:33 PM

While I would agree with you, I'll argue the inverse here for the sake of discussion

Trossen already has some stuff working. Leveraging that will get us someplace faster. That "some stuff" is in C#. So if we hurry it to the end, we introduce less unknowns and get to market faster. It's well-known and safe.

OGRE will build with gcc, but will also build with VC9 (2008 VC++), all editions inc. the free/Express edition, but you have to use the precompiled dependancies (which I'd bet were compiled with gcc ;))

I'd like to see us look to gcc. Why? GCC is the most amazing cross-compiler on the planet. If it compiles in GCC (with nothing funky), it'll compile with *anything* as a target. I would like to see us paying attention to the embedded platforms going forward. But I just realized this probably belongs in the other thread [full stop]. Sometimes it's hard to "delink" the dependancy of environment to architecture...

I didn't see you disagree to putting the port in at "2.5", Dale?

Matt

04-21-2008, 08:58 PM

>>>But I just realized this probably belongs in the other thread [full stop].

I don't think we can totally separate the language discussion from this part of the debate. We really at heart are debating about the order of the process, to do that we need to argue the pros and cons of being in certain languages I guess :)

You succinctly put forward the points I'm also making. When we pick the protocol it may only be a few nights work for Alex/someone to tap it onto what we already spent 9 months developing. As I understand it, if we run with sockets then how we build OGRE stays absolutely the same. It doesn't care nor "see" C# right? (I'm asking here, compiling for various OSs and some of the items you are discussing are WAY out of my experience.) If that's the case we aren't really going out of our way to have OGRE interact with the existing version.

Even if we do have to build a layer of some sort in there for the time being in my mind 1 week of work trumps rebuilding an object model for 4 months. I say, get the thing up and running and start learning. We will immediately start creating a list of things we need to change and debug and upgrade. Knowing this before we go into a fresh rebuild is valuable. It can be good to see what was overlooked in the current version we know is getting scrapped.

Dale (everyone) please keep debating the points you are thinking of here. This is exactly what we want, everyone listing out their thinking, objections, arguments, etc. I'm still arguing for using what we have, but you have stated some good reasons why not to. I'm undecided so far to be honest.

Matt

04-21-2008, 09:00 PM

Maybe we need to hand the actual project files over to a few of you and let you see how complex you think a rewrite will be? Let's get a handle on what man hours we are talking about here. Or maybe you can already tell from looking at the diagram we sent out?

Sienna

04-21-2008, 09:27 PM

Haven't had time to study the block diagram.

I want to point out to everyone how important the PROTOCOL is to this decision. I tend to agree with the majority here... take the easy way out for the moment, and just add a protocol to the .net stuff. (I would like to point out that as soon as choose a protocol, building a OGRE whatever ontop of that protocol will separate it permanently from the .net stuff, and it wouldn't be throw-away.

This is one of the places I am willing to compromise my hate for everything that comes from MS for practical expediency....

LinuxGuy

04-21-2008, 09:49 PM

1) discuss and choose a communications protocol
2) upgrade the current C# TROM to it
3) Build the first version of the rendering tool
4) Build a GUI robot builder interface ??? Probably dump the old one Alex built since it won't work anymore.???
How about:
1.5) Discuss and choose implementation language
2) Upgrade and Convert current C# TROM to using the languge specified in item 1.5

8-Dale

LinuxGuy

04-21-2008, 09:55 PM

I'd like to see us look to gcc. Why? GCC is the most amazing cross-compiler on the planet. If it compiles in GCC (with nothing funky), it'll compile with *anything* as a target. I would like to see us paying attention to the embedded platforms going forward. But I just realized this probably belongs in the other thread [full stop]. Sometimes it's hard to "delink" the dependancy of environment to architecture...
Very well said! I use it daily to cross compiling stuff for Hammer (http://www.tincantools.com/product.php?productid=16133&cat=0&page=1&featured).

I didn't see you disagree to putting the port in at "2.5", Dale?
Actually, I'd like to have the port where it is, but insert 1.5 for choosing the implementation language.

8-Dale

LinuxGuy

04-21-2008, 10:08 PM

I want to point out to everyone how important the PROTOCOL is to this decision. I tend to agree with the majority here...
We don't even need to choose an implementation language to chose the protocol, unless we want to take into consideration the amount of existing code we can start out with. I'm betting C/C++ wins out clearly in that case. I'll take a shot at CORBA after I get OGRE running on my system. I am betting CORBA has a lot that will be of use in robotics.

take the easy way out for the moment, and just add a protocol to the .net stuff. (I would like to point out that as soon as choose a protocol, building a OGRE whatever ontop of that protocol will separate it permanently from the .net stuff, and it wouldn't be throw-away.
The easy way is not necessarily the best way though, which might require more work in the short term but pay off bigtime in the long run. I really want to get away from anything platform or company specific as quickly as can be done.

This is one of the places I am willing to compromise my hate for everything that comes from MS for practical expediency....
I don't hate all that MS produces, but I do have a problem with the way they do business and aquire things. I'll take their freebies, but I don't want to lock myself into the MS way of doing things when there is often (but not necessarily always) better out there. I want to keep my mind as open as Open Source. :veryhappy::veryhappy:

8-Dale

Matt

04-23-2008, 11:25 AM

The decision tree is pretty clear at this point and we have been working through it nicely in the forums:

1) Protocol needs to be decided first (web services/CORBA with pipes and sockets looks to be the current direction being talked about)
2) Then language (C++ is winning)
3) Then whether or not to convert the C# immediately or wait 1 round. Currently, evidence and opinion seems to be pointing toward moving into a rewrite out of the gate. (I can see you smiling Dale, but don't count your chickens yet ;) )

After we finalize the decisions we get into who is raising their hands for what. Jodie has kindly said she could work on the conversion, Dale is clearly loving the idea of playing with OGRE, Sienna did I hear you mention liking GUI work earlier? The tree control and properties grid will need to be redone.

Anyhow, that's just me thinking out loud. I'm getting ahead probably.

LinuxGuy

04-23-2008, 11:57 AM

1) Protocol needs to be decided first (web services/CORBA with pipes and sockets looks to be the current direction being talked about)
2) Then language (C++ is winning)
I'd look at CORBA, but I am WAY more interested in OGRE right now. I'll bow to Sienna on the protocol as she clearly has more expertise in that area. I am much better at interfacing, hardware and software components.

3) Then whether or not to convert the C# immediately or wait 1 round. Currently, evidence and opinion seems to be pointing toward moving into a rewrite out of the gate. (I can see you smiling Dale, but don't count your chickens yet ;) )
Umm, how did you guess? :veryhappy::veryhappy: I have a kitty, so she would chase down your chickens. :happy:

After we finalize the decisions we get into who is raising their hands for what. Jodie has kindly said she could work on the conversion, Dale is clearly loving the idea of playing with OGRE, Sienna did I hear you mention liking GUI work earlier? The tree control and properties grid will need to be redone.
YES, I want to tinker with OGRE, if I can ever figure out what I missing to get it to build. I have wanted to tinker with 3D for a long time, but never (for some reason) ran into OGRE before. Hopefully OGRE won't harass my kitty too much. :happy: I don't get excited about software systems very often.

8-Dale

Eric

04-23-2008, 01:19 PM

If it is a toss up between CORBA vs web services.... I don't know anyone developing in CORBA anymore. The current business model is web-services (and its growing).
As for languages... I do love java, but C++ and C# are fine tools. The biggest concern is to make sure it's a major language and not a limited community language or the new fad in developing.
Just my 2 cents worth...

Matt

04-23-2008, 02:34 PM

I just moved two posts that were about language discussion to the language thread. This thread is on architecture path & our decision tree/cycle, etc.

thanks

EDIT by Alex: Helps to give them the URL Matt:p

http://forums.trossenrobotics.com/showthread.php?t=1685

Sienna

04-23-2008, 06:10 PM

Shouldn't the tree views and whatnot be split from the actual object model? After all, they are only a way to represent the object model, not the model itself. And we want the object model to be lean as possible, to be portable to as many platforms as possible!

And like you, I think I want the rendering of the current system tied into the same guis as the other stuff... so Dave would have to tell us how to put OGRE into a GL window or something.

Matt

04-23-2008, 06:58 PM

Shouldn't the tree views and whatnot be split from the actual object model? After all, they are only a way to represent the object model, not the model itself.

Absolutely. That's how we did it the first time. Not sure where you are seeing otherwise. (admittedly, my head is spinning from all the different awesome threads :) ) I imagine other companies/people will come up with their own GUI interfaces down the road as well.

And like you, I think I want the rendering of the current system tied into the same guis as the other stuff... so Dave would have to tell us how to put OGRE into a GL window or something.

No, the rendering tool needs to be it's own thing as well, not tied in. The treeview/properties grid manipulates the TROM and the rendering tool just sits there and renders. Well wait, okay, I think I know where you are going. More advanced versions where the rendering tool becomes clickable for selecting parts and stuff like that, yes, now you need them tied a little more tightly together. I haven't banged that around in my head enough yet and am thinking KISS out of the gate. That might be easy to do by just allowing the rendering tool to broadcast also. Then an App developer can be free to tie them together how they like.

metaform3d

04-23-2008, 08:14 PM

Well wait, okay, I think I know where you are going. More advanced versions where the rendering tool becomes clickable for selecting parts and stuff like that, yes, now you need them tied a little more tightly together. I haven't banged that around in my head enough yet and am thinking KISS out of the gate.There's a design concept called Model/View/Controller which I would very much advocate for this project. For running a robot all you care about is the Model -- that's all the stuff that makes the robot work. Something like a list viewport or a 3D render are Views, which are only reading the model state and displaying it. Clicking on stuff gets into the realm of the Controller.

The point is that ideally the Model doesn't know anything about the View or the Controller. Some systems break this rule but for a robot you'd want it strictly enforced. You don't want to have the GUI present (in any form) just to run your robot do you? The point is, it's absolutely correct to focus right now on the Model part of the system and we can figure out the View and Controller parts later.

Adrenalynn

04-23-2008, 08:24 PM

Totally agreed, Meta!

Matt

04-23-2008, 09:45 PM

Totally agreed as well. And it's sooooo refreshing to have a group in here that understands this very fine point of architecture. I can't tell you how many people I have had to debate with that poo-poo the TRS concept not being able to grasp that it's the plumbing and the combining layers that "do stuff" are ABOVE it :)

>>>You don't want to have the GUI present (in any form) just to run your robot do you?

Right! Here is the distinction: the GUI treeview/properties grid tool isn't a controller. It's what I'd call a building/management tool. We haven't even talked about controllers yet. Those are for individuals to tackle in their own way. ;)

Sienna

04-24-2008, 07:00 AM

More people who understand MVC! You cannot imagine all the people I try to explain that architecture at work to.....

Now, I may be misinterpreting things, but don't a good number of systems seem to combine the VC portion?

JonHylands

04-24-2008, 08:08 AM

MVC is a really good theoretical "model". The very first GUI (implemented in Smalltalk, btw, at Xerox PARC) used it, and it is still available as one of the UI paradigms in Squeak, the open source descendant of that system.

For robotics, its definitely the way to go. I can't imagine building a complex robot controller where you don't at least have the view and model/controller split. Its harder to split the model and the controller, because you have to be very vigilant about making sure you don't get any control code inside the model, but you definitely end up with something nice in the end.

Sienna, most windowing paradigms end up combining view and controller because in a GUI, most of the benefits of separating them are theoretical, and end up adding more complexity instead of making it easier to use.

- Jon

Adrenalynn

04-24-2008, 10:31 AM

I like this because now we're heading back to some place we can start getting the code off the PC and on to the 'bot when we're done simulating.

metaform3d

04-24-2008, 11:22 AM

Now, I may be misinterpreting things, but don't a good number of systems seem to combine the VC portion?Yes, mainly as Jon said because it's more difficult to separate View and Controller and the incentives aren't as strong for smaller applications. One big reason to keep them separate is if you want to support scripting. Just as you can factor a product with M-only, you could also create a skew that's M+C but no View. You then just have to lay on a scripting language like Python with hooks for the control objects and you have a version of your system that can do everything the GUI version can do but with no GUI.

LinuxGuy

04-24-2008, 12:08 PM

There's a design concept called Model/View/Controller which I would very much advocate for this project. For running a robot all you care about is the Model -- that's all the stuff that makes the robot work. Something like a list viewport or a 3D render are Views, which are only reading the model state and displaying it. Clicking on stuff gets into the realm of the Controller.
I think this relates directly to the problem I see with PyRo (http://pyrorobotics.org) now. The view is not separated from the model and controller at all. I just need the model and controller parts to be on the robot, if I understand all this correctly. I do want the model to be able to communicate with the view, but I want the view to not be on the robot at all. I don't know if I can separate the view from the model and controller in PyRo (http://pyrorobotics.org/), which would be a shame.

The point is that ideally the Model doesn't know anything about the View or the Controller. Some systems break this rule but for a robot you'd want it strictly enforced.
If the model doesn't know about the controller, how does anything get done? Doesn't the model hold all the parameter information the controller would need to make things happen on the robot?

You don't want to have the GUI present (in any form) just to run your robot do you? The point is, it's absolutely correct to focus right now on the Model part of the system and we can figure out the View and Controller parts later.
I definitely don't want the GUI on the robot in any form. The GUI has to be remote and connect via some form of wireless in my case. I want to be able to build a realistic model of my robot so the right things happen at the right time. I want to be able to run the model with the view to simulate the robot before I connect the model to the controller. Something tells me my understanding of MVC is not quite right though.

8-Dale

metaform3d

04-24-2008, 04:10 PM

I definitely don't want the GUI on the robot in any form. The GUI has to be remote and connect via some form of wireless in my case. I want to be able to build a realistic model of my robot so the right things happen at the right time. I want to be able to run the model with the view to simulate the robot before I connect the model to the controller. Something tells me my understanding of MVC is not quite right though.Yeah I don't think so.

Very briefly: for a robot system the "model" would be the robot itself: the sensor software, the actuator software, and all the logic inbetween. In the real world you just turn it on and let it go. In simulation, however, the model also includes the simulated environment, and the effect of the environment on the sensors and of the actuators on the environment is all part of the extended model.

You could pre-program the whole thing and run it as a batch job on a mainframe, in which case all you need is the model. But you want a GUI both to visualize and manipulate the robot software and the simulation if you have one.

A "view" is anything that reads the model state and displays it to the user. The view does not affect the model, and the model does not know it exists. It just reads the state. The model must normally publish event notification so that it can let any clients know when things change, but the clients are anonymous and may not be there at all.

A "controller" is anything that alters the model. Again the model has to present an API that allows controllers to get in and change things, but the model does not have to be aware of the system that is doing the changing. It should verify its internal state to disallow invalid changes, and it should broadcast any changes to clients (views) so they can update.

The relationship between the view and the controller is mediated by a special addition to the model -- the user model. This models the user's mental state in terms of what they are interested in (selections) and what they intend to do (modes). The view reads this state to show feedback about the user model, and the controller uses this to decide what to act on and how.

LinuxGuy

04-24-2008, 04:27 PM

You could pre-program the whole thing and run it as a batch job on a mainframe, in which case all you need is the model. But you want a GUI both to visualize and manipulate the robot software and the simulation if you have one.
I wouldn't need a mainframe to run my simulation. It can be done right on a PC. Player/Stage (http://playerstage.sourceforge.net/) and Gazebo (http://playerstage.sourceforge.net/doc/Gazebo-manual-0.5-html/group__simulator.html) are robot simulators that run on a PC. These are things TROM might want to connect to at some point.

A "view" is anything that reads the model state and displays it to the user. The view does not affect the model, and the model does not know it exists. It just reads the state. The model must normally publish event notification so that it can let any clients know when things change, but the clients are anonymous and may not be there at all.
This seem reasonable.

A "controller" is anything that alters the model. Again the model has to present an API that allows controllers to get in and change things, but the model does not have to be aware of the system that is doing the changing. It should verify its internal state to disallow invalid changes, and it should broadcast any changes to clients (views) so they can update.
If there is an error, it needs to be returned to the Controller and the Viewer. The Controller can then act to correct it if it is able to or tell the Model it could not. The Model can send an event to with Viewer if one is active.

8-Dale

Sienna

04-24-2008, 07:03 PM

Yes, mainly as Jon said because it's more difficult to separate View and Controller and the incentives aren't as strong for smaller applications. One big reason to keep them separate is if you want to support scripting. Just as you can factor a product with M-only, you could also create a skew that's M+C but no View. You then just have to lay on a scripting language like Python with hooks for the control objects and you have a version of your system that can do everything the GUI version can do but with no GUI.
Scripting! DUH! Silly girl, forgetting that...

So, in this definition, the TROM is both a model and controller, because it's updates the model, but also the robot?

Or are we going to consider the SCL the controller, because it issues commands? In this case, how do we deconflict that we have two models, one physical (the bot itself) one software (TROM)?

Matt

04-24-2008, 07:14 PM

No, no, the TROM is the model. You have to forget about the physical robot. MVC describes a world of software and didn't have anything to do with robotics.

TROM = the model (raw data storage house essentially)
Rendering Tool with no "clickable feedback" = Viewer
Rendering Tool with "clickable feedback" = Viewer/controller
Treeview/properties grid control = controller (with some viewer in there I guess)
SCL = nothing in the MVC

It doesn't all line up perfectly of course. Neato though :)

Alex

04-24-2008, 07:32 PM

I can't describe just how satisfying of a feeling it is knowing that the way Matt and I originally architected the TROM actually has a name and has been used in the past:D We beat our heads together for months on end trying to figure out this architecture (yeah! now I can call it something, MVC). I just wish I would have known about MVC beforehand because it would've saved a ton of time having a architectural pattern to study instead of coming up with our own pattern:D

Anyway, I'm glad to see that we're (EDIT: starting to be) all on the same page here! Now we can start to move forward and more towards the development page:D

Alex

04-25-2008, 10:27 AM

SCL = nothing in the MVC I'd have to disagree with that Matt. From what I've read and understood about the MVC, the SCL is a controller.

Taken from the MVC Wiki (http://en.wikipedia.org/wiki/Model-view-controller):

Controller

Processes and responds to events, typically user actions, and may invoke changes on the model.

Matt

04-25-2008, 10:41 AM

Yeah, I guess I can see that. Sensor data input is inbound to the model updating it. I will whip myself in penance. My pain will be your joy.

LinuxGuy

04-25-2008, 03:57 PM

I'd have to disagree with that Matt. From what I've read and understood about the MVC, the SCL is a controller.
This means the SCL would be a library of executable code then. It would not just be classes the Model or API uses to instantiate Objects used to interface with the sensors and actuators/controllers.

Maybe it's really the API that is the Controller, since the upper level software would be making API calls, which would cause Objects to be instantiated for interfacing with the robot's hardware (sensors, actuators, and/or controllers).

However, the Model is going to have to instantiate Objects also or it can not do its job at all. I'm trying to get my head around all this and all that's happening is my head starts to hurt.

8-Dale

Matt

05-06-2008, 11:21 AM

UPDATE: I just wanted to give everyone a quick update. Even though the forums have gone quiet we are working on things behind the scenes. Now that we have a clear picture of what needs to be done and what technologies we will be using Jodie and I are working on a white paper which will serve as a full summary of the project and goals. I will be circulating this paper through the education and business communities to widen the support base for the project. Alex is also cleaning up the old TROM and supporting code and will be handing this over to Jodie for her perusal on the port to C++. It will probably be a few weeks before we resurface, but as always people can discuss away here in the forums :)