[srobo-devel] Manual Control Interface

[Tom Leese]

Hi,

The manual control interface was great for debugging, and it’s a pity that it is not enabled on the tablets. Although the functionality is there on the client-side, it was never finished in herdsman and sr-robot. I’m going to attempt to rectify this before Kickstart. My plan of action is (sadly a lot of what needs to be done is down to the software being very Linux centric, but oh well):

- (Port libkoki to non-Linux machines.) — while this was originally a goal of mine, this seems infeasible in the time-scale, so I’ve decided to ignore this for the moment.
- Port ‘sr-robot’ to use ‘pyserial’ over ‘pyudev’ (to support non-Linux machines).
- Allow ‘sr-robot’ to run without ‘pykoki’ (make it an optional dependency).
- Add some tests for ‘sr-robot’ — just to check the ‘pyserial’ port worked.
- Implement the manual control interface in Herdsman.
- Check it all works with the tablet.

If anyone has any comments or thinks there is a better way of doing this, let me know. I’ll be doing this in a ‘manual-control-interface’ branch of both ‘sr-robot’ and ‘herdsman’.

Tom

[Richard Barlow]

Hi Tom,

Thanks for sorting this out before Kickstart. Why does all of this need to
work on non-Linux machines? Surely everything runs on the Odroid?

Rich

Hi,
The manual control interface was great for debugging, and it’s a pity that
it is not enabled on the tablets. Although the functionality is there on
the client-side, it was never finished in herdsman and sr-robot. I’m going
to attempt to rectify this before Kickstart. My plan of action is (sadly a
lot of what needs to be done is down to the software being very Linux
- (Port libkoki to non-Linux machines.) — while this was originally a goal
of mine, this seems infeasible in the time-scale, so I’ve decided to ignore
this for the moment.
- Port ‘sr-robot’ to use ‘pyserial’ over ‘pyudev’ (to support non-Linux
machines).
- Allow ‘sr-robot’ to run without ‘pykoki’ (make it an optional
dependency).
- Add some tests for ‘sr-robot’ — just to check the ‘pyserial’ port worked.
- Implement the manual control interface in Herdsman.
- Check it all works with the tablet.
If anyone has any comments or thinks there is a better way of doing this,
let me know. I’ll be doing this in a ‘manual-control-interface’ branch of
both ‘sr-robot’ and ‘herdsman’.
Tom
--
You received this message because you are subscribed to the Google Groups
"Student Robotics Development" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Jeremy Morse]

Hi,

Great stuff Tom, thanks for driving this. I too tend to take the view
that it's less important to support non-linux things when we have a
single use case.

Am I right in recollecting that deploying this doesn't require the
"robotd" concept, because in the configuration where this is just used
to test the robot itself, no other software is running?

--
Thanks,
Jeremy

[Tom Leese]

Hi,

Post by Jeremy Morse
Great stuff Tom, thanks for driving this. I too tend to take the view
that it's less important to support non-linux things when we have a
single use case.

Yeah, I do basically agree. However, my *only* computer at the moment runs Mac OS X so that’s the reasoning behind porting stuff to be non-Linux compatible. :)

On the other hand, it’s never a bad thing to increase the potential for users and when it comes to testing the boards (which I believe is happening in Southampton) it’ll be useful to have a Python library for interacting with the boards that works on any computer.

Post by Jeremy Morse
Am I right in recollecting that deploying this doesn't require the
"robotd" concept, because in the configuration where this is just used
to test the robot itself, no other software is running?

I must admit I’m not too familiar with the ‘robotd’ concept (although perhaps I know it by another name…), but I don’t believe this requires it, correct.

Tom

[Murray Colpman]

I must admit I’m not too familiar with the ‘robotd’ concept (although perhaps I know it by another name
), but I don’t believe this requires it, correct.

Robotd was a concept that I was going to attempt to implement for my
internship, but unfortunately the idea was dropped before I had really
started. It was the idea to have a daemon through which all direct
hardware communication will be handled, so that (what was at the time)
the user's instance of pyenv and anything else running on the robot
could communicate with the hardware at once without any issues like
things being in the wrong state, etc..

Tom and I were discussing ways to get around this issue. I don't think
the plan was to only allow it to be used when code isn't running, as
that would defeat the major use-case of using it to see live-updating
(eg) servo positions as the code is running. Though having said that, an
MCI that can be used only when code isn't running is better than no MCI
at all.

