Lego Manifest Question

Hey, I just have a quick question I'm curious about. When I edit the manifest file to support 2 NXT buttons that control the speed of a motor, why do I also have to change the settings in the web interface? I would expect these to be set by the manifest file itself. Am I missing something?

So when I have this as my manifest file:

Code Snippet

<?xml version="1.0" ?>
<Manifest
xmlns:motor="http://schemas.microsoft.com/robotics/2006/05/motor.html"
xmlns:lego="http://schemas.microsoft.com/robotics/2006/05/legonxt.html"
xmlns:bumper="http://schemas.microsoft.com/2006/06/contactsensor.html"
xmlns="http://schemas.microsoft.com/xw/2004/10/manifest.html"
xmlns:dssp="http://schemas.microsoft.com/xw/2004/10/dssp.html"
>
<CreateServiceList>
<ServiceRecordType>
<dssp:Contract>http://schemas.tempuri.org/2007/05/twobuttonsonemotor.html</dssp:Contract>

<dssp:PartnerList>
<dssp:Partner>
<dssp:Name>motor:ControlledMotor</dssp:Name>
</dssp:Partner>

<dssp:Partner>
<dssp:Name>bumper:Bumper1</dssp:Name>
</dssp:Partner>

<dssp:Partner>
<dssp:Name>bumper:Bumper2</dssp:Name>
</dssp:Partner>

</dssp:PartnerList>

</ServiceRecordType>


<!--Start LegoNXT Brick -->
<ServiceRecordType>
<dssp:Contract>http://schemas.microsoft.com/robotics/2006/05/legonxt.html</dssp:Contract>
<dssp:PartnerList>
<!--Initial LegoNXT config file -->
<dssp:Partner>
<dssp:Service>LEGO.NXT.Brick.Config.xml</dssp:Service>
<dssp:Name>dssp:StateService</dssp:Name>
</dssp:Partner>
</dssp:PartnerList>
<Name>lego:Brick1</Name>
</ServiceRecordType>

<!-- Start ControlledMotor -->
<ServiceRecordType>
<dssp:Contract>http://schemas.microsoft.com/2006/06/legonxtmotor.html</dssp:Contract>
<dssp:PartnerList>
<dssp:Partner>
<dssp:Service>ControlledMotor.Config.xml</dssp:Service>
<dssp:Name>dssp:StateService</dssp:Name>
</dssp:Partner>
<dssp:Partner>
<dssp:Name>lego:Brick1</dssp:Name>
</dssp:Partner>
</dssp:PartnerList>
<Name>motor:ControlledMotor</Name>
</ServiceRecordType>

<ServiceRecordType>
<dssp:Contract>http://schemas.microsoft.com/2006/06/lego.nxt.bumper.html</dssp:Contract>
<dssp:PartnerList>
<dssp:Partner>
<dssp:Service>Lego.NXT.Bumper1.Config.xml</dssp:Service>
<dssp:Name>dssp:StateService</dssp:Name>
</dssp:Partner>
<dssp:Partner>
<dssp:Name>lego:Brick1</dssp:Name>
</dssp:Partner>
</dssp:PartnerList>
<Name>bumper:Bumper1</Name>
</ServiceRecordType>

<ServiceRecordType>
<dssp:Contract>http://schemas.microsoft.com/2006/06/lego.nxt.bumper.html</dssp:Contract>
<dssp:PartnerList>
<dssp:Partner>
<dssp:Service>Bumper2.Config.xml</dssp:Service>
<dssp:Name>dssp:StateService</dssp:Name>
</dssp:Partner>
<dssp:Partner>
<dssp:Name>lego:Brick1</dssp:Name>
</dssp:Partner>
</dssp:PartnerList>
<Name>bumper:Bumper2</Name>
</ServiceRecordType>

</CreateServiceList>
</Manifest>


