Skip to content

Servo continuous persistence#24

Draft
vishwasenthil wants to merge 6 commits intomasterfrom
servo-continuous-persistence
Draft

Servo continuous persistence#24
vishwasenthil wants to merge 6 commits intomasterfrom
servo-continuous-persistence

Conversation

@vishwasenthil
Copy link

No description provided.

@vishwasenthil
Copy link
Author

New code

#define PAGE_SIZE_BYTES 256
#define XIP_BASE_ADDRESS 0x10000000
#define ROBOT_MAGIC_NUMBER 1

Copy link
Member

@Effo12345 Effo12345 Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These #defines is one of the main reasons I mentioned splitting nonvolatile stuff to a separate file; the rest of the actuator code doesn't really care about them and it leads to low file cohesion

bool is_moving;
int32_t target_pos_continuous;
bool target_pos_reached;

Copy link
Member

@Effo12345 Effo12345 Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you define these global variables here? They don't seem to be used anywhere. Same is done down below (lines 139-140)

extern servo_t claw_grip;
extern servo_t claw_rack;
extern servo_t *servos[NUM_SERVOS];

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Declaring these extern is fine for now while testing, but try to restrict them just to the .c file for final production. Also, I don't see any reason you need to include actuator.h here. Really all you need is the servo_t struct definition, found in hiwonder_driver.h


if (abs(servo->absolute_pos - servo->target_pos_continuous) < STOPPING_TOLERANCE) {
// Stop servo
uint8_t param_buf[MAX_PACKET_SIZE]; // Is MAX_PACKET_SIZE necessary
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, MAX_PACKET_SIZE isn't strictly required but it makes dealing with the buffer easier since you can put it on the stack instead of having to malloc it (because it's a fixed size)


if (err != SERVO_READ_OK) {
LOG_WARN("Servo read error");
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why multiple checks for SERVO_READ_OK? This second one will never run

}

const int32_t ROLLOVER_THRESHOLD = 500; // 32768
const int32_t FULL_RANGE = 1400;
Copy link
Member

@Effo12345 Effo12345 Mar 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please never declare constants this way, even while testing. If they must exist, place them in a #define at the top of the file. Hiding the constants inside the functions makes it much harder to find them when you need to change them later, constants being the things that are most frequently modified after the code is put into production

servo_read_continuous(servos[i]);
}
*/
servo_read_continuous(&claw_grip);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine during testing, but this should get moved out of main for production

write_to_flash(&servo_config);
*/

servo_continuous_move_deg(&claw_grip, 360, 200);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to avoid testing like this unless you're getting really weird issues. It's better to make a more versatile test platform with ROS inputs

printf("Read failed with error code: %d\n", err);
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to avoid placing functions like these in main as well

@Effo12345
Copy link
Member

A couple general notes:

  • Please remove micro_ros_template and the reference to it in .vscode/settings.json
  • I appreciate the maintenance of the ROS structure in ros.c
  • You'll have to run me through at S'ups how your code is sending packets presently. I don't see anywhere that calls to the uart_scheduler but I might be missing it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants