Update mar 22 new auto updates

 In a effort to keep track of change in Robbies Code a summary of changes and mods we will post a summary of activity 

 

 

March 2026: Swerve Drive Gets Smarter

The swerve drive looked right on paper but had an annoying judder in practice: wheels would oscillate back and forth when trying to hold a near-zero velocity. The root cause was a missing hysteresis band around the wheel flip decision. When a wheel needs to go, say, 91° from its current position, it can either rotate 91° or flip 180° and go 89° the other way — both are mechanically equivalent. Without a proper dead-band, the controller would keep flip-flopping between the two options near the boundary. Adding a 45°/90° hysteresis band eliminated the oscillation.

Two other quality-of-life improvements went in at the same time: a hardware steering limit (MAX_STEERING_RAD) that makes the wheel flip rather than clamp when it hits the physical range, and first-order velocity smoothing (MOTOR_RAMP_TAU) to take the edge off acceleration. The robot moves noticeably more smoothly as a result.

Tunable Firmware Over Serial

One thing worth highlighting: we added a maxrate parameter to the ESP32 steering firmware. Previously, adjusting the maximum stepper speed meant changing a constant, recompiling, and reflashing — a five-minute interruption that breaks your testing flow. Now you send a single serial command:

echo -e "S 800 200 1000\n" > /dev/esp

That sets max rate to 800 steps/s, stall detection timeout to 200ms, and watchdog to 1000ms. The setting is saved to NVS flash and survives a power cycle. To query the current config:

echo -e "q\n" > /dev/esp

This sounds like a small thing but makes a real difference when tuning — try a value, drive the robot, adjust, repeat without stopping anything.

Splitting the Arm's Hardware Interface

The SCARA arm had a different kind of conflict. The arm's vertical axis (joint 0) is a stepper motor driven by a separate ESP32-based controller, while all the other joints use Feetech/ST serial servos. Originally both were lumped into a single ros2_control hardware block, which isn't how ros2_control is designed to work — different hardware interfaces need separate blocks. Splitting them into _j0 (stepper, via stepper_ros2_driver) and _servos (Feetech, via feetech_ros2_driver) cleaned this up properly.

We also added a use_mock_hardware:=true xacro argument so the arm can be launched in simulation mode without any physical hardware attached — useful for testing MoveIt2 motion planning on the desk before trusting the real arm.

---

March 2026: Teaching the Robot to See Low Obstacles

This is the big one from this week, and the one that required the most debugging.

The Problem: The Lidar Is Blind Below 390mm

Robbie's RPLidar is mounted at 390mm above the floor. Its beam is horizontal, so it simply cannot detect anything shorter than that — a 305mm drinks can sitting on the floor is completely invisible to it from a navigation standpoint. This isn't a configuration issue; it's physics.

The RealSense D435 at the front of the robot is mounted at 300mm and has a 57° vertical field of view, so it does see low obstacles clearly. The question was getting that data into the Nav2 costmap properly.

Ghost Obstacles: A 3D Raycasting Problem

We switched the local costmap from a 2D ObstacleLayer to a VoxelLayer, which can ingest 3D pointcloud data and mark obstacles at the correct height. The obstacle marking worked fine — slide a box in front of the camera and it appeared in the costmap immediately. The problem was clearing: when you removed the box, the mark stayed. Move someone's foot through the space and the footprint remained permanently. The robot would start navigating around nothing.

The cause was subtle. The VoxelLayer stores a 3D grid of voxels (cubes). We had it configured with 16 height slices of 5cm each, covering 0–80cm. The lidar clears free space by raycasting — sweeping a beam horizontally at 390mm. That beam only intersects voxel slice index 7 (0.35–0.40m). Obstacle points from the RealSense were marking slices 2 through 6 (0.10–0.30m, the height of a typical low obstacle). The lidar's clearing rays passed right over those slices and never touched them. Once marked, they stayed forever.

The fix is almost embarrassingly simple in hindsight: collapse all 16 slices into one single 80cm-tall voxel.

z_voxels: 1
z_resolution: 0.8   # one voxel covering 0–0.8m

Now the lidar ray at any height within 0–80cm intersects the single voxel and clears the whole column. The 3D height discrimination is gone, but for a local costmap whose only job is to answer "is there something in the way", that trade-off is fine.

The Wrong Topic Name

