jiahan / atrias Goto Github PK

I believe we just need to communicate well with the amplifiers to get this 
information.  But it should be logged at 1kHz, and be a reliable measurement. 
We'll have to make sure this is part of the Menial board redesign.

Currently, getting the software up and running across the nettop and desktop 
require quite a few steps, possibly in a certain order.

We need to make this a two-step process:

On nettop:
{{{
roslaunch atrias nettop.launch
}}}

On desktop:
{{{
roslaunch atrias desktop.launch
}}}

See website: http://www.orocos.org/

Not available for ROS Electric at the time of writing.

Currently the controller can either specify that the hip is a "pin joint" (i.e. 
in zero-force control) or locked at the midpoint of the screw.  It would 
probably be better if the controller could change the lock-point as needed.

Currently, the publisher is forced to loop at 1 kHz and publish at every loop. 
Obviously, this does not necessarily sync with shm updates. This brainfart 
needs to be fixed.

Robot should go through an automatic self-calibration procedure at the press of 
exactly one button.

Use Medullas' EEPROM to save calibration config?

Please include the definitions of the robot model, already supplied by J. 
Grizzle as a PDF document, to the wiki page.

Current EtherCAT slave driver works with kernel version 2.6.29. We need a 
driver that can work with newer versions of the kernel. If KPA can't provide, 
we need to look for alternative slave cards.

Relevant file:
* data_subscriber.cpp

Maybe use Python for the script?

We need a way to update the encoder limits that the firmware uses for 
calculating the danger regions from the control computer.

The uController on the boom is missing some of the upper bits occasionally 
(like on the order of several seconds).  The current fix is to check to see if 
the value changed by more than some large amount (like 1000 counts) and not 
update the EtherCAT data when it does.

Now that the power will go through our Menial boards on the Elmos, we should be 
able to measure this.  Hopefully we can use the Hall sensors we already found 
for last summer's amps, or we can ask SWRI what sensors they use, and they may 
help us incorporate it into our machine.

Something nice to print out so people working with the robot can tell what the 
medullas are doing.

Modprobe works again after reboot.

Plot log data (on GUI or with another tool to parse log files)

We should have an automated test to show the computation time available to the 
controllers.

To reproduce:

1. Turn on EtherCAT slaves, connect to master.
2. Insert kernel modules rt_shm and rtai_controller.
3. Monitor dmesg output.

The dmesg output looks something like:
"EtherCAT WARNING 0: 1 datagram TIMED OUT!"
"EtherCAT WARNING 0: 1 datagram UNMATCHED!"
"EtherCAT ERROR 0: Failed to receive address clearing datagram: Datagram error."

And:

"Slave does not support changing the PDO mapping."

This happens before the controller runs through the state machine to initialize 
the EtherCAT slaves.

Relevant files:
* data_subscriber.cpp
* atrias_gui.cpp

Need to measure the spring rate using load cell and angle.  This may be an 
excellent task to delegate to a summer intern.  

For now, we could weigh the robot carefully, then change the knee angle to 
change the mechanical advantage of the legs, and change torque commands so the 
robot is in steady-state.  We then know the mass of the robot compared to the 
spring deflection - and this is a much better measurement than the torque 
commands to the motor. We may also be able to add and remove weights from the 
robot, and measure the deflection of the springs.  We _know_ that the springs 
are symmetrical, and that information is important.  

Data publishing needs to keep up with updates from rtai_controller.

Currently, data_publisher lags (on average) behind rtai_controller by 5 to 10 
seconds per minute.

The lag is not affected by the location of the ROS master node, so network 
connection speeds is probably not the bottleneck.

If publishing is disabled, the loop exceeds rtai_controller updates by 10 to 20 
seconds per minute.

Debug messages shouldn't flood dmesg at 1 kHz. That's just mad.

Currently, the publisher is forced to loop at 1 kHz and publish at every loop. 
Obviously, this does not necessarily sync with shm updates. This brainfart 
needs to be fixed.

Currently when any of the hardstops are triggered, the control signal is cut 
from the amp for the related motor.  The problem is when the springs reach 
their hardstop, they have stored up a heinous amount of energy. It would 
probably be better (safer) if rather then going totally limp and unleashing 
that energy, the motors should become "dampy".

To reproduce problem:

1. Turn on electronics.
2. Load rtai_controller kernel module.
3. Monitor output of dmesg.
4. Monitor LED status lights of Medullas.

The medulla boards still report that they a KPA part.  We need to get a script 
(make or find one) to edit the SII binary.