We were going to look into the possibility of fiddling with how the
Robot object works, in particular the idea of making it a singleton,
which would also very neatly solve the "I've initialised Robot twice and
now everything is broken" gotcha. But since neither of us quite remember
how the sr-robot software and herdsman actually work/interact at the
moment (in particular, it would require the user's code and the code
handling the MCI to be able to run in the same process), we understand
that this might not be feasible after all and we might have to throw
this idea out. It's not the neatest of ideas, in any case; I'm told it's
not particularly Pythonic.

During this conversation I had completely forgotten about the idea of
robotd. At this stage, it might be a very sensible possibility.


Murray.

[Rob Spanton]

Hi Tom,

Post by Richard Barlow
Thanks for sorting this out before Kickstart. Why does all of this
need to work on non-Linux machines? Surely everything runs on the
Odroid?

Indeed, everything runs on the ODROID, so there is not really any need
to invest time in running it on other platforms.

Post by Richard Barlow
If anyone has any comments or thinks there is a better way of doing
this, let me know.

Yes, run it in a VM if you do not have a Linux machine. Most modern VMs
will allow you to easily do USB pass-through, so you will be able to
have it talk to whatever hardware you are looking for.

There is a broader issue to-do with using a manual control interface
(MCI) as currently implemented within the tablet-interface. Running the
MCI in parallel with the user code will not only cause confusion on the
user's part, but also violate various locking requirements relating to
the hardware's use within the current software.

Recall that the MCI from the previous software arrangement was deployed
as a separate robot.zip, which meant that only the user code *or* the
MCI could be used at one time. This is because the MCI would run in the
place of some user code.

There are at least two solutions to this:

1) Implement the option of having user-provided tabs (or pages, or
whatever the term is) within the tablet interface that are served
from the user's code. Then implement the MCI as some alternative
user-code that uses this feature. Users would then use this in a
pretty similar manner to before.

2) Implement a hardware multiplexing daemon. (This is robotd.)

Option 1 is the most straightforward approach, and results in an
extremely useful feature for users too (that provides many possibilities
for them -- e.g. displaying their robot's current belief map on the
tablet). I highly recommend going down this route. The tricky bit of
this is working out how to integrate request handlers and such into
their code in a way that shares context suitably and doesn't require an
entire API rewrite.

robotd is for another day, and possibly not even another day, but right
now isn't the time to get into that discussion I think.

Also, there's no need to rush this through for Kickstart, as this can be
deployed at any point.

Cheers,

Rob

[Tom Leese]

Hi,

Post by Rob Spanton
Yes, run it in a VM if you do not have a Linux machine. Most modern VMs
will allow you to easily do USB pass-through, so you will be able to
have it talk to whatever hardware you are looking for.

Good point. The allure of porting stuff to non-Linux was clearly too tempting!

What is currently the most SR-friendly Linux distro? Fedora seems to be the popular choice, right?

Post by Rob Spanton
Option 1 is the most straightforward approach, and results in an
extremely useful feature for users too (that provides many possibilities
for them -- e.g. displaying their robot's current belief map on the
tablet). I highly recommend going down this route. The tricky bit of
this is working out how to integrate request handlers and such into
their code in a way that shares context suitably and doesn't require an
entire API rewrite.

I agree this is the way to go, and there is the functionality there in the tablet interface to support custom pages, so let’s do this.

Post by Rob Spanton
Also, there's no need to rush this through for Kickstart, as this can be
deployed at any point.

Would certainly be nice to have it for the microgames though. I’m sure I can get it done with help from people in Southampton.

Tom

[Rob Spanton]

Post by Tom Leese
What is currently the most SR-friendly Linux distro? Fedora seems to be the
popular choice, right?

I would recommend doing it in a Fedora VM, as the ODROID software is all based
on Fedora. Fedora provide a server "cloud image" that may suffice as a base,
but I have not yet had the chance to evaluate it.

Cheers,

Rob

[Tom Leese]

Hi,

Post by Rob Spanton
I would recommend doing it in a Fedora VM, as the ODROID software is all based
on Fedora. Fedora provide a server "cloud image" that may suffice as a base,
but I have not yet had the chance to evaluate it.

VM configured and working! I stuck with the ‘Workspace’ variation, ‘Cloud’ looked like it was going to take a bit of work to get set-up. I won’t bother with the non-Linux porting stuff I had on my todo list.

