Finished Projects on Lizerd

Proto Modules

Wed, 23 Apr 2014 00:00:00 +0000

There is not always a good solution to design your PCB without testing some of the more important parts or implementations ideas that haven’t been tested before, to see if it is working as you thought. So from the beginning I have been using experimental PCB boards that I could use to test my solutions. But long ago I switch over to SMD parts and scraped the trough hole components that I had. And then the experimental boards became quite hard to use. So I started creating different small PCB boards that holds my standard parts and solutions. I have quite a lot of them now, so I thought I could show a few. I use plastic plate as base that has a grid of holes drill in it, so I can mount the boards and use Dupont cables to connect between each module.

MCU Boards

Since many year back now I use STM32 MCU family as my standard processor. I made my own break out boards for the different MCU family’s.

TFT 2.8 inch with touch + touch controller on the board

3 (half H bridge) channel power board, used as an example to drive BLDC motors

24bit ADC with a precision voltage reference

I have made a lot of small modules, here is a few. (Bluetooth, 2ch stepper motor driver, various)

For debugging I use my own USB to serial (3.3/5v) modules. And if the solution depends on various timings, then I place a dedicated connector with a few IO connections to the MCU. So when I debug internal race condition I can always use a logic analyzer to see what is happening. I have also made some larger boards like my DDS module. I put various function on the board that enables me to test a few DDS signal generator ideas I had. I have many other test modules that I will add to the list later on.

Temp controller (8ch PID)

Mon, 21 Apr 2014 00:00:00 +0000

By request I made a board that holds 8 channel temp controller. In this solution the sensors had be digital for high accuracy in a noisy environment, but there are also analog inputs that enables the module to be used as a generic 8ch PID controller.

Structure

Each channel can select input source, ether digital SPI or analog input (12bit resolution). Each channel has it’s own PID and control settings. The controller can be configured to work in many different ways. The unit is powered by a 5 to 24v and can send status and settings trough an RS232 port.

Temp Sensor

I used a small 5-pin SOT23 temp IC, LM95071 SPI/MICROWIRE 14-Bit Temperature Sensor. This gives me resolution of 0.03125°C between −40°C to +150°C.

Board

Demo Video (sorry, there is only a Swedish version)

Settings

UART = 115200 RAW data to controller must start with $ and end with # !!!

Standard Functions

INF $INF# Show info data CLR $CLR# Clear (Resets) Settings, “Do not effect eeprom settings” SAV $BRN# Save settings data to EEprom (Burn current data into Eeprom) UPD $UPD# Update settings data from eeprom SWV $SFW# Show FW version

TempSensor port -> Temp Channel Select function

Select which TempSensor ( SPI port ) that selected TempChannel(PID regulator channel) should get it’s temperature from. TCS $TCS@1*3# Temp Channel Set, TempChannel 1 is set to use TempSensor on port 3

Enable/Disable functions

TCE $TCE*1# Temp controller Enable/Disable 0=Disable, 1=Enable (on enabled PID (I) is reset to Zero). All channels will be Enabled/Disabled. Only channels that is Enabled “CHE” will be activated on $TCE*1# CHE $CHE*1# Channel 1 Temp Control Enable (CH 1->8) on enabled PID (I) is reset to Zero. CHD $CHD*1# Channel 1 Temp Control Disable (CH 1->8) on enabled PID (I) is reset to Zero.

Main Setup functions

NOC $NOC*2# Number of active channels “in order” that should be used “0 to 8 -> CH0 to CH8” TUR $TUR*20# Temp and PID Update Rate in Hz, example = 20Hz DUD $DUD*2# Debug Update Divide, “Temp Update Rate”/DUD , in example 20Hz/2 = 10Hz. The debug data will be updated (sent) 10 times/sec SUR $SUR*1# SPI update Rate " SPI communications Freq" 0 = 140KHz 1 = 280KHz 2 = 500KHz 3 = 1MHz 4 = 2.25MHz 5 = 4.5MHz

