The past week I’ve spent more time than I had hoped learning how to use the PWM functionality on the BallE board with the help of ChibiOS. There are a few things that have slowed my progress — for example “TIM3_CH4″ seems to be implemented as Timer 3 Channel “3″ (starting at 0). Not realizing this in order to make the proper 1-off correction consumed the majority of my time.
The other issue I had was implenting the usage of the PWM with one of the board’s blue LEDs. I wasn’t able to use ChibiOS’s “palSetPadMode” function to change the LED to alternative mode 1 on the fly. Instead I found a way to get it working by setting the alternative mode directly in our board.h initialization file. This is not the biggest of issues, seeing as we will most likely never use the LEDs for PWM functionality.
There is still a lot of work to do on implementing the balancing control of BallE. Depending on our progress with getting the H bridges up and functional, I may continue on trying to build a sim environment for testing the control of the motors. The plan is to have a balancing bot by the end of the week… I’m sure this will be a challenge, but I’ll be working hard during the week to have it ready.
For the past few weeks I have been working hard to understand a mash of Matlab, Simulink, VRealm, Mathematica, and most of all ‘math’ itself; all of this in attempt to fully understand and simulate the 3D modeling and feedback control of the state of the art rezero robot. The information included by the rezero team is impressive, but the matrix translations and binding equations for describing the coupled state of the robot are too complicated to understand and implement in the amount of time remaining.
The BallIP implements a straightforward planar model, in which the movement of the ballbot is described in 3 separate 2D planes (XZ, YZ, and XY). The feedback control loop is modeled as a PD loop. The theoretical values are computed and then tuned for the real system. The first attempts to reproduce the nyquist plots given in the BallIP report were unsuccessful. I can only imagine that its a misunderstanding on my part of the interpretation of transfer functions in matlab. This is something I will have to get help on from one of the TSI professors.
Today I started up on coding in ChibiOS along with the rest of the group by testing a thread which flashes a LED. Pierre-Hugues has set all of the configurations for the BallE board so it was fairly easy to pick up demo code and get it running.
To further understand ChibiOS I will also start playing the usage of the PWM during the vactatio (sooner than later). Hopefully in parallel I have time model the transfer functions used by BallIP.
More to come…
I have spent the majority of today working with MATLAB’s built-in 3d modeling tool — called V-Realm. Before this, I had discovered the way that we will be able to create a general MATLAB model and include a 3d visualisation (*.vrml), and specify inputs to the 3d model. This, of course, will allow us to visualize the simulations we intend to create for our ballbot motor control system.
The V-Realm tool has a significant learning curve — especially, if your not used to 3d graphics, rotations, and vectors. Though I’ve managed to figure out the majority of it’s functionality, I haven’t been able to understand rotations using quaternion vectors. The result is a slightly less-than-perfect manual rotation of the motor-axes around their own z-axis. Most importantly, the 45 degree angle between the motor axis and the ballbot body is perfect (assuming my calculations were correct).
As for quaternion vectors, I don’t envision having to manually calculate them as I tried to do tonight. The power of MATLAB will allow us to model 3d transformations using the manipulation of matrices. Of course, I’m a bit rusty on linear algebra, but there are a number of great examples — implementing an inverted pendulum; control system for the NXT BallBot from CMU — with which I can hopefully learn the concepts much more rapidly.
In conclusion, the created 3d visualisation of BallE in empty space is, thus, well-specified according to it’s currently decided dimensions:
- 10.16 cm diameter
- 1.27 cm x 2 wheel bushing (not sure if I interpreted ‘bushing’ correctly, but not too important right now)
- 22.0 cm diameter
- 40.0 cm height
- 5.7 cm in height
- 5.7 cm length and width
- 22.0 cm diameter
Any of these dimensions may change, but it shouldn’t create too much extra rework for aligning the parts in the 3d model. Tomorrow I intend to verify the dimensions of the 3d model against our actual build plans (Matthieu will be starting on that tomorrow). Afterward, I plan to experiment with the MATLAB simulations by adding some basic inputs and potentially updating the enviroment with a ground and some color. I also will work with Otilia and Pierre-Hugues on testing the usage of a Kalmann filter for our inputs from FreeIMU.
More to come in the near future. Over and out.
Ballbot Visualisation in Vrealm
I hope I can recall everything that we reviewed in class for place and route in Expedition PCB. It was impressive to see a completed pcb diagram in 30 minutes. He makes it look easy. I spent about 3 or 4 hours working on just the placement. I finished the routing after another 1 hour for configuration corrections and 1 hour of careful routing. My placement didn’t take into consideration the routing for voltage and ground, so my sublayer is pretty ugly and I didn’t take much time get rid of snaking. I also haven’t made consideration for lengthening wires to the same bus. I’ll have to practice it later. I’m also thinking about asking for suggestions. I saw others using grounding pins for some of their chips. I didn’t use any. It’s difficult to stop working on my PCB because I’m really not satisfied with the outcome, but I will hopefully practice later and try following some principal guidlines which I may have missed this time (such as better placement with consideration to voltage and ground wires).
First log entry!
My work in completing the communication challenge was a miserable failure on last Friday. I’m continuing to feebly progress on my zigbee code. Currently I can receive… something… which appears as nothing, but it screws up my other messages, so I know it’s there. I also know that I may have a problem with my lcd mutex or lcd timing, seeing that my other messages “interfere” (for lack of a better word) with my zigbee messages.
I burned through a ridiculous amount of time staring aimlessly through my buggy code. Luckily I was able to get some help from the other students on setting my interrupts correctly and also identifying that my maximum stack size for the zigbee receiving task should NOT be (configMINIMAL_STACK_SIZE * 15). The simple fact that my error was fixed in a matter of seconds with the help of the others suggests that I need to find more clever ways to ask for help debugging.
So, I have another hour tonight that I can spend on my largely unfinished Schema and PCB diagrams. Tomorrow will be another long night of project work. Luckily (or unluckily) I managed to mark the wrong date in my calendar for my visa renewal appt, so I won’t be missing class tomorrow as long as the police don’t come take me. That should free up some more time for looking through the rezero ballbot simulations.
More to come on my zigbee adventures in a couple days.
After some days of silence during which we did some hard thinking on the mechanics of BallE, we have an idea about what power of motors BallE will need for maintaining stability for a worst-case scenario. For a final load of 10-20 kg, a center of mass not higher than 50 cm (for the structure placed upon the ball) and for a recovery angle between 0 and 30° we would like BallE to stand up in less than a second. For that a total power 50 W should be plenty. We want to stick to our initial plan: 3 omni-wheels so we will need 3 motors…
There is a compromise between the motors we can aford and the power BallE needs. We think that 3 motors of 12 W should do.
After taking a look at the ballbots that where built, we liked the Japanese one the most. You can take a look at it here:
We liked the idea of using thrust bearings to support the axial load between the omniwheels and the motors. The motors that the Japanese used are stepping motors (KH56). After some hesitation and debriefing with Alexis (based on the Segway experience) we decided to use DC motors.
We took a look at Kalman and LQR and we took a deep breath…
It was decided that it will be easier and cheaper to build a metal frame for the ballbot instead of a wooden or plexiglass one (in contrast to the Japanese one).
We still have to decide upon the size of the omniwheels:) More on that, tomorrow.
Otilia, PHH, Scott, Matthieu