1
$\begingroup$

BACKGROUND:

I am creating a robot to score the most points in 30 seconds while running autonomously. Naturally, two thoughts come to mind: Linear programming and machine learning.

Linear programming would provide a stable, simple method of scoring points. However, it is limited by what it can do, and optimizing scores would require reworking the entire bot.

PROBLEMS:

The robot and code itself can change, but it is not time efficient due to the fact that it would require completely reworking the code and robot by a single programmer. The robot has to work with what its got.

QUESTION:

Can I create Android Java classes to allow my robot to work the field as an AI and tweak its strategy or course of action based on stats from previous rounds? (Self-Supervised Learning) If it is possible to do, how would I do it?

SPECS:

Max robot size of 18'' cubes

Android Marshmallow

ZTE speed or Motorola moto g gen 2 phones

Multiple inputs from a controlling phone and various sensors

Output to multiple motors and servos

$\endgroup$
3
$\begingroup$

I think the problem you're going to find is that machine learning requires learning. If the goals or objective vary just a little, then manually adjusting the software shouldn't be too difficult (if you programmed it well), and it might only take a few trials for the AI to adjust to the new scenario.

If the objectives change so much that you're looking at "reworking the entire bot," then you're probably also looking at ditching the previous AI and retraining it on the new course.

:EDIT:

I wrote the answer above on my phone over the weekend. I'll add some more content now:

What you're asking for is almost more like consciousness than a "simple task" - you want the robot to be spatially aware of itself, aware of the objectives its been given, how to move around its environment and then how to use its physical structure to achieve the goal. I'm positive this is all very far beyond the scope of the project/competition you're asking about.

The route I would take would be to break each action out into their own functions and then tune each as required. So you might have functions like:

  • Localize - this is how the robot determines where it is. Dead reckoning, localization, SLAM (simultaneous localization and mapping), etc. would exist here.
  • Navigate - this would do pathfinding as required to set waypoints or instructions for how the robot would get from a given start to a given end. Maps and navigation routines like A*, Dijkstra, etc. exist here.
  • Locomotion - this would be the low-level interface between the navigate function and the wheels. Navigate says turn to a heading of XXX degrees and travel YYY centimeters, Locomotion actually does it. Here's where the wheel base, wheel radius, gear ratios, and other parameters related to locomotion reside.
  • Obstacle detection - if required, a detected obstacle could pause the navigate/locomotion routine, update the map with an obstacle, and force a new navigate call to find the best path from the current position to the original destination. Mapping, SLAM, or other detection algorithms could exist here.
  • Manipulate - this would control the device on the robot that is designed to interact with the course.
  • Mission control - this would be the higher-level function that calls everything else.

So, for example, if you were given some arbitrary number of ball locations and told to deposit them in a basket, your code might look something like the following (Matlab) pseudo-code:

function MissionControl()
basketLocation = [xBasket, yBasket];
objective(1).startPosition = [xBall1, yBall1];
objective(2).startPosition = [xBall2, yBall2];
% This continues for all objectives

% All of the objective locations are at the basket, so
% assign all of the objective goals to that location.
[objective.goal] = deal(basketLocation);

for currentObjective = 1:numel(objective)
    currentPosition = Localize();
    path = Navigate(currentPosition, objective(currentObjective).startPosition);
    for currentWaypoint = 1:numel(path)
        Locomotion(currentPosition,path(currentWaypoint));
        currentPosition = Localize();
    end
    Manipulate('get');
    currentPosition = Localize();
    path = Navigate(currentPosition,objective(currentObjective).goal);
    for currentWaypoint = 1:numel(path)
        Locomotion(currentPosition,path(currentWaypoint));
        currentPosition = Localize();
    end
    Manipulate('put')
end

Each subfunction has its own parameters - again, things related to how the robot moves goes in Locomotion(). How the robot 'get's the ball goes in Manipulate(), etc. If you were going to insist on using AI, I would encapsulate each AI routine in a similar manner, such that there are actually several AI routines.

Again, if there are any dramatic changes, such as a dramatically different footprint or something similar, you'll probably need to wind up retraining the AI. If you don't discard the previous AI, then all of the new training is going to try to "fight" its previous learning of how to behave or interact, and the result may not be optimal in either scenario (old or new).

But like I mentioned earlier, any use of AI would, in my opinion, be a big overkill. Parameterize your code - don't use any magic numbers - and you should be able to update/tune your performance relatively quickly by tweaking the configuration parameters.

$\endgroup$
  • $\begingroup$ It may be possible to implement an algorithmic optimization rather than AI, but so much depends on the specifics if your task and robot. This paper (cs.cmu.edu/~cga/papers/cga-icra97alt.pdf) describes some complexities for an inverted pendulum control task. Check out the difficulties for this rather straightforward task. Some of the references cited there might be very helpful to you. $\endgroup$ – SteveO Nov 27 '16 at 18:19
0
$\begingroup$

Robot-Control-Systems are normally designed as Realtime-Systems. Traditionell programming concepts like loops or procedures will not work. Instead a time-based-schedule is necessary:

0 walkforward
1 walkforward
2 stop
3 turnright
4 walkforward
5 stop

The first parameter is the timeindex, and the second parameter is the actual command. This plan has to be generated on the fly, according to the obstacles which can be changed during runtime. The scheduling-plan can be seen like a chessboard notation (1. a2a4 c2d2) but for the domain "robot control".

To create such realtime-plans one possibility is indead machinelearning. The commands of the human-operator will be recorded and set in relation to the current situation. And with a little bit of luck, this will work for new situations. Another (better) solution would be to see this as an np-hard problem like Sudoko or Travelling-salesman: for given situation and a given goal a number of actions has to be found.

The idea of break down a robot-control-system into different modules like lokalize, navigation, locomotion, manipulate and mission control is not bad, but it is only additionell. It is a way for generating the overall realtime-plan.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.