Dawn Robotics Forum

Alan,

I've made progress on extending your scratch interface with the Rover 5. I managed to develop a scratchx plugin that has nice clean command blocks that wait for a response before moving onto the next instruction (i.e. getting rid of the clunky broadcasts that used to have).

You can see the plugin at http://scratchx.org/?url=http://bennalar.github.io/rover-ext/rover.js but it won't currently work unless you're running the https://github.com/bennalar/digimakers_scratch_workshop/blob/master/scripts/scratch_js.py python script in the background.

It works fine for the simulator but I had lots of issues with the bluetooth stack so I gave up on that approach. I recently noticed that you've built a python library, so I'm thinking of adapting that instead to work with the scratchx interface. This also means that I can make use of the pi_camera_bot webserver code too as a bonus.

I started porting your code from https://bitbucket.org/DawnRobotics/raspberry_pi_camera_bot/src/89323d4120ea95c897a98948c62305d2ca508096/?at=master but then spotted that you have two branches new-experimental-rover and experimental-rover. I'm going to have a go at using the new-experimental-rover code on my robot to see how that works.

Am I taking the right approach here? I really want to get this up and working before the new term starts. It seems to make sense to use the updated python library rather than the old workshop code.

Cheers,

Phil

Dear Phil,

Sorry for the delayed reply on this. I've got to say, I haven't looked at Scratch for ages as the move seemed to be towards Scratch 2, and with a move to something Flash based it didn't look like it was going to work on the Pi. I have been thinking for a while, that in order to get something like Scratch working with our robot kits on the Pi, then it might be better to use something like Blockly, which is built using just HTML5 and Javascript.

I'd love to know your take on it though, and what your experience has been of using Scratch 2.

Not had time to grok your javascript code, although at a glance it looks great. I would say that for future development, yes you're definitely better off using the work I've done for our Raspberry Pi Camera Robot. Briefly this works by running a Python webserver on a Raspberry Pi which communicates with an Arduino compatible board in order to control the robot's motors, servos etc. If you haven't seen it already then there's a forum post describing the code here.

For our Raspberry Pi Camera Robot kit we use the Mini Driver (a small arduino compatible board) but as you've found we also have an experimental branch which is targetted at controlling the Rover 5 using an Arduino Uno. This was intended to work with our Pi Co-op board, but with a bit of fiddling it should also work with the Seeeduino in the Rover 5 kit.

Once the Raspberry Pi robot is up and running, you can send it commands, and get sensor readings back from it by talking to the webserver using websockets. Now, you can either do this using the py_websockets_bot library, or you can also do this using the websockets functionality in Javascript, which I imagine if it works, could simplify your code setup somewhat. For an example of talking to the robot in Javascript please look at the web interface for the robot here.

Hopefully that all make sense. Please let me know if you have any more questions, or need clarifaction on anything.

Regards

Alan

Alan,

Thanks for your reply. I've now developed the scratchx interface using your API and it works for both the live and simulated environments.

It uses the existing python code to provide an interface between scratch and the robot/simulator. I've just tweaked it so that it works using the scratchx javascript plugin. See basic diagram below.

[ScratchX] <-> [ScratchXPlugin] <---> [Scratch Environment] <---> [Robot Webserver]

Red = Javascript
Blue = Python on client
Green = Python (py_bot_webserver) on robot

It seems to work fairly well but I need to play around with the constants (MOVE_SPEED_PER_SECOND, TURN_SPEED_PER_SECOND, ENCODER_TICKS_PER_CM, ENCODER_TICKS_PER_DEGREE] to make sure that the live and simulator environments tie together better. Any advice on this would be welcomed! I'm happy to give you a demo of this if you want to see it in action?

Cheers,

Phil

Hi Phil,

That's awesome, very nice work.

To get values for the constants I'd advise working from the chassis manual linked from the product page. The manual says you get 1000 encoder ticks over 3 revolutions so I'd assume 330 to 350 ticks per wheel revolution.

If you're still based in the Bristol area and fancy coming over to the BRL at some point, it would be great to see it in action. Drop me an email at info@dawnrobotics.co.uk to arrange a time.

Regards

Alan