SDS $SDS*2# Set Debug Status, example = debug is set to output channel 2 data Debug_Status = 0; No debug Debug_Status = 1; Channel 1 data Debug_Status = 2; Channel 2 data Debug_Status = 3; Channel 3 data Debug_Status = 4; Channel 4 data Debug_Status = 5; Channel 5 data Debug_Status = 6; Channel 6 data Debug_Status = 7; Channel 7 data Debug_Status = 8; Channel 8 data Debug_Status = 9; Send only every channels temp in visual form {Value in (int)(float * 10)} Debug_Status = 10; Send only every channels temp in visual form {Value in float} Debug_Status = 11; Send only temp from all channels in graph data Debug 1 to 8 data format (Temperature * 10: Temp_Ref * 10:** Temp_Error * 10**:** PID_Resualt / 10**:** P_Resualt / 10 : I_Resualt : D_Resualt : PWM**) all values are in Short HEX and separated by “:”, new data is separated with 0x0A = “/n”.** Channel Temp Settings SRT $SRT@1*51.6# Set Reference Temperature, example set CH1 ref temp to 51.6 deg

PID Settings

SPK $SPK@1*101.1# Set Pid K value for selected channel, example K = 101.1 on Channel 1 SPP $SPP@1*1.1# Set Pid P value for selected channel, example P = 1.1 on Channel 1 SPI $SPI@1*0.1# Set Pid I value for selected channel, example I = 0.1 on Channel 1 SPD $SPD@3*10.5# Set Pid D value for selected channel, example I = 10.5 on Channel 3

Channel Power Settings

SMP $SMP@1*100# Set Max Power “PWM Max Duty” 0-100% example, CH1 set to 100% as max power level SLP $SMP@1*0# Set Min Power “PWM Min Duty” 0-100% example, CH1 set to 0% as max power level

Power Invert function, For example active cooling equipment

CIE $CIE*1# Enable Power Inverted function on Channel 1 (0% power inverts to 100% power) CID $CID*1# Disable Power Inverted function on Channel 1

Example Channel1 Settings

// Set Reference Temp SRT@1*55.5 //// Set CH 1 K value SPK@1*1 //// Set CH 1 P value SPP@1*400.5 //// Set CH 1 I value SPI@1*0.5 //// Set CH 1 D value SPD@1*100.5 //// Set CH 1 Set Max Power SMP@1*50 //// Set CH 1 Set Min Power SLP@1*0 //// Set TempChannel1 to SensorPort 1 TCS@1*1

Example Main Settings

// Temp/PID Update Rate in Hz TUR*4 //// SPI update Rate , 0 = 140KHz SUR*0 //// Set Debug Status = No Debug SDS*0 //// Debug Update Divide DUD*2 //// Number of Channels that is active NOC*2

Modular Data Acquisition System

Sun, 20 Apr 2014 00:00:00 +0000

I made a system for signal data acquisition that had to be modular and also work standalone without a connected PC. It should be powered by battery or usb and communication should be done by Bluetooth or USB. The memory had to be absurdly large or else I had to implement a trigger and sample profile that should be able to handle various situations. The later was the better solution. I did the PCB HW and firmware plus demo PC software that held all the functions/classes needed for another guy that did the final PC software, mechanic parts and HW installation. So this is what I did.

HW Part

The system is based on a hub module (in the plastic case), a sensor module (aluminum case) and a sensor package (lower left corner). Multiple sensor modules can be connected to the hub trough daisy chain. The sensor module holds two differential input channels that are used for strain gauge measurement (Instrumentation Amplifiers), and six analog (12bit) or digital inputs. Each differential channel has a settable offset trough the 12bit DAC, so the offset can be adjusted while the profile is running. The module also holds one 3 axis accelerometer and one The RGB led is for status indication. The board on the picture is not fully populated. I used “no delay SPI flash memory” that enables me to sample and save data at a high rate. I made four flash memory footprints so it can be populated with 4 to 16MBit storage memory. I use two SPI channels so I can write/read to two memories at the same time. The module also holds a regulator for the 10v that is used for the strain gauge sensors. This voltage can also be recorded if the user wants to check supply variations. The module is divided into two sections, analog and digital. This is to reduce noise. The hub holds the USB and Bluetooth (v3.0) connection to the PC. It is using a step-up converter to step 5v (battery or USB) up to 12v for the strain gauge supply. The empty footprint below the Bluetooth is for another Bluetooth module type, but the one from ST electronics was better suited for speed reasons. This module also holds a global trigger input that is used in this application for absolute positioning of the cylindrical assembly it is mounted on. Both Hub and Sensor module has power saving functionality to reduce power consumption when the system runs on battery .

