HMI current sensing

[tum]

Has anyone been able to read the hitec servo current draw using HMI and the stock 3024 board?

[Ray]

If you search in this web site, some people had discuss that Robonova's servo do not have the current sensor.

[tum]

If you search in this web site, some people had discuss that Robonova's servo do not have the current sensor.

I thought you could read the current using the serial interface?

[i-Bot]

You are both correct.

The servos do not have a current sensor.

The current can be read using serial HMI.

The current reading is not the actual current, but is the applied current. It appears to be the PWM ratio of the motor drivers. This is calculated from the difference between the actual servo position and the desired servo position within the servo, using a control algorithm.

Actual current will differ from real current due to back EMF in the motor, battery voltage, battery source resistance, etc.

The new HMI servos with current protection use the applied current value and cut out if this is too high for too long.

The current read via HMI may be sufficient for your needs, or you may actually get the same information from reading the position.

Note also there has been some concern that with serial HMI, and also with reading position using pulse feedback, you do get a valid result 100% of the time. This may be some internal software timing in the servo, so do check all the values returned.

[tum]

You are both correct.

The servos do not have a current sensor.

The current can be read using serial HMI.

The current reading is not the actual current, but is the applied current. It appears to be the PWM ratio of the motor drivers. This is calculated from the difference between the actual servo position and the desired servo position within the servo, using a control algorithm.

Actual current will differ from real current due to back EMF in the motor, battery voltage, battery source resistance, etc.

The new HMI servos with current protection use the applied current value and cut out if this is too high for too long.

The current read via HMI may be sufficient for your needs, or you may actually get the same information from reading the position.

Note also there has been some concern that with serial HMI, and also with reading position using pulse feedback, you do get a valid result 100% of the time. This may be some internal software timing in the servo, so do check all the values returned.

Hi i-bot,

I've been reading through the forums and still don't have a clear idea of what is possible with the 3024 board. I would appreciate it if you could (time permitting) document the exact steps required to get a fresh RN-1 setup to be programmed with C. I'm at my wits end with robobasic.

I would like to be able to program a 3024 controller to control the servos using the HMI serial interface. I assume this is entirely possible with the stock controller board by simply bit blasting the coms through the existing servo signal lines. All the lines could be bit blasted simulataenously and through some rough calculations (assuming the AVR128 is fast enough) I'm thinking I could send packets at 100hz to each and every servo.

[i-Bot]

I will try to find some time to document the process.

Basically you need to generate the code using AVR studio and gcc compiler. This make a .hex file which is downloaded using RoboFlash to the controller board.

The bootloader on the C3024 limits the file download to 64K bytes (32K instruction words).

If you are looking at HMI, then there is an example in Fritziods file area:
http://robosavvy.com/Builders/Fritzoid/SerialMove.asm

My file area has some idea of the C library based on the existing C3024 code:
http://robosavvy.com/Builders/i-Bot/upload.zip

I have been using the stock RoboBasic firmware with some patches to add new functions. I use this to retain compatibility with the majority of other RN1 owners.

I have two other controllers, one Parallax propeller based and one using Spartan FPGA. Both of these have advantage that the time critical and time consuming code can be seperated. However both involve swapping boards, so are a pain with all the servo wires.

I am considering going back to the C3024 as the low level controller and using a second processor for higher level. This could be local or remote. New C3024 software is still required since the comms of the stock C3024 is not compatible to this mode. So I would have to make a new library based on interrupts for the servo timing.

[tum]

Hi I-bot,

Do you know much about this hitec chain interface for up to 128 servos? I assume this means that up to 128 servos can share a single signal line but I can't find a single piece of documentation regarding this. A chain interface implies that you can set IDs for each servo but there's no information about that either!

The feature is explicitly advertised on the side of the servo retail box too.

[i-Bot]

Yes, you can daisy chain the servos, they have open collector interface. This only true for serial HMI of course.

The ID can be set using the serial HMI program cable and software.

The limitation of daisy chain is speed. The HMI serial protocol is at 19200, and single transaction takes 7 characters. so the time of the total transaction is 3.65 milliseconds. This is why it is usual to have a seperate UART for each servo.

[tum]

Yes, you can daisy chain the servos, they have open collector interface. This only true for serial HMI of course.

The ID can be set using the serial HMI program cable and software.

The limitation of daisy chain is speed. The HMI serial protocol is at 19200, and single transaction takes 7 characters. so the time of the total transaction is 3.65 milliseconds. This is why it is usual to have a seperate UART for each servo.

Ok, that makes sense. A line each would give each servo a transaction rate of over 300Hz. More than enough for dynamic feedback control.

The side of the HSR 5498SG retail box says the servo can give voltage, current and position feedback. Sounds a bit like false advertising.

If the current is only deduced from the requested & real position offset then I'm guessing it won't be able to show very low current changes (from the robonova foot encountering an object) because those won't cause a position mismatch because the servo is able to overcome small forces. Does that sound right? If that's the case then it's not much use for balancing feedback either. I guess reading whilst moving would also result in useless values.

[tum]

I will try to find some time to document the process.

Basically you need to generate the code using AVR studio and gcc compiler. This make a .hex file which is downloaded using RoboFlash to the controller board.

The bootloader on the C3024 limits the file download to 64K bytes (32K instruction words).

If you are looking at HMI, then there is an example in Fritziods file area:
http://robosavvy.com/Builders/Fritzoid/SerialMove.asm

My file area has some idea of the C library based on the existing C3024 code:
http://robosavvy.com/Builders/i-Bot/upload.zip

I have been using the stock RoboBasic firmware with some patches to add new functions. I use this to retain compatibility with the majority of other RN1 owners.

I have two other controllers, one Parallax propeller based and one using Spartan FPGA. Both of these have advantage that the time critical and time consuming code can be seperated. However both involve swapping boards, so are a pain with all the servo wires.

I am considering going back to the C3024 as the low level controller and using a second processor for higher level. This could be local or remote. New C3024 software is still required since the comms of the stock C3024 is not compatible to this mode. So I would have to make a new library based on interrupts for the servo timing.

Excuse my ignorance again but will uploading a .hex program I've compiled with AVR studio (nothing but an empty main) somehow kill the ability to use roboflash a second time? Is the ability to use flash using the roboflash in the default hitec firmware?

[i-Bot]

When an external torque is applied to the servo, it does seem to go slightly off position. This means the current reading does give some indication of applied force to limbs. The force does appear to need to exceed the servo dead band ( about +/- 5 microsec) after that the current reading is about fairly linear until full current is applied at +/- 100 microsec (+/- 10 degrees). These were based on the default servo configuration.

So worth a try.

As you say this is of little use during movement, the dynamic case is a lot more complex.