While digging through the config we found that the pointcloud topic in nav2_params.yaml was set to /front_depth_camera/depth/color/points but the RealSense launch file sets camera_name: front_camera, making the actual published topic /front_camera/depth/color/points. The costmap had been silently failing to subscribe to any pointcloud data at all — which explains why obstacles weren't appearing in the first place. A frustrating but instructive bug: always verify what topics are actually being published before assuming your configuration is working.

---

Fixing the Crab-Walking

With the costmap now working, a different problem became obvious: the robot was navigating like a crab.

On a route that required turning — go forward, turn left, continue — the robot was cutting diagonally across the corner rather than following the path and rotating to face the next leg. Because the RealSense only covers the forward 86°, a robot strafing sideways is effectively navigation-blind in its actual direction of travel. The voxel layer it had just been given was immediately undermined by the robot pointing the camera the wrong way.

This came down to two settings in the MPPI (Model Predictive Path Integral) controller:

1. PathAngleCritic.max_angle_to_furthest: 1.0 — this critic only fires when the robot's heading is more than 1.0 radian (57°) off the path direction. So on a 45° diagonal approach the critic was completely silent, and the robot was free to strafe without penalty. Dropping this to 0.4 radians (23°) means the critic activates much earlier and pushes the robot to align with the path.
2. PathAlignCritic.use_path_orientations: false — the path planner knows what direction the robot should be facing at every point along the path. With this set to false, MPPI was ignoring that information entirely — just trying to stay near the path line without caring about heading. Flipping it to true gives the controller the directional information it needs.

We also raised PathAngleCritic.cost_weight from 5.0 to 12.0 to make it the dominant force when the robot is heading the wrong way.

Robbie 2.0: The Reinvention of a Home-Built Robot

A few months on, the project has evolved significantly.

The original wheel configuration ultimately proved unreliable. While the system functioned and integration with Home Assistant showed promise, performance was inconsistent. The use of ChatGPT was extremely helpful during this phase and accelerated development considerably. However, over time, weaknesses became apparent. The wheel drive assemblies were prone to slipping, and I²C communication with the motor drivers was intermittently unstable. After several weeks of operation, the limitations of the older hardware and software became clear — much of it had not been designed specifically for this application.

The introduction of Claude Code marked a turning point in the project. Development speed increased dramatically. We replaced the original wheels with Waveshare DDSM115 hub motors, which feature integrated rubber tyres and RS485 communication. This change required a complete rewrite of the motor driver software.

The rewrite addressed several architectural weaknesses. The legacy serial data gateway was slow and cumbersome, particularly when handling dual serial ports. Using Claude Code, we restructured the system to:

• Implement proper closed-loop control for the stepper systems

• Read the IMU directly over I²C instead of through a secondary MCU

• Use native serial interfaces rather than custom device abstractions

• Eliminate unnecessary communication layers

One of the most powerful aspects of using Claude Code was its ability to generate complete, production-ready programs from detailed specification files, while referencing similar implementations from related projects. This dramatically reduced iteration time.

As development progressed, driving and navigation testing exposed timing issues and logic flaws. Leveraging AI to generate targeted test code and analyze system behavior proved invaluable. The ability to propose architectural changes — even major ones — and receive complete, coherent code in real time reduced what would traditionally take months into a matter of days. Debugging navigation behavior in particular became far more efficient.

We also completely rewrote the voice recognition and text-to-speech subsystems. These are now hosted via a web server interface, allowing commands to be issued either by spoken input or via text through a browser interface.

Current Status

The system is now significantly more robust and capable:

• Reliable autonomous navigation

• Automatic docking and charging

• Arm control via MoveIt

• Voice command integration

• Local LLM support for general interaction

• Facial recognition with the ability to enroll new users dynamically

• Arm and base pose recording with sequence playback synchronized to voice

Overall, the project has transitioned from a proof-of-concept system built on repurposed components into a far more stable, purpose-designed robotic platform. The acceleration in software development and fault diagnosis has been transformative, enabling rapid iteration and architectural refinement that would previously have been impractical.

Phase 2 Update: Integrating Home Assistant and Wyoming Satellite

As we kick off Phase 2, we’re moving away from our custom speech‑to‑text solution and leaning on Home Assistant as Robbie’s primary voice interface. By piping audio through the Wyoming satellite link and feeding commands into MQTT, we not only gain rock‑solid STT accuracy but also unlock powerful automation hooks:

• Battery Alerts: Whenever Robbie’s battery dips below a threshold, Home Assistant will flash LEDs and trigger a voice warning over the satellite channel.