SW Part

This is the demo software that I did for the other programmer and for my own debugging purpose. The main structure of a data acquisition profile is that each sensor module has it’s own profile of how it will run - independent of the other modules on the system. Each Sensor module has n number of Sessions, each Session holds x number of cycles, each cycle holds period samples. Lets say the module monitors two pressure sensitive cables that are placed on a road (almost everyone has seen this some time on some road). A session holds the period settings. For each session trigger we get a cycle that contains data for each car. In that cycle we get a number of periods. Each period holds data for each wheel pair that are sensed by the cables. If we have specified that we only want to record 100 cars that meet the first Session profile, we can set cycle length to 100, and the create a second Session for another profile settings that detects trucks instead.

Session Settings

Each module can hold multiple different Sessions, and each can be used multiple times or until the memory is full. For each Session we can adjust the Differential channel offset (Vref). This is used for an increased range on ether the positive or negative signal side. If Vref is set to zero mV we have 12bit ADC resolution on the positive side of the strain gauge. or if Vref is set to (max signal)/2, we have 11bit ADC resolution on both side of the strain gauge. And the same thing if you like better resolution on the negative side only. The rest of the settings have the same functionality as in Period.

Period Settings

Start Triggersets on what signal or property you like the period to start on.

External Signal is coupled directly to the global trigger (a trigger signal that is sent to all sensor modules).
ADC is used when you like to trigger on an analog signal from a selected channel.
Time is what it sounds like - time from the last Period ended or Session started.
Percentage can be used when you have a repetitive global trigger signal. The module calculates the time between triggers and you can set a percentage so the trigger time can vary and you still get the same point between trigger signals.
Direct means that the Period starts directly.
Number of samples can be used if you like to wait n numbers of ADC samples before Period should start recording signal data.

Start Flank sets whether the trigger should activate on positive, negative or any flank. Start Filter Time sets how long the trigger flank has to be steady before it is valid. The module starts recording data at the trigger moment, but if the filter shows that the trigger signal is not valid after n time it will delete recorded data and wait until next trigger. The value is X * 0.1mS, so a value of 100 equals 10mS. . Start ADC channel is where you set the channel that should be used if the Start Trigger is set to ADC. . Number of Triggers Before Start can be set if you know that there is n number of signal triggers before the data that should be recorded. . Start Value holds the value the ADC should trigger on in mV. . And there is the same settings for the end trigger. So you can set start trigger to an analog signal and set end trigger to time or number of samples as an example. For each period we can set different ADC settings based on what we want so sample. The Sensor module has three ADC units, each 12-Bit resolution. Total sampling speed (ADC1 + ADC2 + ADC3) while storing data to flash is about 60KHz. It’s mostly dependent on number of channels per ADC, flash write time and filter settings. In this window the user can set average (Filter) and wanted sampling frequency. Not every sampling speed can be met however, so the closest frequency is displayed (Selected Freq). The lowest sampling frequency is 40Hz / Average. In the window ADC3 has a sample frequency of one sample per second, but it takes 10000 samples and makes an average of those over one second. The ADC settings are then saved in the period profile. Each ADC can hold multiple channels. If ADC1 is set to 1KHz it does not matter if you select one or two channels, the sampling frequency is still 1Khz

ADC1_CH1 DIFF_CH1_SIGNAL_PIN. <- Strain gage
ADC1_CH2 DIFF_CH2_SIGNAL_PIN.
ADC2_CH1 DIFF_VOLTAGE_PIN.
ADC2_CH2 ACC_Z_SIGNAL_PIN. <- Internal Accelerometer
ADC2_CH3 ACC_X_SIGNAL_PIN.
ADC2_CH4 ACC_Y_SIGNAL_PIN.
ADC3_CH1 AIN_CH1_PIN. <- Analog inputs
ADC3_CH2 AIN_CH2_PIN.
ADC3_CH3 AIN_CH3_PIN.
ADC3_CH4 AIN_CH4_PIN.
ADC3_CH5 AIN_CH5_PIN.
ADC3_CH6 AIN_CH6_PIN.

