WEEK TEN
The last week was spent at the Muscatatuck Urban Training Center for testing the robots.We arrived on Sunday afternoon and set up our workspaces and tools.
At this point, different aspects of the system had to be integrated into the software lib ex- Cameras, SLAM system, STOP Sensor Motor Control and so on. I spent the first few days assisting with the integration and the latter part of the week was spent in testing the code and observing robot behavior in different environments.
We faced rough weather for the first 3 days and so they were devoted to software development and programming. My program could not be tested until the basic code for motor & driver control was written and executed. After this part was written, I wrote the LCM code and modified the main motor controller to include messages and information from my sensor.
I wrote LCM for the first time and this was an amazing learning experience. LCM is a set of libraries and tools for message passing and data marshaling, targeted at real-time systems where high-bandwidth and low latency are critical. It provides a publish/subscribe message passing model and automatic marshaling/un-marshalling code generation with bindings for applications in a variety of programming languages. It was originally designed and used by the MIT DARPA Urban Challenge Team as its message passing system.
LCM is designed for tightly-coupled systems connected via a dedicated local-area network. It is not intended for message passing over the Internet. LCM has been developed for soft real-time systems: its default messaging model permits dropping messages in order to minimize the latency of new messages.
Some of the files/ code written was:
stop_obstacle_t
stop_obstacle_t.h
The motor controller program subscribed to the 'channel' for the 'STOP SENSOR' to receive updates for the status of safety. Some changes were made to the main controller file to 'kill' the motor if the channel read a 'S' character for stop.
The figure below is a screen shot of the working processes during final testing.
At this point, different aspects of the system had to be integrated into the software lib ex- Cameras, SLAM system, STOP Sensor Motor Control and so on. I spent the first few days assisting with the integration and the latter part of the week was spent in testing the code and observing robot behavior in different environments.
We faced rough weather for the first 3 days and so they were devoted to software development and programming. My program could not be tested until the basic code for motor & driver control was written and executed. After this part was written, I wrote the LCM code and modified the main motor controller to include messages and information from my sensor.
I wrote LCM for the first time and this was an amazing learning experience. LCM is a set of libraries and tools for message passing and data marshaling, targeted at real-time systems where high-bandwidth and low latency are critical. It provides a publish/subscribe message passing model and automatic marshaling/un-marshalling code generation with bindings for applications in a variety of programming languages. It was originally designed and used by the MIT DARPA Urban Challenge Team as its message passing system.
LCM is designed for tightly-coupled systems connected via a dedicated local-area network. It is not intended for message passing over the Internet. LCM has been developed for soft real-time systems: its default messaging model permits dropping messages in order to minimize the latency of new messages.
Some of the files/ code written was:
stop_obstacle_t
stop_obstacle_t.h
The motor controller program subscribed to the 'channel' for the 'STOP SENSOR' to receive updates for the status of safety. Some changes were made to the main controller file to 'kill' the motor if the channel read a 'S' character for stop.
The figure below is a screen shot of the working processes during final testing.
The following picture was taken during final testing. The robot successfully stopped when it approached the stairs.
We tested the sensor with different speeds, gradually increasing it to test the sensor.
The normal operational speed for the robot ( roughly walking speed) was only 50% of the maximum speed. The sensor successfully stopped the robot up to 85% of the maximum speed.
We tested the sensor with different speeds, gradually increasing it to test the sensor.
The normal operational speed for the robot ( roughly walking speed) was only 50% of the maximum speed. The sensor successfully stopped the robot up to 85% of the maximum speed.