• Natural‑Language Commands: Spoken instructions matching our custom “command list” get forwarded to ROS as action goals. Anything else is treated as a query and sent to our LLM, using conversational context for sharper, more reliable responses.

• Seamless Feedback Loop: All robot responses—whether status updates or LLM-generated replies—are spoken back via Home Assistant’s text‑to‑speech and broadcast over Wyoming.

With Home Assistant automations handling the heavy lifting, we can rapidly script new behaviors and integrate sensors, without reinventing the wheel on voice processing. Phase 2 promises a smarter, more conversational Robbie—stay tuned!

 

next adding vision 

Robbie Phase 1 complete

 

---

Robbie Phase 1 Complete

Robbie has successfully completed Phase 1, and we now have a fully operational robot capable of performing a wide range of core functions. Key features include:

• Autonomous navigation to any given location

• SLAM (Simultaneous Localization and Mapping) for real-time environment mapping

• Automated docking with the charging station

• Executing navigation sequences, moving between multiple waypoints

• Full MoveIt integration for both arms

• Arm and head coordination, enabling the arms to reach a target while the head tracks it

• YOLOv5-based object detection

• Howie chatbot serving as the onboard AI for conversational interaction and control

• Custom GUI for arm manipulation, wheel status monitoring, sending navigation commands, and triggering preset arm poses

The robot's arms are based on the Aster robot design, which itself is derived from the Poppy platform. They are well-proportioned for the chassis and just clear the deck during motion. The first two joints use 40kg servos, which remain surprisingly cool during operation. We've implemented the ServoEasing Arduino library to smooth out the movements—greatly reducing the initial jerkiness and overall shakiness of the robot. As confidence in the arm kinematics grows, we can safely increase movement speed to produce a more natural and lifelike appearance.

The arms are resin printed, which gives them a clean aesthetic, though long-term durability is still under evaluation. The grippers are currently more placeholders than practical, serving primarily for visual and alignment purposes. Proper pick-and-place performance will likely require a redesign of the grippers—and possibly the entire arm assembly. Once the outer covers are added, we may encounter thermal challenges, but with winter approaching, overheating shouldn't be a major concern. On the plus side, the covers will help keep out dust and foreign object debris (FOD).

---

Phase 2 Plans

Looking ahead, Phase 2 will focus on increasing autonomy, interactivity, and dexterity. Planned milestones include:

• Routine autonomous behaviors – Robbie will regularly roam the house, perform idle animations like fidgeting or muttering, and initiate casual conversation using Markov chains for randomized speech patterns

• Enhanced pick-and-place capabilities – introducing true object grasping, lifting, and positioning using updated grippers and motion logic

• Face detection, tracking, and recognition – allowing Robbie to greet known individuals by name, follow faces during conversation, and log new encounters

• Photo capture missions – patrolling the house while using YOLO to detect interesting objects and take photos automatically

   

  
  
   

---

March updates

Not a good couple of weeks for the robot the torso was to unstable the robot was in danger of tipping over. then the main computer failed long story short i replaced the it with a new I7 main computer. that works much better the WIFI is only 5 but still works. the battery charger started to fail resulting in a shorter run time. the new charger gives a 2 hour run time now. Navigation is starting to head in the right direction. we still get stuck in tight spots we have achieved a few way point navs.

A few thoughts

• charging system needs beefing up we are having wire power loss
• add in the 3rd battery for a extra 18AH
• start navigation tuning with a new map
• see how a boost charge affects run time

using a LLM with vscode has made tuning the robot easier

networks and bugs

 

For the last couple of months I have been chasing bugs first the network was slow which made the robot uncontrollable I switched out the I5 for a RPI5 but had to add a UPS to give the RPI enough power. Better but not enough I switched the middle ware to Zenoh but that required a upgrade to ROS2 Jazzy and Ubuntu 24.4 it soon became apparent that the RPI5 didn’t have the speed to run the complete stack not even enough to run the robot and cameras. I replaced the WiFi in the I5 from a USB dongle to a express WiFi card so we we ran the network at the same speed as the RPI but I was getting packet drop I added a extra WiFi access point tied to the wired network the I5 went from 120 kbit/s to 300 mbit/s a big improvement, we can now run the robot with everything required running with very little lag. The next task was getting auto dock working to dock in reverse in the end it was simpler just to write my own node. With all the systems running on the robot I started having battery fails we replace the battery for the other robot but that didn’t last very long. A bit more digging the robot draws 4 amps for the moment we changed the way we operate by docking the robot between tasks. Now that only left Navigation to sort out after a few days of tuning and reading we adjusted the global cost map inflation to give smooth pathways and the velocity smoother to keep velocities that work with the robot. We can navigate around the house and it will work most of the time still more tuning required but that is for another day. We also started to add the covers on the robot now that we can navigate through door ways it time to put on the torso

 

 

 Robbie now with torso