Profile setup. To setup the Profile, the tree view holds the settings. Here we can get current status, Download profile to selected module, upload sample data, add and remove content. For each Session. For each Period. Main control to run each or all modules. Using Send trigger the user can manually trig each module and upload sample data. After the module has sampled the data it can be viewed and exported. This project was fun to create. I had to think a lot about timings and squeeze as much functionality in the MCU as possible without loosing sampling speed.

Irrigation System

Sun, 13 Apr 2014 00:00:00 +0000

By request for an irrigation system based on “Ebb and Flood irrigation technique” I made a system that should be able to handle a very large area and variation in complexity as well as irrigation types. The system is modular and is based on a main unit and multiple modules that are used for sensors and system control. My idea was to make the system stand alone so there should be no need for a computer running the garden/greenhouse, but I still wanted a good and easy way to configure and log the system. So with that in mind I built a system that is stand alone, but configured with a PC program trough radio/USB. This is what I came up with:

PC software

P1

I though about how to make it easy to see the setup ether if it’s a small garden or a large greenhouse. So I made an aerial view solution. You can add as many “views” as you like and they will show up as tabs (blue arrow). With each view you can add a picture that should show your garden/greenhouse layout or parts of it by using multiple views. Then you can freely draw smaller boxes on the picture that indicate specific areas. Each box can be the area the sprinkler is affecting if you use sprinklers. Or it can be a flower bed area that use water drop irrigation. And so on. One module can control one area but it can also share sensor information or status with other modules/areas. Blue is views and red is areas within that view. Each area can connect to sensors or signals from the whole system. Only sensors that can be used (in this case Rain sensors) will show in the drop down selection box. Each area can control up to four activators, either on it’s own area or others. For example one main water solenoids that supplies all areas can be set in each area output, so when the area sprinkler solenoid is turned on the main water solenoid only supplies water when it is needed. Area Status holds current status from the area (Sampled from the selected sensors). Get Modules is where I select a specific module that holds a wanted sensor. Only modules that have the selected sensor will show in the list. Set Modules is where I select activators that should be enabled if the selected area output is active. Time frame Settings is where you can set start and end time for each day or for a specific day when the profile should be active. Last Enable is exactly what it says - the last time the area activators were enabled. Timer Settings is where you can set a “dumb” timer. Chain Settings is where you can link the selected are to another area, so this area follows the selected area’s profile. Max/Min Status holds the maximum and minimum recorded Temp,Rain,Moisture an Light values. Calc Settings are only for the irrigation profile for this area. The window below sets this. I have been experimenting with different Irrigation profiles and have implemented one that enables various settings. The “Calculated Time” box enables you to test various weather scenarios. If the area has Temp,Rain,Soil moisture or Light Sensors linked or only one sensor, this profile can calculate the Irrigations. The values in the picture are not for a real profile, they are just for show.

Main Unit

The main unit is based on a STM32F103 32-bit MCU. It is connects to the modules by two opto-isolated RS485 networks. There is one radio port that can be used if a wider range is needed. This is done with wireless routers that extend the RS485 network. The Main unit only needs a computer during the setup, but if the user wants a displayed overview (almost) in real time the computer can log and display the current status of the system. The main unit connects to the computer trough USB or Bluetooth. I have made one water level sensor board that can control one water solenoid. This one is specifically made for the “Ebb and Flood irrigation technique”. It is based on capacitive sensor technique so the PCB do not need direct contact with the water. This is my standard board that I can connect to moisture, light, logic, analog and rain sensors. It has an internal temp sensor but the module can connect to external temp sensor with higher precision if needed. The board also contains four output signals for activators like water solenoids. The module is powered trough the RS485 network and uses sleep modes to reduce power consumption. The plan is to integrate a bootloader so that each module can be upgraded from the main unit. More module versions will be create. They can be used for various functions in the system. For example

