Permalink
Browse files

Add Unit 3 - particle filter implementation.

  • Loading branch information...
andreynech committed Dec 14, 2012
1 parent 6e3d5ac commit d244f8553b7622f2c27e6db7fcd3f73ed7440fcc
Showing with 944 additions and 16 deletions.
  1. +1 −1 README
  2. +10 −7 unit1/README
  3. +3 −3 unit1/localization.py
  4. +2 −0 unit2/README
  5. +3 −5 unit2/kalman.py
  6. +43 −0 unit3/README
  7. +51 −0 unit3/actuators.ice
  8. +19 −0 unit3/admin.ice
  9. +40 −0 unit3/client.config
  10. +372 −0 unit3/homework6.py
  11. +154 −0 unit3/lineutils.py
  12. +42 −0 unit3/plan.dat
  13. +45 −0 unit3/run.gnu
  14. +94 −0 unit3/sensors.ice
  15. +45 −0 unit3/set_robot.gnu
  16. +11 −0 unit3/trajectory.dat
  17. +9 −0 unit3/trajectory.prev.dat
View
2 README
@@ -2,7 +2,7 @@ This repository is for the experimental and demonstration purposes. Programs her
The goal was to introduce as less modifications as possible to the code written and explained in the class. However, there were typically two modifications necessary.
The first set of modifications is to initialize our remoting infrastructure and get connected to the vehicle. For these purposes we introduce the main application class Client which inherits Ice.Application class. Then we move different functions presented in different units into our Client class. And finally, the main application logic resides in the Client.run() function. This function is invoked from Client.main() function within the following typical start-up code fragment:
The first set of modifications is to initialize our remoting infrastructure and get connected to the vehicle. For these purposes we introduce the main application class Client which inherits Ice.Application class. Then we move different functions presented in corresponding units into our Client class. And finally, the main application logic resides in the Client.run() function. This function is invoked from Client.main() function within the following typical start-up code fragment:
if __name__ == "__main__":
app = Client()
View
@@ -2,13 +2,16 @@ Localization example with real robot.
As a robotics platform this example uses hardware and software we are
developing for our Veter-project:
https://github.com/veter-team/veter/wiki . This example example
illustrate how to perform one-dimensional localization using histogram
filter we have learned in Unit 1 of the class. In particular, the left
sonar measures the distance at each step. If the distance is less than
threshold (defined as 30cm), then we consider that the measurement
returns "wall". If the distance is larger than than threshold, then we
assume that we are in front of the door.
https://github.com/veter-team/veter/wiki .
Corresponding sourcs are available here:
https://github.com/andreynech/udacity-cs373
This example illustrates how to perform one-dimensional localization
using histogram filter we have learned in Unit 1 of the class. In
particular, the left sonar measures the distance at each step. If the
distance is less than threshold (defined as 30cm), then we consider
that the measurement returns "wall". If the distance is larger than
than threshold, then we assume that we are in front of the door.
The one second pause between movements is made intentionally to
highlight that we are not in the continuous space. In practice, it
View
@@ -1,11 +1,11 @@
#!/usr/bin/env python
#
# Copyright (c) 2012 Andrey Nechypurenko (andreynech@gmail.com)
#
# The following code is provided as is without ANY warranty. You can
# do whatever you want with it, i.e. modify, redistribute,
# etc. without any restrictions. However, I would appreciate if you
# will mention me as original author.
# will mention Udacity folks as original authors and me as the one who
# adapted it for the real robotics vehicle.
# Andrey Nechypurenko (andreynech@gmail.com)
# Standard set for Ice
import sys, traceback, Ice
View
@@ -4,6 +4,8 @@ real robot.
As a robotics platform this example uses hardware and software we are
developing for our Veter-project:
https://github.com/veter-team/veter/wiki .
Corresponding sourcs are available here:
https://github.com/andreynech/udacity-cs373
In this example, we estimate our own position and speed based on the
rear sonar measurement (distance to the wall). In the Unit 2, several
View
@@ -1,11 +1,11 @@
#!/usr/bin/env python
#
# Copyright (c) 2012 Andrey Nechypurenko (andreynech@gmail.com)
#
# The following code is provided as is without ANY warranty. You can
# do whatever you want with it, i.e. modify, redistribute,
# etc. without any restrictions. However, I would appreciate if you
# will mention me as original author.
# will mention Udacity folks as original authors and me as the one who
# adapted it for the real robotics vehicle.
# Andrey Nechypurenko (andreynech@gmail.com)
# Standard set for Ice
import sys, traceback, Ice
@@ -280,5 +280,3 @@ def run(self, args):
if __name__ == "__main__":
app = Client()
app.main(sys.argv, "client.config")
View
@@ -0,0 +1,43 @@
Robot position estimation using particle filter (CS-373 unit 3) with
real robot.
As a robotics platform this example uses hardware and software we are
developing for our Veter-project:
https://github.com/veter-team/veter/wiki .
Corresponding sources are available here:
https://github.com/andreynech/udacity-cs373
In this example, we estimate robot's position based on the sonar
measurements. There are four sonars available on the vehicle facing
forward, backward, left and right. The robot is programmed to follow
the predefined trajectory through way-points specified in the
trajectory.dat file. In addition, we defined the room plan as a list
of "walls" stored in the plan.dat.
At each way-point we are obtaining sonar measurements. Then, for each
particle we are calculating "ideal" measurement. This calculation is
done by creating equations for two lines the particle belongs to - the
one which is parallel to the particle bearing and the one which is
perpendicular to the particles bearing. Searching the nearest
intersection between these lines and walls gives us the "ideal"
measurement. Corresponding functions are implemented in
lineutils.py. The difference between "ideal" measurement and actual
sonar data is used to calculate the error and the weight of the
particle for re-sampling step.
The video of the experiment could be seen on YouTube:
http://youtu.be/uUOn-zTqZv8
In the small picture, there is a room plan with the trajectory the
robot attempts to follow (green line). Red lines illustrate sonar
directions. Points on red lines correspond to the distances measured
by sonar. These distances are not exactly on the intersection with the
walls because the robot can not follow the ideal path precisely. Dots
spread across the room are particles used in the filter. The red cloud
of particles and camera-like icon represents the final robot position
estimated by the particle filter. As could be seen on the video, the
estimated position is very close to the actual robot position. In our
experiments we were using 500 particles. However, it was hard to see
just 500 particles on the video, so we recorded sonar measurements and
than re-run the filter using 10000 particles for the video. Final
results using 500, 1000 and 10000 particles were identical.
View
@@ -0,0 +1,51 @@
/* Copyright (c) 2012 Andrey Nechypurenko
See the file LICENSE for copying permission.
*/
#ifndef __ACTUATORS_ICE
#define __ACTUATORS_ICE
#include "admin.ice"
module actuators
{
struct ActuatorDescription
{
// Actuator unique (for the group) id
short id;
// For example camera servo
string description;
// Model id
string vendorid;
};
sequence<ActuatorDescription> ActuatorDescriptionSeq;
// Used to tell actuator to make the movement with
// specified speed and distance.
struct ActuatorData
{
// Which actuator
short id;
// In rotations per second. Rotate backwards if negative
float speed;
// In rotations
float distance;
};
sequence<ActuatorData> ActuatorFrame;
interface ActuatorGroup
{
idempotent admin::State* getStateInterface();
idempotent ActuatorDescriptionSeq getActuatorDescription();
void setActuatorsAndWait(ActuatorFrame duties);
void setActuatorsNoWait(ActuatorFrame duties);
};
};
#endif // __ACTUATORS_ICE
View
@@ -0,0 +1,19 @@
/* Copyright (c) 2012 Andrey Nechypurenko
See the file LICENSE for copying permission.
*/
#ifndef __ADMIN_ICE
#define __ADMIN_ICE
module admin
{
interface State
{
idempotent void start();
idempotent void stop();
};
};
#endif // __ADMIN_ICE
View
@@ -0,0 +1,40 @@
#
# The client reads this property to create the reference to the
# "RemoteVehicle" object in the server.
#
# Stringified proxy for sonar sensors
Sonars.proxy=sonars:tcp -h beagleboard -p 10020
# Stringified proxy for chassis motors (left and right track)
Chassis.proxy=wheels:tcp -h beagleboard.lan -p 10010
#
# The client creates one single object adapter with the name
# "Callback.Client". The following line sets the endpoints for this
# adapter.
#
Callback.Client.Endpoints=default
#
# Warn about connection exceptions
#
Ice.Warn.Connections=1
#
# Network Tracing
#
# 0 = no network tracing
# 1 = trace connection establishment and closure
# 2 = like 1, but more detailed
# 3 = like 2, but also trace data transfer
#
#Ice.Trace.Network=1
#
# Protocol Tracing
#
# 0 = no protocol tracing
# 1 = trace protocol messages
#
#Ice.Trace.Protocol=1
Oops, something went wrong.

0 comments on commit d244f85

Please sign in to comment.