When I run the service for the first time, it takes me to the web interface to enter in the correct COM port. However, the sensors are set to the default (I think it's a touch sensor in port 1, a sound sensor in 2, sonar in 3, and a light in 4.. or something like that). Why isn't my configuration from the manifest file set? Is it because it's getting those selections from the default Brick service? If so, is there better way to do this?

Like I said, this isn't a crucial deal or anything, I'm just curious.

[4423 byte] By [Kexyn] at [2008-1-9]
# 1
I believe the setting your referring to get set in the config file for those services, e.g. LEGO.NXT.Brick.Config.xml, ControlledMotor.Config.xml, Lego.NXT.Bumper1.Config.xml and Bumper2.Config.xml. These config files are referenced by your manifest. I don’t believe the web ui actually can access those (i.e. for security reasons your browser won’t let it access disk for most places).

I think the web ui just sends the setting to the brick, Im still new to this so I'll add a disclaimer here

keith at 2007-10-3 > top of Msdn Tech,Microsoft Robotics Studio,Microsoft Robotics - Hardware Configuration and Troubleshooting...
# 2

Actually i was thinking about this a bit more and its rubbish that the web ui cant change the config, the web ui itself cant but when it post backs to the server side that would be able to so not sure why it doesn’t, perhaps it’d be a bit magic. Maybe a save button would be in order?

keith at 2007-10-3 > top of Msdn Tech,Microsoft Robotics Studio,Microsoft Robotics - Hardware Configuration and Troubleshooting...
# 3

Keith is right. The config files need to be updated.

When writing a service, there is a base method called SaveState(_state). If this method is called after the HttpPost, then it will attempt to save the state back to the config files identified in the manifest. This can fail for security reasons, depending upon your security context, but in general, it works fine. Unfortunately, not every service implements this method. However, I believe the LEGO brick service does -- this is why you don't have to update the settings the second time you run the service.

DaveLee at 2007-10-3 > top of Msdn Tech,Microsoft Robotics Studio,Microsoft Robotics - Hardware Configuration and Troubleshooting...
# 4
This is a little tangential, but bear with me speaking as someone who's wrestled with the manifest editor to configure an NXT recently...

One issue with state configs is that if they're generated by the manifest editor they are likely not initialized the same way their services would initialize them. This can include null references to objects that are usually created at run-time and assumed to be correctly initialized in a persistent state file. I had no end of trouble last week trying to partner the generic differential drive service with two lego motors and encoders, mainly because the differential drive state config needs initialized encoder state members, and these need to be consistent with the actual partnered encoder states. The manifest editor doesn't know anything about these issues because it just calls the default constructor on the state class.

Sorry to go a little OT but when you're building manifests for the NXT with the manifest editor, it's caveat emptor. Be sure your state config files have all the relevant fields initialized and they are consistent across the various services that store duplicates of things like motor and encoder state.

Oh, and while I've got your attention...
Another issue with the NXT config seems to be that the persistent state includes motor power settings, which means that if you stop the service while the robot is moving, the next time you fire it up the robot will jump briefly before some mechanism zeros the motor outputs. It should be straightforward to differentiate between config-time and run-time state in the brick service and ensure that config-time state is what is persisted.

R

RobSim--Braintech at 2007-10-3 > top of Msdn Tech,Microsoft Robotics Studio,Microsoft Robotics - Hardware Configuration and Troubleshooting...
# 5

Hi Rob.

You bring up some good points about the LEGO service. This was one of the first services in MSRS 1.0 -- before VPL, and way before the manifest editor. Unfortunately, the configure is very complex, and it was only ever meant to be updated by using the main LEGO NXT web configuration page. That being said, we've decided to revamp the LEGO services

Announcement: New LEGO NXT services!

We are preparing to ship a new package for MSRS 1.5 containing an all new set of services for the LEGO NXT which greatly simplify using the LEGO from either code or VPL.

With the new set of services, configuration is extremely easy in VPL. These services are in the final stages of testing, and will be released as a stand-alone pagage very soon. Stay tuned.


Dave

DaveLee at 2007-10-3 > top of Msdn Tech,Microsoft Robotics Studio,Microsoft Robotics - Hardware Configuration and Troubleshooting...

Microsoft Robotics Studio

Site Classified