Motor controller for fans and venting hatches.
Water nutrient concentration sensor.
Wall mounted buttons and information displays.
And more …

Communication between the main unit and the modules is done trough a RS485 network with 32-bit address space. It uses data packages with CRC and ACK / resend functionality to ensure that right data is sent and received by the right module. The main unit can scan the network and request each module’s ID that is connected and responding. The modules and main unit restart if they by any chance happen to hang. The main unit can send a restart command trough the network if it detects a continuous error respond from any module. This is mostly not a problem, but if it by any chance should be, the main unit has the ability to reset the network.

Simple video in Swedish

More to come later on..

KTH Segway

Fri, 11 Apr 2014 00:00:00 +0000

While I worked on my own segway I got a request from my University (KTH) to create a vehicle that the students should be able to test their control system theories on. So I created an improved version based on my own segway. My motto for this project was the same as for my own version

Highly optimized controller and power boards give you the freedom to implement more advanced model functions without the need for workarounds. It should also be sturdy and hard to break.

This is the result Cad Two KTH students using the vehicle. . I used the same PCB board solution as in my homemade version. A bit better shielding than in my home made version. I used two 1.5 Hp motors with with almost no backlash in the gears. I used encoders that give me 8000 pulses per wheel rotation. Due to the motor power my motor drivers had to be able to handle the large current. The first step was to increase the copper area of the PCB power signal ways. I also changed the mosfets to IRFB3006PbF that can handle 195A continuous and 1080A pulsed. There are three mosfets for each branch in the H-bridge. . Power distribution board. Handles how the system is powered on, before we had one power switch. Now the system is always on and checks if the segway is in use or should power down parts to conserve power. Or shut down in a safe manner to protect the battery’s or if there is any other problem. in off state the board consumes an average of ~255uA @33V, this is made possible by using a super cap. So the regulators are only active during the charge of the super cap, after that the system is in sleep until the cap needs to be recharged. In afterthought I would have added a separate switch for the switch regulator IC’s, and cut the current consumption to about 50uA instead. . High power switch to control when the motors should be powered, and shut down on failure or to preserve power. The boards in the picture is not fully assembled. I made a new LCD unit small demo video of the LCD touch function

The new LCD unit has touch a interface and a menu that can be used to adjust settings while driving. It also displays the KTH logo at power up :) I added better suited motor driver current sensors The battery’s are charged and balanced by this unit.

Structure

The structure is almost the same as my home made version. (New version uses LiFe battery’s instead of VRLA ones, and the new power distribution board is not in the structure picture) Connections between each part of the system

Software/Firmware

I wrote C code that is easy for the students to follow and to start with. This way they can get started with the control theory quickly. This is to free them from having to spend several hours with the base part of the code that makes the rest of the machine work. I even included auto calibration on motor drivers so the students can recalibrate the drivers if they overwrite the values. I included a start-up function on each board so if the student by accident put the main board code in the motor board the code would stop and indicate that the wrong code has been loaded. There is a lot of small things like this to make the development as pain free as possible. With the better sensors the logging result was a pleasure.

Parts

pictures of the segway

I will add more soon I made a small time laps video, more like a test, there is one frame that keeps showing up.

FlashUnit

Sun, 26 Aug 2012 00:00:00 +0000

Flash Programmer

Sony had a major problem with one of there HDD recorder. The problem was that the main memory chip became worthless and the device could not start. The memory contained the player’s software. The only way to load the program files into the memory was through a dvd update disc, and the unit had to be operating for that to work. And all new memory chips was empty so there was no way to solve the problem. So the units were replaced and the not working ones were stacked waiting for a solution. I managed to find data sheets to to the memory circuit, and hoped that the security features are not activated in the units memory. An rig was built for testing the the hdd player memory. After a confirmed that the memory was open and a could extract the data, then i created a PC program that could act as host.. When the first test was successful, a second test board was created. The new connection solution was not a stable solution, the results was not satisfying. there is a reason why there is gold plated connections on edge connectors :) The best solution would be if a large circuit socket was mounted instead of needing to solder the memory, but that was to expensive at the time. So I updated the first version and sent it for manufacturing. And the host program was redesigned to be more easy to operate. After that , it worked fine to revive the old units.