I wanted to test the navigation system with the whole robot I'm looking at the acceleration profiles and how the robot handles doorways and corridors and just driving in general

 Docking Server

Here is a clip showing the nav2 docking server Robbie is docking forward so we can work on the other systems. I have mapped the un/dock sequence to the joystick this seems to make a good natural work flow. the undock should be called from the BT server before the start of navigation

 October update

Time for another update on robbie after changing the the drive base to the omni_bot base it showed potential but also a lot of short comings the base was to large to consistently go through corridors the structural integrity was compromised. The base was designed with tighter tolerances and greater rigidity also smaller. We now use stepper motors for the steering system with magnetic encoders. and I2C controller motor drivers with encoders . The motor drivers were from the old design and the python driver was a legacy design. The big change was the odometery function using wheel angles and wheel velocity coupled with a gyro, magnetometer that gave a 20cm accuracy after a 16 meter drive. The successful test of the new omometery node I was able to remover the dead encoder wheel and use ROS nav2 with a MPPI controller in OMNI mode using the nav2 docking server the auto dock works with greater reliability and comes with a undock function all this is mapped the joy stick controller. The python controller was starting to be a bottle neck so I rewrote it in CPP with a noticeable speed improvement. 

this is a video of the the base using navi2 to chase the videographer https://youtu.be/5DKG3iNSfLM

and some build photos

 

 

Intergrating Omni_bot and Robbie

I have merged the omni_bot base with the torso of Robbie

The integration of three omni wheels with encoders has significantly enhanced and simplified the robot's odometry. Precise measurements of wheel rotations from the encoders enable accurate localization and mapping of the environment, resulting in more reliable navigation.

By leveraging Nav2 and slam_toolbox for navigation, the robot benefits from powerful out-of-the-box navigation capabilities. These robust ROS packages facilitate autonomous path planning, obstacle avoidance, and efficient goal-reaching, minimizing the need for extensive modifications.

The adoption of the differential drive plugin for navigation has greatly reduced fishing motion in the Y-space, resulting in smoother and more fluid movement

Replacing the RPI4 with an I5 mini PC running Ubuntu 22.4 and ROS Humble significantly boosts computing power and reliability. The I5 mini PC offers faster processing speeds, improved multitasking capabilities, and better software compatibility, simplifying installation and ensuring a stable platform. Eliminating the Timing Issues by Centralizing Nodes on I5: Centralizing all nodes on the I5 mini PC resolves timing issues observed in the previous setup. Improved synchronization and coordination between nodes result in smoother communication and minimized delays, enhancing performance and responsiveness.

Autodock functionality now incorporates strafing moves, enabling precise alignment with the docking beacon. This refinement enhances the accuracy and efficiency of the docking process.

The low power monitor program has been enhanced to incorporate additional functionality. Utilizing a QR marker and the rear-facing camera, the robot can accurately rotate to the correct angle before initiating Autodock. This improvement ensures precise alignment and eliminates potential errors during docking.

Control and day-to-day operation of the robot are seamlessly achieved using the existing chat bot, which now supports custom commands. Unknown commands are recorded for further integration into AIML, continuously improving the system's understanding and response capabilities. Text-based input simplifies interaction, enabling smooth communication between users and the robot platform.

 

 

 

Robbie update

 I haven't done a update in a while Robbie now runs ROS2 humble on a single RPI4

ROS2 humble is at last at the same level as ROS1, but in general it works much better. Navigation is much more stable and works out of the box the ability to do mapping and use move_base at the same time makes mapping quicker. the work flow is now 

• start the robot , 
• launch slam and navigation 
• set points in RVIZ until the map is complete
• save the map in RVIZ

using the way point navigator feature in RVIZ you can set the way points you would

like the robot to traverse press run and the robot moves the course. very little effort required. 

 

 

 

 

Gizmo Update

The last couple of weeks Gizmo has continued testing, the goal has been to make it more reliable and autonomous and we are making progress in that part. The biggest change has been the addition of a microphone array on his head. This was not easy the software only runs on the latest Rasbian, and ROS needs to be installed from source  it took about a week before it was all running.
Gizmos current status is