Although unrelated to what I need to be doing, I just wanted to know what people thought about me moving the ‘herdsman’ package into the ‘sr’ namespace as with ‘comp’, ‘tools’ and ‘robot’. Since nothing except herdsman itself uses that API and since ‘bin/herdsman’ won’t change, I think it’s a fairly safe move, and it makes me feel a bit better having all stuff nicely organised. Assuming no one has any objections, I will make that change as part of my exploration of the manual control interface.

Tom

[Tom Leese]

Hi,

I’ve thought about this some more and decided what I think to be the best course of action.

When you create a Robot instance, it also runs a web server (WAMP, normal HTTP whatever (probably WAMP)) which is used to expose custom pages, pub/sub and RPC calls. The API will look something like this:

@R.tablet.custom_page(‘Belief Map’)
def my_belief_map():
return ‘<h1>Some HTML</h1>’

@R.tablet.procedure(‘my_belief_map’)
def get_my_belief_map():
R.tablet.publish(‘belief_map_retrieved’)
return [{‘x’: 0, ‘y’: 0, ‘width’: 100, ‘height’: 100, ‘what’: ’robot’}]

@R.tablet.subscribe(‘belief_map_retrieved’)
def tablet_did_something():
print(‘Tablet attempted to get my belief map.’)

@R.tablet.procedure(’dance’)
def dance():
R.motors[0].m0.power = 100
time.sleep(1)
R.motors[0].m1.power = 100
time.sleep(1)
R.motors[0].m0.power = 0
R.motors[0].m1.power = 0

I can’t decide whether to use something more generic than ‘R.tablet’, perhaps ‘R.interface’ or something, some thoughts on that would be good?

So there will be two WAMP/HTTP servers: Herdsman and Robot. Herdsman will deal with “low-level” stuff like starting/stopping the robot and reading the logs. Robot will deal with the “high-level” stuff like implementing a manual control interface. Herdsman will be running for as long as the robot is switched on, Robot will be stopped and started as the user code changes.

We could also embed a “default” MCI in the standard Robot instance which can be added with “R.enable_manual_control_interface()” or something.

I’ll also have to make the API for using WAMP through Polymer slightly more pleasant, and also make sure to take into account this difference between the two servers.

Any thoughts on my proposal is appreciated.

Tom

Post by Tom Leese
Hi,

Post by Rob Spanton
I would recommend doing it in a Fedora VM, as the ODROID software is all based
on Fedora. Fedora provide a server "cloud image" that may suffice as a base,
but I have not yet had the chance to evaluate it.

VM configured and working! I stuck with the ‘Workspace’ variation, ‘Cloud’ looked like it was going to take a bit of work to get set-up. I won’t bother with the non-Linux porting stuff I had on my todo list.
Although unrelated to what I need to be doing, I just wanted to know what people thought about me moving the ‘herdsman’ package into the ‘sr’ namespace as with ‘comp’, ‘tools’ and ‘robot’. Since nothing except herdsman itself uses that API and since ‘bin/herdsman’ won’t change, I think it’s a fairly safe move, and it makes me feel a bit better having all stuff nicely organised. Assuming no one has any objections, I will make that change as part of my exploration of the manual control interface.
Tom
--
You received this message because you are subscribed to the Google Groups "Student Robotics Development" group.
For more options, visit https://groups.google.com/d/optout.

[Tom Leese]

Hi,

Since I last worked on the tablet interface/Herdsman, Autobahn (the library to use WAMP) has changed a bit. It no longer contains a WAMP router and instead the recommendation is to use http://crossbar.io/.

This actually makes things a little simpler for us, we only need to run one WAMP server (they call these parts routers) instead of two. The Herdsman WAMP application and the Robot WAMP application exposes stuff on the same WAMP router (using different ‘realms’) and the tablet interface can still connect to a single router as before. The complication being that we now need to run a crossbar.io instance on the Brain Board. Is this still something that could be added retrospectively with an update or does this need thought now?

Tom