Home Made Segway

Sun, 26 Aug 2012 00:00:00 +0000

I have been working on this idea for a while now, to build my own segway clone. It hass been a while since I started this project and finally it is working as hoped. I made a demo video, as for now it is only a Swedish version is available.

My idea is that I want hardware that doesn’t bring any model or programming limits. There should be no need for workarounds or mysterious functions to make the model work. There should be enough processor power so you don’t have to design your model according to hardware limitations. The theory will seem more genuine if you are not too limited by the hardware. I have based the design on my ideas on how to best implement the simplest solution that still has more processor capabilities than needed. My motto for this project was

Highly optimized controller and power boards give you freedom to implement more advanced model functions without the need of workarounds.

There is a loot of stuff in this machine, I will try to show the most interesting parts :)

The structure of the electronics

The MainBoard, MotorBoard and SensorBoard are housed inside the black box you see above. The black box contains 3 boards. Right now the box is made of wood, but it will be replaced by one made of aluminum soon for better shielding properties.

MainBoard

The main board is a separate board that holds the vital peripherals and has access to all the data of the system. This is the central processing unit of the segway. The main board is a separated board, and this enables a board design that is more resistant to external interference, such as the electrical noise generated by the motor board and motors. This is vital for a good signal to noise ratio on the ADC design that samples the sensors. Without this the sensor readings get noisy and precision is reduced. This is the board that holds the control system that makes the segway balance. Communications between the main board and the motor board are trough SPI for the high speed data, and trough UART for the slower data instructions.

MotorBoard

The motor board gets control data from the main board and interacts with the motor driver to adjust the motor power. The main reason this board has it’s own processor is that if the main board hangs due to code that are under development or for some other reason, the motor board can still actively control the motors. It can then ramp the power down if it senses that the periodic update from main board is lost. This gives you a better chance to get off the vehicle if the motors are stuck on high power or if there is a sudden loss of power to the motors. Another reason is that motor board can handle the motor power control loop with feedback from motor encoder in a dedicated processor instead of having to share the load on the main board processor. This means that I have a lot of processor power only for the motor control loop and I can implement more advanced algorithms without having to consider load regulations. The board also have two current sensor inputs, sensing +- current to each motor driver. This means that the board can sense the power load on the motors.

SensorBoard

The board contains one SPI Gyroscope ADXRS450 ±300°/sec, and two MXA2500G ±1.7 g (2 axis each) that has an angular offset of 45deg to each other. The board is made so it is easy to make a new version. This way I could test various solutions. The current board is my third version. My main goal with this project was to be able to test and learn control systems, and sensors are a big part of that.

Motor Driver

The motor driver is made of H-bridge driver HIP4081A controlling 12 FDP030N06 mosfets. Each mosfet is capable of 120A continuous and ~700A peak current. Each branch in the H-bridge holds 3 FDP030N06 and should be able to handle much more power then the 250W motors will need. I have mounted a digital temp sensor on the heat sink with a resolution of 0.03125°C, so i can monitor the dissipated heat from the mosfets.

Power Distribution Board

This board regulates the battery voltage (24v) to 14.4v to motor drivers and 8v to the box with main/motor/sensor board.

Steering LCD unit

I made this of one of my test PCB boards. The LCD has touch functionality but it is not implemented in this version. On the screen I can monitor the angle of the segway as well as voltages, currents, consumed power, motor driver power and temperature. I can also see traveled distance and speed, but it is on a newer version of the software than the one used in this picture.

Charger

I made a charger that I could place inside the segway so it would be easy to charge the batteries. The batteries are limited to 3A charge current, and the charger is using a 3 step charge mode. It holds information about charged Ah, and voltage, current and temp can be requested trough the UART connector.

Motors

The motors were one of the hardest parts of the segway to find. They needed to have the right specifications and be reasonable priced. Thanks to friends I got one motor for free and two more for a small price. The three motors became two after selecting the best parts. The motor power is about 250W and it is equipped with a worm gear that has an awful backlash. The motors were in used condition so I knew that I would have some problem with the control system due to the big backlash. Currently I am using some nifty encoder from a camera for motor feedback. I must find a better suited encoder so I can use the encoder data in the motor control loop. But it is hard to find a well suited encoder that is small enough as well as reliable. I am still looking for one. If I can use the encoder feedback I can almost completely eliminate the backlash problem - that would be really nice.