Rather than staying in the "danger" state once the transmission is out of the 
danger range, we should move to the error state.  The transition should happen 
when the transmission is out of the danger state and while the velocity of the 
motor lower than some threshold.

This will replace Devin's custom interface code between kernel and EtherCAT. 
This should also make launching software easier.

Yep.

Create a system image of a working Zotac system so we can fall back to it if we 
break anything.

The medullas will report an error variable through the ethercat. It would be 
helpful to have these errors appear on the GUI.

The Medullas need to implement motor position limits, such that if the motor 
comes close to a hard stop the medulla runs a damping controller to stop the 
motor smoothly.

Right now to change the ID (to either leg A or B) the code must be directly 
modified.  This should just be a makefile option (i.e. "make legA").

Currently the makefiles are unable to handle building objects and linking them. 
 This means that the external libraries (in the "lib" folder) have all the code 
in the header file.  While this works, it is gross and make the elderly cry.

make a nice google doc of the medulla system flow

Implement a globals.h for global defines.

Because we are currently limited by the maximum velocity of the motor's rotor, 
it would be nice to have this logged along with the rest of the data. The rotor 
velocity can be calculated from the motor velocity that is already measured.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Currently, the RT controller logs at 1 kHz while the GUI grabs a single clump 
of data at around 30 Hz (just enough to update the graphical display).

wireless_kern_interface runs two threads: msg_thread and datalogging_thread.

msg_thread... I'm not sure what this does. It might be the messenger between 
user space and kernel space.

datalogging_thread opens a logfile and logs an entry every loop.


The change: datalogging_thread should store 50 to 100 lines of log data at a 
time to send to the GUI in bursts (i.e., 20 to 10 Hz). Bandwidth could be saved 
by storing the values as floats instead of strings. This would be an addition 
to the local logging that is already performed on the nettop.

ZotacBuild describes the software compilation process nicely, but the process 
really could be simpler.

Ultimately, we want to create a modified Xubuntu distribution with all 
necessary software components preinstalled. We'll want to consult OSU's OSL and 
LUG for this.

Fewer steps is better.

Someone should make a guide for working with the robot on a day-to-day basis.  
It should include things like how to get the system running (hopping?) from 
complete power-down and trouble-shooting ("are the lights blinking?", "did 
dmesg say xyz?").

The leg seems to disable itself too easily. I calibrated the transmission 
offsets, but the vectran cable readjustments probably affected the leg angle 
safety limits.

I am adding comments to some of the code using javadoc style comments. This is 
parsed by doxygen to create HTML file. The project  coding standard needs to be 
updated to include how to make comments for doxygen

It's likely that the cause is that no file location is specified and there is 
no error checking on the fopen or whatever.  The fix should be to check if a 
log file location has been specified before trying to open a null file.

Using the Leg Position controller of the GUI, we are able to slowly change the 
leg angle to about 0.5 radians from neutral (pi/2 radians) and have one Medulla 
put itself in state 2 (STATUS_DANGER).

This happens in both directions.

It is always only one Medulla that dies, never both.

The log files do not show any outlying encoder values, so the encoders are 
probably okay.

The specs that the amp are currently configured with are the generic ones from 
the website.  We now have the actual specs so the amps config can be more 
accurate.

The motor angle limits warn any one motor before it reaches its hard stop.

However, when both motors are moving to pull the leg up, the effective range of 
motion of each motor is decreased because the two parts collide.

We need a way to keep this from happening. (Limit the sum of the two angles, 
perhaps?)

We want this before ATRIAS 2.0 is put on the boom.

Currently, calibrating the robot involves manually moving the leg to various 
lengths and angles and recompiling the Medulla firmware with the new 
calibration values.

One idea with which to avoid having to touch the Medulla code at all is to make 
use of the EEPROM on the Medulla boards. The calibration values would be sent 
from another machine over EtherCAT, and the Medulla boards could save those 
values in the EEPROM.

It would be cool if the robot could make use of its limit switches to 
automatically undergo a calibration procedure at the press of a button.

Please leave any suggestions in the comments below.

Checking and unchecking the Log Data checkbox in the GUI sometimes updates the 
file chooser and sometimes does not. The logfiles are automatically created 
properly by data_subscriber and reported back to the GUI node, but even though 
the GUI node sees the logfile name, it doesn't always update the file chooser 
button.

is ATIRAS part of the URL?  Why is there a space in the URL?

We'll epoxy three onto the motors we've just purchased, and in the future, give 
the Digikey number to Emoteq so they will include them in our motors.