golems / krang Goto Github PK

The wifi communication sucks at the time. Maybe that will help.

The temporary arrangement for this in krang-balance-hack doesn't update offsets across all daemons. This can cause the pciod to have wrong joint limits -- a cause for potential damage if they are too far off.

The old circuit diagram should be updated and a poster should be created with a white background and maybe some coloring.

In the arms, the wires go through each interface board and motor. To take out an interface board for testing, these wires has to be removed through the hole or cut (at the moment). However, we can instead remove the board from the motor and slide it along the slack of the wires, creating enough space to place two connectors from another interface board. This would save a lot of time if we have to test interface boards in the future.

Every now and then, we hear random beep sounds that we can not identify the reasons of. One such occasion is when we zero the arms in linux. We should start from there!

This is very low priority but I just observed that the monitor connected to the vision computer becomes grainy when the robot is charging. This might indicate a bigger noise issue in the system or may serve as a clue.

There is a delay of 4-5 seconds in the "printed" filtered values of the imu. The problem might be our visualization of the values or the filtering.

Need to remove redundant parts and assemblies and post everything to the krang.git for documentation

As of now, we do not handle any error messages in robotiq hands. When they don't work (and they don't work from time to time), we don't know the reason.

Also, we need to be able to read data from the hands such as the position of the fingers.

At the moment, we use x_{k+1} = Fx + w although we could have a Bu term in the estimation of the next state. To accommodate the lack of it, we have a large w, the process noise. Incorporating the control signal would be fast and lead to more precision.

It has to do with the krang-waist driver. Probably it doesn't sense the same position as krang-balance-hack does.

We suspect that at any given time only one module is holding all the weight of the upper body because the breakers of the both modules may not engage simultaneously and the one
that is engaged first actually carries all the weight. We should look into this possibility.

See initialization in old krang-balance-hack or new forwardKinematics experiment.

There has been some discussion indicating the contrary and we had fuses blown possibly because of pushing beyond a hardware limit (note possibly).

pciod is yelling at us when the driver is started in initd/kang. In wondows it is working fine.

At the moment, the time step is fixed to be 2.04 ms but we could possibly measure this value. Whether that measurement is reliable or not should be tested and if so, implemented.

When I set the top view, the camera seems to have both a pan and tilt angle. I suspect this is because the base is set at an offset wrt the world coordinates.

The values being read from module 3 and 4 of the arms become zero and then jump back to current value. For module 4 it stays longer to the zero value before coming back to the current value and is more frequent.

The computer refuses to start up and display anything on the monitor. Once started it turns off really quickly, indicating some deeper problem than just a bad VGA card. For the time being, a second computer is used instead.

A possible next step is to order a "Power on self test" card and do the diagnostics of the computer while starting up.

1- Clean up the code
2- Evaluate the necessity of two threads
3- Provide interface functions to read back virtual output
4- Upon death, reset virtual output

Mike Stilman came to the lab and told me (munzir) that he needs krang-balance-hack to be up and running by the end of this week. Someone is going to come next week, and Mike needs to have krang ready for display.

We need to compare the CoM calculations between the new and old versions to see what we have gained from the more detailed model.

We need multiple users so that they can login to git and push/pull stuff to the solidworks model (so that we know who did what)

A short report describing the observations, conclusions and future work on the HOK problem.

When we query for a nonexistent module with a command such as "pciod -Q state -b 1 -m 8 -m 9 -m 14", pciod hangs instead of returning an error.

It works in windows so it is a software issue

Currently, it does not have any information.

The range of the z reading is substantially bigger than the x/y readings and if we assume that the same happens in the variance, then the Kalman filter should treat the z readings differently. Let's make sure this happens.

Calculate Krang moments of inertia and put in URDF files

Something needs done with these, but I'm not sure what. Assigning Can as well so he can give details