Debugging capabilities

I have created a PC logging program that I use for logging data in real time trough Bluetooth or USB. With the program I can read and set control values in the segway, even while it is running. Both the main board and motor board have JTAG and USB communication that can be used to debug processors and output data. JTAG is a direct bus to the processor and can be used to read out almost every step the processor makes as well as settings and data. USB is mostly for sending log data that can be saved as a file or viewed in real-time through the pc program. It enables multi signal view with high detail, which can be saved in various data formats. The program can be used for sending data and commands to the target board with regulator settings etc. By saving logged data in a file and with a large number of formatting options the file can be used for many other purposes. While the segway is running the radio communication can be used instead of the usb communication. The major difference is only the amount of data that can be logged.

My angle measurement jigg

Used for testing and calibrating the sensors Testing and calibrating the motor driver.

Beta Boards

I did make a beta version of the solution at first. Mainboard Motor Board + Motor Driver Sensors, also with the same “easy change” -concept I first made an external charger, but i changed my mind when i did realize I could fit the charger inside the segway instead.

Other

I made some high speed PCB cad and soldering videos based on the segway mainboard and motorboard

Lego Segway

Sun, 26 Aug 2012 00:00:00 +0000

This project was done at KTH Elekro for a project course. This course mostly aimed for project management in groups of five persons, the project our group got was to build a segway robot based on lego mindstorm kit. The problem was that no group before was able to make the robot stand for more then 12 seconds. Only the PhD student group was able to create a robot that could stand without time limit. The goal was to beat the PhD student’s time. My main role in this project was to create the empirical model of a lego segway robot, and this is what I did. we only had access to the lego mindstorm kit the two last weeks, so it was very important that the theory was done before we got the lego kit. Given the time limit it was important to collect as much information as possible before creating the basic control system structure. For the sensor data collection, I built a test rig with accelerometers and gyros, and put together a signal logging program. With this test rig the different angular algorithms could be tested. A idea was to be able to use the rig on the final lego robot. but after implementation to the lego robot data interface a big flaw was detected. The data transfer was to slow and took to much process power when I implemented it in the lego unit. So the idea was scraped. We went away from the recommended programing language, the lego unit uses a so called Real time operating software. And I knew the importance of selecting the right programing language when the processor resources are limited. And I went with Robot C that has the best performance when used with the integrated software in the lego unit. I could skip the integrated software and write processor compiled code, but that would take much more time than a could afford for the project. It was not so difficult to get the robot standing only with the gyro sensor, but it had a awful gyro drift fault, this cannot be calculated, and it gives sporadic data faults. When I tried to integrate the accelerometer in the control algorithm the extra time delayed when fetching the accelerometer data made the robot much more unstable. So instead of the accelerometer I used the wheel sensor, this sensor does not have the best performance, but that was solved with moving average type collector. Here is the final control system for the segway robot Then I created a function in my logging program that enable me to send control data trough Bluetooth and control the robot with the PC mouse movements. The PhD studens robot could only stand still on the same spot or run forward with a constant speed. Final result.

Video 2 " Not the best video quality"

StepMaster

Sun, 26 Aug 2012 00:00:00 +0000

Small but flexible intelligent stand alone stepper motor controller.

This product was made for a motor company. They had a programmable and independent motor controller that was to expensive and with low flexibility. So they asked me if a could do a better and cheaper version. It was a challenge to build it so small with that much motor power . The upper board is my first Beta version. The lower one is the motor board that i should replace. It´s main features is “small but flexible intelligent stepper motor controller”. Main Features

8 Inputs with programmable functions.
2 Outputs with programmable functions.
2 Amp Stepper Driver , Selectable in 20 steps from 100mA to 2000mA. 12 - 30 VDC Input voltage.
Current Standby, Both Time before standby and current is programmable.
2 Analog inputs with programmable functions.
1/1 , 1/2 , 1/4 , 1/16 microstep is selectable by input or internal state.
Programmable functions is set by a PC application.
FW update can be made by customer (done in the PC application).
Programmable Acceleration/Deceleration Time.
Smooth motor motion in manual step mode.