1. navigation works but still passes to close to objects if we set way points Gizmo will navigate through doors and narrow corridors and still be localized correctly at the end.
2. Moveit will move the arms to a location and track a moving target but the dynamixels servos will overheat after a short time.
3. Auto-docking and battery management work in semi automatic mode only

 The new external microphone opens a lot of potential ideas in a quite room Gizmo will recognize voices out to 2.5 meters with the TV running we are down to about 1 meter. We are using python speech recognizer and Google STT in default mode, snowboy for hot work recognition. it take about 8 seconds from start of command to returned text. the text is passed to a python chatbot for response and action requests are passed to the behavior tree.

Gizmo the new Robbie

Gizmo is a merger of 3 robots
Bentley a smallish robot
Robbie a big Inmoov style robot
Max a navigation test robot
All 3 had design problems Bentley was too small, Robbie was too big and had trouble navigating around the house and Max was a good size but the drive train was fragile. And last of all 3 robots was just too much. Time for a rethink, so I combined the best features of all. The basic style of Bentley the size of Max and the systems and parts of Robbie.
Gizmo was designed

• to be lifted to a workbench for maintenance
  
• small enough to navigate with low resolution sensors
  
• big enough to hold the components with easy access
  
• 5 hour run time
  
• and not look like a box with appendages
  

The first version was made with tubing to check for fits and clearances

Version 2 was mostly 3D printed and a new drive train using sprocket and chain 

RPI Update

Its time for a quick update on Robbie the 2 RPIs are working as expected they both run ubuntu mate now. The problem with espeak stalling was resolved by doing an update. The RPI camera works well and moving it to the 2nd RPI (R2) has increased the frame rate. The autoboot is still causing problems upstart will boot the roscore RPI but using the machine feature to launch services on the second RPI only works with a display running. Robbie's head is not fully assembled in the photo I'm still in 2 minds if I'm going to change it or just reprint it. While launching Robbie's system over three computers is a pain at the moment it has some clear advantages only the core RPI needs to be running to navigate the second runs voice and cameras. The third is for moveit and the AI. Once the boot sequence is functioning as expected, the health monitoring side of the AI will move to R2. Power distribution is becoming an issue now the new system will be one button to start the computers and automatically turn off power after the RPIs have shutdown the other systems will be switched on and off as required with MOSFETs all systems will have a switch or a fuse to disable it if required.

The Rats Nest

The wiring on Robbie has always been a problem and a big source of unreliability, the other issue was the I2C network not being able to put the motor drivers on the motor made the wiring a mess. The L298n motor drivers were bit under powered and standard servos in some of the joint it time for a rethink. I replace the I2C network with RS485 now the drivers are on the motors and the cables use JST XH connectors which makes for cleaner wiring VNH2SP30 and the TB6612FNG dual motor driver have replaced the servo drivers and the L298n. I replace the control board in the servo and used a magnetic encoder with the TB6612FNG but used the gearing this saved a lot of work redesigning the joint. The new network is working and the joint signal stability is better that before.

                                                             

Before

After

   

Robbie Update

Robbie is in the midst of a big update, with the CPU pegged at 100% it left no room for further development also a slight bug would crash the whole robot. My solution was to split up the computers on Robbie He now runs a raspberry pi 3 for low level programs and the main computer runs the higher level programs. The added advantage is Robbie now uses less power and now can run for 4 hours as opposed to 20 minutes before. Previously I used a kinect in the head to do face recognition now Robbie has a RPI camera. Face recognition was never 100% I tried openface and that works better, I just have to get it to run with ROS. Getting ROS to work was difficult using Ubuntu mate 16.4 and Ros kinetic worked but the TTS never worked reliably After switching to Raspbian Jessie and compiling ROS from source it seem to work OK Compiling works better when you increase the swap file size to 1024  

Magnetic encoder gearbox

It's been a while since the last update I have redesigned the gearbox with 2 radial bearings and a thrust bearing. The worm is print in 2 parts this gives a better tooth profile and reduce backlash. The motor driver is now a VNH2SP30 on a custom pcb and still the arduino pro mini. Its now mounted on the gearbox to reduce wiring and make it more modular. After the redesign its not 100% compatible with Inmoov. Communication is now with RS485 each unit is daisy chained from the last again to reduce the wiring clutter. Using cheap motors causes a problem with the PID accuracy mainly due to the higher starting voltage and the resultant jerk on start of movement.