Post by Tom Leese
Hi,
I’ve thought about this some more and decided what I think to be the best course of action.
@R.tablet.custom_page(‘Belief Map’)
return ‘<h1>Some HTML</h1>’
@R.tablet.procedure(‘my_belief_map’)
R.tablet.publish(‘belief_map_retrieved’)
return [{‘x’: 0, ‘y’: 0, ‘width’: 100, ‘height’: 100, ‘what’: ’robot’}]
@R.tablet.subscribe(‘belief_map_retrieved’)
print(‘Tablet attempted to get my belief map.’)
@R.tablet.procedure(’dance’)
R.motors[0].m0.power = 100
time.sleep(1)
R.motors[0].m1.power = 100
time.sleep(1)
R.motors[0].m0.power = 0
R.motors[0].m1.power = 0
I can’t decide whether to use something more generic than ‘R.tablet’, perhaps ‘R.interface’ or something, some thoughts on that would be good?
So there will be two WAMP/HTTP servers: Herdsman and Robot. Herdsman will deal with “low-level” stuff like starting/stopping the robot and reading the logs. Robot will deal with the “high-level” stuff like implementing a manual control interface. Herdsman will be running for as long as the robot is switched on, Robot will be stopped and started as the user code changes.
We could also embed a “default” MCI in the standard Robot instance which can be added with “R.enable_manual_control_interface()” or something.
I’ll also have to make the API for using WAMP through Polymer slightly more pleasant, and also make sure to take into account this difference between the two servers.
Any thoughts on my proposal is appreciated.
Tom

Post by Tom Leese
Hi,

Post by Rob Spanton
I would recommend doing it in a Fedora VM, as the ODROID software is all based
on Fedora. Fedora provide a server "cloud image" that may suffice as a base,
but I have not yet had the chance to evaluate it.

VM configured and working! I stuck with the ‘Workspace’ variation, ‘Cloud’ looked like it was going to take a bit of work to get set-up. I won’t bother with the non-Linux porting stuff I had on my todo list.
Although unrelated to what I need to be doing, I just wanted to know what people thought about me moving the ‘herdsman’ package into the ‘sr’ namespace as with ‘comp’, ‘tools’ and ‘robot’. Since nothing except herdsman itself uses that API and since ‘bin/herdsman’ won’t change, I think it’s a fairly safe move, and it makes me feel a bit better having all stuff nicely organised. Assuming no one has any objections, I will make that change as part of my exploration of the manual control interface.
Tom
--
You received this message because you are subscribed to the Google Groups "Student Robotics Development" group.
For more options, visit https://groups.google.com/d/optout.

[Rob Spanton]

Hi Tom,

@R.tablet.procedure(’dance’)
R.motors[0].m0.power = 100
time.sleep(1)
R.motors[0].m1.power = 100
time.sleep(1)
R.motors[0].m0.power = 0
R.motors[0].m1.power = 0

Whilst this is easy to read, I think it kind of misses some of the
issues with actually using this interface. The challenging things to
deal with when using this interface will be the fact that the RPC
handler will need to execute in a separate context to that which the
user code runs.

The following basic code should illustrate this point:

from sr import *
import time

R = Robot()

some_thing = 0

@R.remote.procedure("my_belief_map")
def stuff():
return some_thing

while True:
some_thing += 1
time.sleep(1)