Programmable Input Features

Go To Home “Position zero”
Step continuously at given direction
Step xx steps at given direction
Direction Step continuously at positive direction
Step continuously at negative direction
Step xx steps at positive direction
Step xx steps at negative direction
Positive end sensor input
Negative end sensor input
2 Inputs for speed, 4 programmable speed settings
2 Inputs for current, 4 programmable current settings
2 Inputs for microstep, 4 programmable microstep settings
Emergency Stop, 3 different variations ( Pause ongoing function ) ( Pause and Exit all ongoing functions) ( Pause and Exit all ongoing functions and release current to motor )
Emergency Reset Wait until, trigged functions is memorized and on hold until this function triggers Current standby, Releases current to motor
Abort if, abort all functions when trigged

Input Features

High signal in, between 4.5 to 30v is acceptable for a logic 1 (levels can be changed)
Pull up signal can be applied to input, if pull up is enable, the input pin only needs to be grounded to trigger input function
Functions can be set to trigger on negative “falling signal” or positive “rising signal”

Output Features

Both outputs can handle up to 300mA current each.
Outputs can be set to positive or negative response out

Programmable Output Features

Busy, Triggers output when device is busy or motor is running
Home, when current position is zero “Home” can be set with a +- tolerance
Positive, Negative, Or both end sensor. Activates output on end sensor trigger.

The final version. The board dimensions is 30 x 37 mm I created a PC program in C# that makes the board profile really easy to setup. Profile Input options Every input / output on the motor board can be set to a selected function. Main profile settings Analog Input Settings Device Control Manual control of the motor. Communication settings Firmware Update Built in firmware update function for easy upgrade.

Xremote

Sun, 26 Aug 2012 00:00:00 +0000

Xbox Remote control

Project created 2001

Back in the day when I owned an XBOX I was very irritated that I needed to get up to reset the unit every time I wanted to change games. And to be perfectly clear, I enjoy electronics more than playing games, so it was more fun to create a solution to my problem instead of playing. I think I spend more time on creating this gadget then total playing time on the XBOX. So I had some experience with the microchip PIC16C series micro-controllers and thought it could not be that hard to create some kind of solution to my very very big problem. I started small by creating a debug platform. with one Nokia 3310 LCD and IR receiver, few buttons and RS232 interface. Programming was done in assembler. Processor was 16F676 with 1K Flash running on internal clock. The major problem I had with this design was the lack of flash memory, I spent many many hours on optimizing my code to be able to fit all the functions I wanted. I made a specific prototype. The final version contained the following functions.

IR receiver, supported multiple protocols “IR Protocol learning capability”
Easy to install in the XBOX, with or without any modchip installed.
4 to 10 solder points depending on configuration.
12 programmable functions, easy to program.
3 extra output ports for controlling extra functions, like mod lights and so on.
Only a small IR eye with push bottom is visible on the front of the xbox.

Functions

Check power off = Check if XBOX is turned off, if not turn off. (1)
Power_on05 = Start pulse 500ms long. (1)
Power_on_1 = Start pulse 1s long. (1)
Power_on_2 = Start pulse 2s long. (1)
Power_on_3 = Start pulse 3s long. (1)
Power_on_Set = Start pulse is by configurable time “0.1-7sec”. (1)
Power Do Low = Start XBOX with Do low (Modchip on/off). (1)
Power Do High = Start XBOX with Do low (Modchip on/off). (1)
Eject on = Ejects the DVD player.
Extra toggle 1 = Extra port 1 toggle output status
Extra toggle 2 = Extra port 2 toggle output status
Toggle Do = Toggle Modchip status, also used as Extra port 3

If the XBOX is already on and this functions is triggered the chip shuts down the XBOX.

Extra ports can also be activated “toggled” when the XBOX is turned off.

chip status and port status is saved in the eeprom memory when the XBOX loses power.

I was so pleased with the design and functionality of the chip that I made some extra boards for a few that wanted it as well. Xremote manual Xremote install instructions