Rob-550 Segway Blog

Team: Wayne Pan, Bruce Huang, Brian Bittner

November 23: Let's get started!

Today we got all of our parts, which included a:

  • Umich Robotics breakout cape
  • 2 motor controllers
  • power regulator
  • IMU
  • 2 motor-encoder-gearbox packages
  • mini 80-20 with fasteners
  • wheels

Our initial goal was to understand the distribution of power and communications for our robot. we started by reading through the documentation, and planning the wiring and integration of our compuational hardware, sensing, and actuators. While Brian was crimping and soldering, Bruce and Wayne constructued the chasis of our segway. We ended lab in high spirits, hoping to quickly overcome the nuances of integration. Our primary goal is to establish communication between the sensors and motors with the beaglebone board.

November 28:

Our team came in to make progress on basic intergration work. We had soldered up the boards and crimped up the wires in our previous meeting. It was time to start wiring up our system. Wayne designed a board to mount our hardware.

We started with the motor controllers. The pin outs that we soldered to the board were plugged into a bread board, which will provide a convenient means organize our communications, establish busses for power lines, and debug any hardware issues. The motor controllers will take a 12V input and distribute this as a function of the user input. An H-bridge allows us to control the motor in both directions, by literally pushing current through it in both directions. This switches the polarity of the magnetic field, reversing the direction of the motor.

Additionally, we hooked up a power regulator. This will allow us to take a 12V input from the power supply and output a 5V supply for the beaglebone's internal power. That way we do not have to maintain the serial connection. This is useful because the cord will apply a net force and moment to the balance bot that is unlikely to help it resist perturbations and balance.

WARNING: Do not power the beaglebone with the usb serial port and from the power regulator. While Arduinos have built in logic to handle such carelessness, Beaglebones do not. Don't Fry your board!

Next we hooked up the encoder feedback to gpio pins on the beaglebones. The quadrature encoder will allow us to tell both how far we are moving and in what direction we are moving. This will be critical for position control. 

November 30: Communicaton

Everything has been wired up, now we want to ensure that we can control our motors. A convenient script (ty peter) has been written to test everything from encoders to motors to imu sensor fusion. In testing the motor, we have noticed that we can only get one motor to be controlled at a time. We got out an oscilloscope to get to the root of the problem.

The oscilloscope allows us to read the voltage and frequency of signals in our circuit (great for measuring PWMs!) On the beaglebone, pairs of SV ports are used to send PWM signals to the motors. It turns out that on our board, 2/4 ports were not operatable. We changed the code to use the two operational ports, and we arrived at two perfectly functional motors. 

Our sensing from the encoders and imu was validated by observing output from the tests provided. Our imu was calbrated such that the our the angle of the segway will be controlled via the pitch, or x-axis of the IMU.

Deccember 3: Beginnings of PID control on Tall Robot:

We began to write our PID controller to control the orientation of our robot. To do this, we obtain the orientation via sensor fusion of our imu and gyroscopic data. This sensor fusion, again, is provided by the logistical infrastracture given to us. The encoders can give us some translational information, but we will use this later. For now we construct a PID controller about orientation. After a good bit of tuning PD (no I) we seem to arrive at a best performance which involves teetering back and forth. Our intuition was to add more damping, but when swinging over the set point, we would still diverge from the goal quite a bit.

We determined that our primary issue was controlling the orientaion by swining a tall effective point mass. This made our rotational very high, and extremely diffficult to control about the inherently unstable setpoint.

December 5: Build a New Mechanical Base

Our mechanical base, as mentioned above, had a center of mass which was too high for the type of control performance we hope to attain. By decreasing the rotational inertia, we believe we will have a quicker mechncial response to ccontrol inputs and overall more vesatile mobile capabilities for our platform.

We removed the verticall struts and reassembled our robot in a configuration which is very low to the ground.

December 7: PID tuning on a new platform

We began tuning again. It turns out that tuning can take quite a bit of time. In particular, we switched our communication framework from usb to wifi, hoping this would be reliable. Unfortunatley, our connection consistently cuts out. This make it hard to quickly tune gains and observe new behaviors.

Initially we tuned our p gain. Our robot oscillated about the equillibrium. Time to add some damping. We add a d term, but our robot seemed to oscillate more violently. This stumped us for a bit. Everything seemed theoretically sound, but simply wasn't working.

December 10: A Backwards D term.

It turns out that we were applying the d term oof controller in the opposite direction. This was accelerating our response rather than damping it, continuously flinging our system into chaos. We learned how substantially such minor errors can have large effects on our controller. Now we slowly added d term until we can smoothly approach an upright orientation.

As expected, there is a slight offset between our robot's angle and the true 'upright' direction. To correct this, an I term accumulated over the duration of the trial, and corrects this error.

Decemer 12:

Now that we have a great orientation controller for our segway, we want it to stay put!

To do this, we will add an outer PID loop to set an angle of approach to converge towards a desired position. The architecture looks like such:

We implemnted the logistical infrastructure for this control loop, in the next session we will tune gains.

December 14:

Our data started with complete communication failure. Peter helped us to flash our board. We had to reset everything to reestablish communication. This took about an hour.

Tuning gains for this outer loop is different from tuning about the unstable angular goal. Here we simply hope to stay in a local translational area. Stability is invariant with respect to (x,y) location, unlike state control for the orientation.

After hours of tuning, we arrive at a robot which will oscillate quite slowly and narrowly about our control input. The controller appears to be highly sensitive to changes in the gains. 

Controlling two states with one control input is difficult, and even more so when when of the states you hope to control is unstable! This is no trivial task. Since we are close to the deadline, we device a plan to have a cool final demo:

December 17:

Whatever Bruce and Wayne Come with for Demo ;)

While Brian was crimping and soldering, Bruce and Wayne constructued the chasis of our se 

We jacked up the wheels for static testing.

<- so sleek and agile!

Motor mount, motor controllers soldered to board.

Integration: Our robot is wired up and ready to sense, plan and act!

We debugged our PWM outputs with an oscilloscope.