baddy-lab / baddy-makers-edition Goto Github PK

The program is full of assumptions and because they are not asserted, the controller can easily get into trouble.
The assumptions are that the positions to play are fixed and that there is a range of speeds attached to it.
The adjusting of motor speeds is based on these assumptions, which is so bad programming.
It is also limiting the uses of the Baddy.

What should be done in the speedadjuster is that the entered speeds are compared and not the programmed types. Based on the difference, some intermediate speed steps are to be done or not. For one step, the intermediate speed could be calculated as the average of the actual running speed and the target speed. With a negative difference, you can decide to break or not, to reduce speed.

I'm talking about int motor_speed_transition(int type, int next_type){
From the types you get the programmed speeds: speed and next_speed for each motor.
With these speeds you do the necessary adjustments by calling for each motor:
int motor_speed_adjust(int motor, int speed, int next_speed){
if speed == next_speed return
if speed - next_speed > brake_step do_some_breaking(motor, speed, next_speed)
if next_speed - speed > acceleration_step do_some_acceleration(motor, speed, next_speed)
set_speed(motor, next_speed)
return

This simplifies the program a lot, because all type transistions use the same routine.

It will avoid unadapted speed transitions, when the implicit assumptions are not there.

Because the transistions are based on the required speeds, the speed adjustment is smoother.

It enlarge the possibilities in the training strokes of Baddy.
For example: we train youth players and operate Baddy, at the same side of the net as Baddy. As we face also the net, it is a mirrored view as the player who operates Baddy himself.
For easy programming, and having the same terrain view on the screen of the app, it makes sense to switch drop and clear by reversing the higher and lower speeds.
Also when I want the 9 training points on a line, or reduce the surface of the 9 point square to eg the backhand rear, or ...
In both these cases, the controller is inducing contraproductive speed steps, which make these modes of operation almost impossible.

We are also looking out for more saved settings, (10?) in addition of the 2 existing, ground and tripod settings, preferably named, as we train also for Minibad, which uses only half of a field and therefore need settings to cover a narower surface.

Hi. Can you share some CAD files or .svg vector files for the wheels?