That’s all, folks!

SPIRLe has now come to an end, and in a rush to meet our deadline, we’re adding here a final list of features and some screenshots for your perusal.

The final version of SPIRLe can be found here: https://github.com/smelliott/SPIRLe

Here is a final list of functionality we’ve managed to implement (taken from our final report):

1. A demonstrably well-designed drag-and-drop IDE interface that enables chaining of blocks to automatically generate usable and human-readable Python code, and enables running of this code in the bundled-in simulator as well as on the physical robot. The blocks themselves encompass all the basic principles of programming. Additional features such as “snap to closest”, block editing, custom block creation, program saving and loading, block copying and deletion, multiple canvas usage have all been implemented successfully.
2. A component-handling and system architecture middle layer that enables block creation by easy writing of XML specification files and Python code to dictate the block’s behaviour. The blocks can then be combined in a hierarchical manner to create blocks with higher and higher levels of complexity and abstraction while being based on simple instructions that can be interpreted by target machine platforms.
3. A low-level communication protocol that allows high-level instructions written by the user to be translated into suitable instructions across a range of platforms, with the addition of yet more platforms being a fairly easy process.

We believe this delivers on all the aims we started out to achieve at the beginning of this project, and although we’re sad to see it end, we’re excited for the future as this gives us a solid platform to build upon in the near future, on our own time.

And now, as promised, screenshots:

New Features Added for IDE

I have added many new features to the IDE, and I am going to explain them in this post.

Prerequisites of programming the Arduino without the IDE

The Arduino IDE transparently compiles sketches using the gcc-avr cross-compiler package and additional AVR-related tools. The Arduino boards all use AVR chipsets which have their own instruction set so the availability of a cross-compilation package like gcc-avr is essential for creating binaries to run on Arduinos (Arduini?)

Component Handling: The GP2D12 Infrared Rangefinder

While our framework is platform independent, dealing with individual platforms and components requires code written specifically for that task. This post is part of a series looking at the Python code required to interface with these components through Elliott’s low-level pin handling instructions.

WebuiltabotwebuiltabotwebuiltaBOT!

World, say hello to Gearonimo, our custom-built test robot.

He’s a simple chap, a very basic track-based bot powered by the .NET Gadgeteer platform (with power and motor driver/PDB boards), 4 brushless servos with encoders and a few AA batteries. The Polulu Dagu Rover 5 chassis used is a very simple, cheap and flexible one, allowing the addition of multiple components easily, as and when desired, which was the primary reason behind our choosing it. We’re going to use him for testing out new stuff, primarily with the Gadgeteer platform for now.

 

Blockly Integration and the Online Option

Regular component blogging will continue shortly, but first I thought I should write something about what I’ve been up to this week. We’re making good progress with the IDE, but as we planned to take the project to a school this Wednesday I thought it might be worthwhile to try and put together something closer to what we’re looking for in terms of features.

Milestone achieved: HandleyBot compatibility

(Taken from Weekly Report)

Although this week was a little slow for us to begin with due to some heavy-duty Compilers coursework, it was still a relatively successful one as we (again) achieved one of our milestones. We were successfully able to interface our IDE with Edna, one of Dr. Mark Handley’s robots used in COMP1010. We essentially followed the method outlined in the prvious week’s report, but instead of piping the generated code through to the simulator, we sent it over WiFi link to the robot. To automate the arduous process of logging in, establishing the link and copying and executing files, we wrote a small shell script that now does all of the grunt work as soon as one presses “Run” in the IDE, and then the robot begins executing those instructions. This should ensure the user doesn’t have to deal with the cumbersome process of doing all that through the terminal.

FYI, this is the bot you’re looking for:

Milestone achieved: RoboSim compatibility

We took a big step in our progress today by getting our IDE to work with the RoboSim simulator designed by Dr. Mark Handley.

This was done by piping through the auto-generated code (which itself was a major accomplishment for this week) with the socket-programming abstractions added in through to the simulator, and we were able to successfully produce a simple simulation of the robot moving forward and turning right a couple of times.

Here’s a screenshot for some more proof:

Drag and Drop Interface for IDE

Hello, this is my first time writing to post.

It is essential that the interface is good-looking and has drag and drop features, since it is designed mainly for secondary school students. In order to achieve this, we decided to use PyQt for GUI Toolkit. PyQt really works great for this task, since the interface created with PyQt looks nice. I personally did not have any experience with Python before, but it does not seem to be a problem because Python is easy to learn.

Component Handling: The HCSR04 Ultrasonic Rangefinder

While our framework is platform independent, dealing with individual platforms and components requires code written specifically for that task. This post is intended to be the first in a series looking at the Python code required to interface with these components through Elliott’s low-level pin handling instructions.