I’m always a little scared of applying power to a device after working on it. After flipping the antique switch, I was greeted by the classic 80’s synthetic voice saying “Ready”. It was glorious.
Before powering up the Hero 1, I reviewed the wiring top to bottom. As this was a teaching robot, there were certainly some jenky wiring. Additionally, the fuse blocks were open blocks – seems a bit dangerous to me.
I replaced the wiring from the batteries into the power supply, upgrading the fuse block to an Automotive ATM inline fuse blocks.
Once booted, I was also able to drive it around! (I’ll get video later).
Now that I have the Hero 1 Robot driving and talking, it’s time to think about upgrades required to interface it with a modern CPU. (I did say I was going to ROS enable it right?)
In order to have a modern CPU communicate with the robot, I need a modern serial interface. Turns out the Robot Workshop offers a USB Serial bridge for the Hero 1!
It requires a memory upgrade and a late version ROM, so I picked those up as well.
The Panels of the Hero 1 suffer from the classic yellowing of old plastic. I’m going to see if Retr0bright will help (or hurt). What’s Retr0bright? It’s a chemical process that was developed (or was it discovered) by the console restoration community. If it works on consoles, it should work on robots… I’ll report back.
]]>(Full disclosure – I’m a Development Lead at Microsoft in the Edge Robotics team – working on ROS within the Core Operating Systems group. This project is not endorsed by or funded by Microsoft)
ROS enforces a “separation of concerns” – Sensors, Compute and Actuators are separated from each other using a “pub/sub” messaging model.
The HERO 1 uses a Motorola 6808 Microprocessor with 4kb of RAM. This obviously won’t run ROS or a modern operating system; but is it enough to run the motors and sensors?
Let’s Try it!
But first, I need to get it up and running.
For a 35 year old Education robot, I think it is in relatively good shape. I’ve ordered manuals and some upgrades – including a USB interface…
My plan:
Until Next time….
]]>I found a complete Hero 1 robot on eBay, and had to have it! It has sat on a a shelf for over a year now. I was recently inspired by a restoration video to fix it up.
Through the grapevine, I was introduced to a Robotics historian, who has a cache of components – and upgrades!
Over the next few weeks, I’m going to be doing a teardown, cleanup and rebuild… I’ll post progress shots. Maybe even do videos…
If you are reading this – cool. It’s been forever since I posted.
I work professionally with the Robot Operating System – ROS…. Once it is up and running – maybe I’ll ROS enable it.
Because.
]]>The Windows Developer Program for IoT – a version of Windows 8.1 for the Intel Galileo – was the first big project to come out of Windows specifically for Makers, and was collaboration between the Maker team and the Windows Embedded team.
WindowsOnDevices.com is out launch point for our Maker engagement.
With Windows 10, many of the learnings of the developer program are coming to light. I can’t wait to play – both professionally and personally…
What am I going to build? What are you going to build?
]]>Ecogeek has a post about the same thing – and drew similar conclusions. Worth the read.
]]>For Fabr v3, I wanted to see if I could replace the Y axis with a replaceable platform, driven by an edge motor. With this arrangement, I could replace the platform with any length I needed for the job at hand. I’m not quite sure if this will work, but something I’ve been thinking about.
]]>The Fabr motherboard is complete, and the firmware refactor I’ve been working on is ready for testing.
Here are some glamor shots of the motherboard (which are reprap firmware and connector compatible, just in case).
Hoping to have this thing up and running for the Robotics meeting this weekend.
]]>If instead of considering the device itself when coding the logic, what if we were to abstract the meaning of the device from its behavior? That’s the basic idea behind Behavior-Device abstraction.
Say I’m building a Unmanned Aerial Vehicle (UAV). I have a navigation behavior which needs realtime orientation data. A typical orientation circuit requires a Gyro and accelerometer for accuracy and drift compensation. If the navigation system had to deal with those calculations, that code becomes unwieldy. However, if it were coded to a single OrientationDevice, then the implementation of that device could be two sub devices – the GyroDevice and AccelerometerDevice, and can build a homogenized notification of orientation changes. What if a manufacturer were to build a single chip that handles both and provides a single interface to it? All one would need to do is replace out the Orientation device without rewriting the Navigation behavior.
The example above described a composition – Each component has a singular responsibility. These are aggregated into a composite or logical device, which then can be actioned upon or notified from independent of the internal implementation.
RepRap has 1 main behavior – The GCode interpreter. It receives commands from the host machine, and drives two logical components – the extruder and the Cartesian bot. The Cartesian bot is composed of 3 linear actuators. The Extruder has a temperature sensor, heater and feed device.
The RepRap project uses Stepper motors for linear actuation, with end stops for collision avoidance and homing. It could be implemented using a servo motor or linear stepper driver. Since driving the linear actuator is now abstracted from the behavior, changes to the driving mechanism becomes much less complicated.
In other words, the behavior tells the bot where to go, the bot figures out how to get there, and the linear actuators figure out how to do it.
class CartesianDevice : public Device,
public Observable,
public Observer
{
LinearActuator& _x;
LinearActuator& _y;
LinearActuator& _z;
bool _xInMotion;
bool _yInMotion;
bool _zInMotion;
public:
CartesianDevice(LinearActuator& x, LinearActuator& y, LinearActuator& z);
void moveTo(float newX, float newY, float newZ);
void moveHome();
inline bool axesInMotion() { return _xInMotion || _yInMotion || _zInMotion; }
virtual void notify(uint32_t eventId, void* context);
};
class StepperDevice : public EventLoopTimer,
public Device,
public Observable
{
int8_t _stepPin;
int8_t _dirPin;
bool _forward;
int _currentTick;
int _targetTick;
int _ticksPerRev;
milliclock_t _maxRate;
public:
StepperDevice(int8_t stepPin, int8_t dirPin, int ticksPerRev, milliclock_t rate);
void goForward();
void goBackward();
void turn(float numberOfRevolutions = 0.0f);
void start();
void stop();
void setTempRate(float rate);
virtual void fire();
};
class OpticalInterrupt : public Device,
public Observable,
public PeriodicCallback
{
int _inputPin;
public:
OpticalInterrupt(int pin);
virtual void service();
};
]]>