Magnetic Encoders

Robbie is now fully functional again after his computer problems the reason the arms missed commands was due to the controllers resetting. after I supplied power to the USB hubs every thing worked as required.

To increase the accuracy of the arm I started replacing the potentiometers with magnetic encoders to fit the new encoders required a few modification to the gearbox, I incorporated a bearing in the top of the gearbox and a mount for the magnet in the drive gear plus a few extra tweaks to increase the strength of the assembly not all modification will be fitted at the same time some will wait until the next major rebuild

Moveit Update

Robbie's moveit configuration is working again accuracy is 15 cm not very good but magnetic encoders will help plus a better calibration. Obstacle avoidance suffers because planning only just misses the obstacles. Robbie now has a point at node where he will point to a published target pose.

Face recognition

We are now running the COB face recognition package this works well in daylight but the garage is to dark Robbie makes a few errors, I need to add more lights. The AI will say Hello when he first recognises a face then after 5 minutes he will just say Hi. The name of the recognised face is returned to the chat bot so he knows who he is talking to

Object recognition

will recognise a pre programmed object but wont learn a new object because ECTO requires direct access to the kinect driver Freenect uses a different driver and Openni will not work under indigo

2d recognition, shift and surf and not included in the opencv package so its very flaky

Navigation

Increasing the Global inflation will make Robbie plan further away from obstacles.

Autonomous operation

shutdown command will not work when Robbie is started using robot upstart also depth registered points from the top kinect will not always work unless something uses it straight away the lower kinect has the point cloud to laser scan and gives no trouble. I will start face recognition on start up and see if it remains stable. We haven't had any jitters or strange events since we started using the powered hubs for the arduinos. The current high temperatures are causing a few resets I need a bigger fan and more vents in the CPU bay

Robbie's Emotion system

has been turned off for the moment since he spent most of the time bored and kept quoting a markovian chain from Sun Tzu. It needs a lot more configuration and thought but its fun for a while

As the design of Robbie matures I'm starting to add covers to hide the wires and keep dust off electronics but this has induce a few extra problems

1. Heat build up
   more fans need to be included in the design
2. striped out threads
   printed PLA and MDF wont hold a thread for very long so now I will add M3 threaded inserts and M4 rivnuts to the structure

AI Updates

Robbie's computer is still broken so I was able to catch up on some tasks I never had time for.

The potentiometer were never very accurate I have designed magnetic encoders as a replacement they are more accurate and and just plug in the the existing structure they will be fitted on the next rebuild.

The overall control was a very hard to maintain and expand natural language is not very good with robot control some verbs are shown as nouns thus wont be interpreted as commands. In NLTK you can define what words are verbs or nouns but maintaining the files is troublesome, I tried pattern_en but it suffers from the same limitations. I also tried WIT a online language processor the learning curve is too steep and I wanted a local solution. Robbie's chat engine on the other hand works well.

I never really looked into pyaiml's capabilities but it can run system programs with command line args. For testing I reduced the loaded aimls to two one for commands the other for general response.

Of course that just puts me back to where it was before but with a lot more potential. Pyaiml will throw a error message for a unknown command I made it so it will append the command to a aiml file I only have to add the meaning later I can automate this but for now I want control over it, this sort of gives me a learning robot.

One of the intriguing possibilities is to query Knowrob ontologies.

For now I can add the name of a person from the face recognition node.

Next task is to make a semantic map and name the objects so when asked his location Robbie will answer “near the desk in the garage” not x,y,z.

All of Robbie's physical task are now controlled through behaviour trees program with action servers any task can be pre empted and resumed if there is a fault or error condition. The behaviour tree also monitors and controls Robbie emotions tasks will give pleasure doing nothing will result in boredom, when boredom reaches a certain level Robbie will do a random task that varies from uttering a quip using a Markovian chains, moving his head or arms to driving around in circles.

Using simulators like Rviz and Gazebo has made these tasks much easier.

Robbie Upgrade

The original base was causing some problems with arms in the relaxed and travel position the arms

would hit the lower body , I don't want the arms to make Robbie to wide he has enough trouble getting through door ways as it is also I didn't have the time for a total rebuild (moving the wheels further inboard) so I opted for some covers and a redesigned waist joint. I ripped the speakers apart

and put them in the space for the kinect. I have put the kinect back in the head so I can visualise the work space