Even with a single integer the above code is somewhat nasty (relies on
the global variable permeating into the stuff() function's thread). As
soon as `some_thing` gets more complicated (e.g. two variables), locking
will likely be required to mediate access to it. That makes the
mainloop code and the RPC code somewhat more complicated.

So whilst the syntactic sugar looks nice on the surface, I think it
tricks the reader of the code into believing that their RPC handler will
run in the same execution context as the `While True` loop at the bottom
of it.

(Side note: This is exactly the kind of thing python flask does, which
is fine for its normal applications -- those in which there isn't really
shared state between RPC handler invocations. In flask, you don't
generally care what thread or process your handler gets called in.
Where is there shared state in flask it's usually within a database --
and databases have an API that is robust to access from multiple
contexts. When you do have to deal with in-process shared state in
flask it's not the most straightforward thing to do I find.)

Also, one wouldn't want (in basically all applications except the MCI)
to have the RPC handler locking some state that the mainloop needed to
access, as this would mean the mainloop (i.e. main robot behaviour)
became somewhat dependent on the servicing of the RPC handlers in a
timely fashion etc. Not good when you may want your mainloop to be able
to respond to some events within a reasonably short period of time.

Another thing to add about the above API is that I don't think there is
a need for the 'tablet' variable to be a member of the Robot object. It
could instead have sat in sr.robot.tablet (or under whatever name was
appropriate) and achieved the same thing. It'd require explicitly
starting by the user, but that would be fine.

I think a less hard-to-debug-bug-inducing, but more flexible way to
present this interface would be to do something along the lines of the
following:

1. Forward requests to /user on the herdsman HTTP server through to
local port N, and document that this is the case. (Forwarding from
/user to a port avoids cross-site scripting and hostname wrangling
issues on the browser side.)

2. Don't provide a decorator-type interface as illustrated above, and
leave it to the user to determine what sort of serving mechanism is
employed. After all, it is easy to start an HTTP server in Python
in many many different ways [1], and we're not looking to constrain
people to using one. Of course, we can provide examples in our docs
that use specific solutions.

I can’t decide whether to use something more generic than ‘R.tablet’,
perhaps ‘R.interface’ or something, some thoughts on that would be
good?

I think 'tablet' is probably not the way to go. Perhaps "remote" would
be more appropriate, as it is accessible remotely from a variety of
things.

So there will be two WAMP/HTTP servers: Herdsman and Robot. Herdsman
will deal with “low-level” stuff like starting/stopping the robot and
reading the logs.

Yes, this is what I expect. Although I would prefer the name "user
server" or "user-side server" for what you have termed "Robot" above, as
it removes loading the term "Robot" even further.

Cheers,

Rob

[1] e.g. flask, Twisted, unicorn, SimpleHTTPServer, ... the list goes on
for several years.

[Tom Leese]

Hi,

I wanted to avoid just letting users create their own HTTP server and instead provide comprehensive documentation on how threads/contexts work. However, I can see the benefits of letting the users do it themselves with similar documentation but perhaps also providing a built-in optional Twisted-based (easiest way to combine WAMP and HTTP on Python 2) server with a set of useful features (perhaps something for further down the line).

One of the advantages I had to making the API more high-level is that we could automatically publish servo/motor change events allowing the pages on the tablet to be more dynamic with less work from the users. However, we could instead provide a way of ‘registering’ to servo/motor change events and then let the user code call the publishing as they want.

I’m happy to go down the expose ‘/user’ route from Herdsman though — and we can define a standard way of exposing custom pages via ‘/user/pages’ or something which returns some documented JSON. I think we’ll still need to switch to using crossbar.io to allow the robot code to join the WAMP router and let components in the tablet interface communicate with the user code.

So, my plan of action is now:

- Remove the /custom_pages route from Herdsman.
- Add a /user route in Herdsman which proxies requests to the user-code.
- Define a standard way of creating custom pages through ‘/user/pages’.
- Switch Herdsman over to using crossbar.io as a WAMP router.
- Produce documentation on how to connect to the WAMP router.
- Simplify how to use some of the components built into the tablet interface.
- Make the manual control interface as a separate robot.zip but making use of the components built into the tablet interface making it super easy for people to make their own customised version.

Also, just to clarify, I think it’s reasonable to say that ‘/user’ won't work in competition mode.

Tom

[Rob Spanton]

Hi Tom,

Post by Tom Leese
Although unrelated to what I need to be doing, I just wanted to know
what people thought about me moving the ‘herdsman’ package into the
‘sr’ namespace as with ‘comp’, ‘tools’ and ‘robot’.

The reason I have not placed herdsman within this namespace is that I
didn't really have any compelling reason to do so...

Cheers,

Rob

[Tom Leese]

Hi,

Post by Rob Spanton
The reason I have not placed herdsman within this namespace is that I
didn't really have any compelling reason to do so…

There is certainly no technically compelling reason to do so, but I think it is good to do so just to keep our code well organised.

Tom

[Tom Leese]

Hi,

Progress!

After a number of changes to Herdsman and the tablet interface, I’ve got custom pages basically working.

The attached robot.py produces the custom page as shown in the screenshot. Obviously it’s a very rudimental example, but it works. The custom pages appear in the navigation bar when the user code is run and disappear when it is stopped. It’s also worth noting the only reason I needed to set the ‘Access-Control’ header was because I have a few levels of proxying going on from my Linux VM.

The code for the tablet interface is in a ‘custom-pages’ branch. I couldn’t make a new branch on ‘brain/herdsman’ so that’s not available for viewing yet.

Herdsman is also running via Crossbar.io now, so the user code can register procedures and subscribe to topics on the same WAMP router.

Tom

[Jeremy Morse]

Hi,

Pseudo-bump: is there progress on the manual control interface? It'd be
great if we could present it at Kickstart this year.

--
Thanks,
Jeremy

[Tom Leese]

Hi,

Post by Jeremy Morse
Pseudo-bump: is there progress on the manual control interface? It'd be
great if we could present it at Kickstart this year.

Progress has been paused as I’ve been focussing on the microgames and introducing new people to Student Robotics. It is something I would like to achieve though, so I do hope to get it working at Kickstart — or at worst, very shortly after.

Tom