From what others have posted omni-bot must be basically roamers without objectives. You could try to turn fritzbots into roamers but it might take a lot of roam actions and tweaking.
There are 4 good sources for learning how to waypointing fritzbot;
(1) this community
(2)
Denny's tutorial
(3)
Hobbit's Tool tutorial
(4)
The Wiki.
The basics. Bots are either navigating or they are fighting. If they are fighting they move about restricted by the clipping surfaces of the map, the position of the opponent, and the laws of physics implemented in the game (g_gravity...). But when there is no opponent the bots need to understand the location that they should to go to and valid safe paths to get there. This they understand by the waypointing system.
The nodes and connections are the core of waypointing. They can be seen (when the editor is on) as analogous to a state diagram. If you ever took some courses on programming or on data structures then you might have seen something on State Machines (A method of describing a machine or program as having a discrete limited number of mutually exclusive states. )
An example of a state machine could be the airport-airplane system. Gravity means that airplanes want to come down and in an ideal system they only come down at airports. So a plane has the state of being at airport X. It takes off when scheduled and conditions are right but only according to the airliners flight plans (which defines the possible next states).
Now the machine changes states where permitted when it gets a specific input for a given state. The way a state machine is graphically represented is as a drawing with a number of circles (the states) interconnected by arrows with an input (condition) written beside them. The diagram is somewhat similar to a flow chart, but much simplier.
Well imagine if such a diagram representing bots navigating the map was then laid so as to conform to the map surface. You would then see some spheres or balls with arrows going between them. And the bots would then want to be inside one of those balls (states) when they could, and with each input they would chose an arrow to use to get to the next state or ball. And being a real system the bots like the airplanes take time to change states/locations.
Now in the editor for Bobots you actually see hollow spheres and color coded connection, but this gets difficult when things overlap. So to make it simplier in fritzbot the spheres are represented by a vertical spindle with 8 equatorial radii spokes (when the editor is set to display the radii.). Red spindles for nodes, (and yellow for actions white for routes). And to represent the direction of the arrows rather than use colors fritzbot connections as it were flow in the 'downhill' direction of the connection.
But then what forms the inputs to the machine? Well the combination of the placement of action spheres (and their type, properties etc.), as well as well placed route spheres and the state of the game objectives all act as inputs on the bot. Then depending on the class of the bot it selects an End state for its goal then choses a next state in the path to get to that goal. The bot will always chose the highest priority goal, and shortest path, and that can make them very predictable. So to add a quasi-random element a route sphere can be considered as a single 6 sided die. The bot in the sphere having no current goal rolls the die and selects from the route properties the corresponding altroams defined for it (assuming the route has a valid action for that class of bot). the bot then makes the alt-roam its primary goal with the further intent to continue from that point to its ultimate end goal.